Keeping customizations in sub-prod instance after clone and upgrade

[Kirk4]

Here is a high-level overview of our standard upgrade process for context, and then my question is at the end:

Our high-level process for upgrades is as follows:

• First, we try to ensure that all users testing functionality in our sub-prod instances have completed their work before we start the upgrade process
• We then commit any modifications we have made in Dev and tested in Test to our Production instance
• After all work being performed has been tested and committed to production, we initiate a clone from production to Dev and Test
• After the clone is complete, we upgrade Dev and Test
• From there, we have multiple teams from our organization test out ServiceNow functionality, identify any issues or changes that may require training and share their findings
• We then implement fixes, develop training, or send communication regarding expected changes in the upcoming upgrade
• We continue with remediation until we are comfortable with the state of Dev and Test
• Then we upgrade production and commit any update sets that we created to resolve issues in Dev and Test to our production instance

Issue:

While we try to ensure that all testing is completed in Dev and Test before upgrades are performed, this is not always possible. This means we need to export XMLs from our Dev instance, and then import them back into Dev post-upgrade.

Question:

What are the best practices for retaining specific customizations in Dev when going through the full clone/upgrade process? Should we perform steps in this order?

• Export XMLs
• Clone over Dev and Test
• Import XMLs
• Upgrade Dev and Test

Has anybody followed similar processes? What issues did you face?

Thank you 😊

[Mark Roethof]

Hi there,

Maybe I'm missing something, though are you not working with Update Sets? Or Source control? Or something else?
Exporting/Importing XMLs sounds weird.

Kind regards,
Mark

[Kirk4]

Hi Mark!

Yes. We do use source control, but in this instance the updates are not ready to be committed to production, and we are about to clone Prod over everything in Dev and Test. Since we don't want to lose these updates after the clone, we are exporting the related records as XML files, so that we can have them saved off outside of the application and can load them back in after the clone.

I would definitely appreciate suggestions though if there is a better way to go.

Thank you for the question

[Bert_c1]

Hi Kirk4,

You should be capturing changes in dev in Update Sets. Those that have not been promoted to the clone source instance need to be set to Complete, then exported. After the clone, import and commit those update sets.  for subsequent work on those, create a 'part 2' update set to complete the work, promote both update sets (or merge) when ready.

[Kirk4]

Thank you Bert. I'll definitely do that.

Do you think it is necessary to import the update set right after the clone and before the upgrade of Dev so that it's imported into the same version of ServiceNow that it was exported from?