System Clone Preserve Update Sets [Orlando]

Mark Roethof · ‎04-13-2020

Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

Hi there,

While cloning instances, you might encounter the "issue" of always having to backup your in progress Update Sets. Quite a bit of work, or hopefully you've (semi-)automated this. Now, with Orlando, Eureka! ServiceNow enhanced the System Clone process with a "Preserve Update Sets" feature!

Pre-Orlando

Pre-Orlando backing up Update Sets would mean for example:
1) Changing the state of the Update Sets to Complete;
2) Exporting the Update Sets to XML;
3) Importing the Update Sets after the System Clone has been executed;
4) Review and commit the imported Update Sets;
5) A best practice is not to reopen the Update Sets, so new follow-up Update Sets with a suffix "(2)", "(b)", etcetera would occur.

Another way could be:
1) Changing the state of the Update Sets to Complete;
2) Retrieving the Completed Update Sets on your production instance (uncommitted);
3) After the System Clone has been executed, review and commit the Update Sets on your development instance;
4) A best practice is not to reopen the Update Sets, so new follow-up Update Sets with a suffix "(2)", "(b)", etcetera would occur.

Orlando
When scheduling a System Clone (System Clone > Request Clone), on the System Clone record under the "Options" section there's a new field visible called "Preserve in Progress Update Sets". Options being "None" and "Last 90 days". This option basically "Preserves update sets during the clone process which eliminates the need to export in-progress, global update sets before you initiate a clone. The default is none. You can select the latest 90 days to preserve the in-progress update sets during this time."

Read more about this on the ServiceNow Product Documentation page:
Request a clone

Note

Important to be aware of:
1) The Preserve In Progress Update Sets only concerns Global scoped Update Sets;
2) After the System Clone has been performed you still would need to review and commit the Update Sets, similar like you were used to Pre-Orlando. So there's still some manual work left, and you would still get new Update Sets with a suffix like "(2)", "(b)", etcetera.

---

And that's it actually. Hope you like it. If any questions or remarks, let me know!

C	If this content helped you, I would appreciate it if you hit bookmark or mark it as helpful. Interested in more Articles, Blogs, Videos, Podcasts, Share projects I shared/participated in? - Articles, Blogs, Videos, Podcasts, Share projects - Experiences from the field

Kind regards,

Mark Roethof

ServiceNow Technical Consultant @ Quint Technology
1x ServiceNow Developer MVP

1x ServiceNow Community MVP

---

CSkaggs · ‎07-21-2020

Thanks Mark. We have cloned our QA instance with this option of Preserve In Progress Update Sets but not seeing them in Local Update Sets afterwards.

Can you please provide more details for:

2) After the System Clone has been performed you still would need to review and commit the Update Sets, similar like you were used to Pre-Orlando. So there's still some manual work left, and you would still get new Update Sets with a suffix like "(2)", "(b)", etcetera.

Do we need to then go into Retrieved Update Sets and look for these Preserved, In Progress Update Sets and re-commit them? And what about the suffix you described? I'm not seeing this or understanding.

Thank you.

drewc · ‎09-22-2020

Here's to hoping this gets expanded to scoped apps.

Jim Coyne · ‎09-22-2020

Indeed, because, to be honest, not a very useful feature without that support.

mholmes · ‎10-06-2020

This looks like a great feature!

I have two questions:

1) What does "from the last 90 days" mean, exactly? Created in the last 90 days? Updated in the last 90 days?

2) How does this interact with the "Default" update sets? Do they need to be marked "Ignore" in the target instance before cloning? Any special considerations so they don't collide with their cloned counterparts? Or are they just ignored regardless?

krystaberry · ‎10-09-2020

You may find this HI Article helpful on reviewing and committing - https://hi.service-now.com/kb_view.do?sysparm_article=KB0827916

Kyle Krick · ‎11-12-2020

I'm wondering the same thing. Did you have any luck figuring out where update sets go after being preserved in a clone?

Mark Roethof · ‎11-12-2020

Hi there,

Indeed you would need to commit those update sets, just like when not using this preserve option.

Suffix don't really understand the question. It's just like when you have committed update sets, don't reopen them. Instead, if you have for example an update set for STRY0012345 - Some change, create a new update if you where still working on that story, an update set with name STRY0012345 - Some change (2), or (b).

Kind regards,
Mark

Les1 · ‎06-29-2021

Like some on this thread, I tried using the Preserve update set function. The update set i'm looking for is totally missing. I have looked for the update set in Retrieved Update sets and its not there. All i can figure is if it was "too old" ? i mean it was In Progress, but does the "last 90 days" of the Preserve Update Set feature mean Created On date? Last Updated date? Sometimes development is a slow simmer process!

Mark Cheek · ‎11-30-2021

Being able to do this with completed update sets would also be very nice. Frequently we'll be in a situation where we have update sets that have been completed in our non-production instances but haven't yet been moved to production, so accounting for them is a real pain.

MikeWilsonNYC · ‎03-31-2022

2 years later, still hoping...

Shivani33 · ‎07-06-2022

Hi All,

This is really helpful. However, I would like to know is there a way to expand to scoped update sets.

Thankyou