What does Instance Upgrade do for already committed Update sets

[Swathi3]

Hello,

I am only aware of upgrading my PDI in ServiceNow. I was curious to know what happens to the already committed UpdateSets(Configurations) when we upgrade the Development/TEST/Production instances. When the Upgrade is successful, will all the configurations be carried forward with no steps to follow regards to update sets or will it be a clean slate?

The product documentation on Upgrade to Quebec in ServiceNow is very detailed. Going through that. I would also like to hear any good pointers  and things to watch out from own experiences during instance upgrade.

Thanks,

Swathi

[John Zhang1]

New upgrade is only impact OOB configurations, not customized configurations.  Basically new upgrade will skip all custom records, configurations and scripts records, but you need to work on each skipped record during your upgrade project.  If you want the upgrade to apply your custom record, you can merge the upgrade feature with your custom changes.

Please mark reply as Helpful/Correct, if applicable. Thanks!

[Theresa Hallen2]

We always stop development, move and commit everything to production that can possibly be moved to production (even if we have to move it and set it to inactive), and then we clone down to DEV & TEST right before a major release upgrade, so we have a reasonable expectation of what will actually occur during the production upgrade. This allows us to test our existing customizations and fix anything that gets broken by the upgrade before we do the upgrade to our Test and Production instances. We export the XMLs for any development work that could not be moved to production prior to clone down and reimport the development XMLs back into our Development instance after the upgrade is completed (and tested) in Development. That’s our process for upgrades; however, your process may be different. I hope that is helpful and makes sense.

[Mark Manders · Accepted solution]

Hi Swathi,

To make sure you can test the upgrade as good as possible, it's recommended to clone PROD over DEV/TEST before upgrading. Any committed update sets on PROD will be cloned over DEV/TEST (make sure you pick the correct backup to clone from, because if you commit an update set at 1PM and you clone a backup made at 8AM, you will loose that update set).

When cloning you can choose to safe 'in progress' update sets. Those will be put back after the clone, but also a warning here: this only works on 'global' update sets. Any others will be overwritten. Because of this I make it a point to always safe them all manually, to be sure I have everything.

After cloning you can upgrade and go through the skipped changes (the Upgrade Center is a real help here). If everything's OK you upgrade PROD, move the update set you created for the skipped changes and 9 out of 10 times you don't have to do anything, because the update set clears the skipped changes on PROD (but check them to be sure).

Since the upgrade is done, the freeze on NON-PROD is over and you can reapply the saved update sets. Import and commit them and you can continue development. Never reopen those update sets though! Either create a new one and merge it with the committed one, or created a 'b-version' of the update set and move them together (or as batch) when development is done.

I hope this helps!

Mark

[peterdelf]

The update sets still persist.  Any individual record that you change from out-of-the-box i.e. a business rule, a client script, a UI Action, a UI Policy, a script include, etc. once you have modified it you 'own' it and an upgrade will NOT change your modified version.  If you customise anything they will show up as 'upgrade conflicts' during upgrade and it is up to the ServiceNow Admin to review these resultant upgrade conflicts and either choose to keep the customised version, merge in the changes between your version and the new ServiceNow version, or revert it back to out-of-the-box.

The whole system is fundamentally built on a version control system.