No upgrade history after cloning

[Bogdan18]

Hello everyone,

We are about to get PROD cloned down to TEST in preparation for the upgrade from Fuji to Helsinki and while we were checking the upgrade history in TEST we noticed that under System Diagnostics/Upgrade history there are no records for the patches we did a long the way. We think that the last Clone we did 6 months ago erased the upgrade history from TEST and DEV. The clone of PROD to TEST will be a full clone, we will uncheck "Exclude audit and log data" and "Exclude large attachment data" and only keep the "Preserve theme" option checked.

1. Is there a way to undo these changes only for the upgrade history table in TEST and DEV? I know there is a rollback option in the clone history but I think this will roll back the entire clone. We would need at least the upgrade history from Patch 13 we did 7 months ago. I see that the file is a zip one, is there something we can do to import it in TEST or DEV? I already tried the export/import xml and even though it doesn't give me any errors the information doesn't get transferred to TEST or DEV.

2. If the above won't be possible then when we will do a full clone will the upgrade history be transferred from PROD to TEST? I am thinking it will as we would uncheck "Exclude audit and log data" which in turn will ignore the System Clone/Clone Definition/Exclude Tables in which the sys_upgrade_.* record is found.

3. If none of the above present a solution what can we do to get the upgrade history records to show up in TEST and DEV?

4. And finally in order to avoid this kind of thing to happen in the future I would like to get confirmation that by adding the sys_upgrade_.* record in the System Clone/Clone Definition/Preserve Data will prevent the upgrade history to be erased. Is this the best solution to this problem?

It is important to get at least the Fuji 13 patching record in the upgrade history on TEST and DEV as we have skipped items that need to be checked.

Thanks a lot,

Bogdan

[Manjeet Singh · Accepted solution]

One option is to export your history as update sets before the clone and re-import them after the clone:

Saving Customizations in a Single XML File - ServiceNow Wiki

[Bogdan18]

What we ended up doing was to remove the "sys_upgrade_.*" record from the Exclude tables of the source instance and run the clone. The upgrade history of the source instance is indeed reflected into the target instance. So you can use this option in future clones and the upgrade history of the source instance will be carried over to the target.