Cloning - and Update Sets Duplication

[Jason Stuart]

Good Morning,

        We have recently cloned an instance in ServiceNOW.  The Clone went fine.  We ran into something we did not expect - and this was Update Sets.  Here is the scenario. Our typical deployment goes from Dev -> Test -> Prod

We cloned Prod to Test

After the clone, I went in and created a new Remote Instance for my Update Source pointing it back to Dev.  So, Test -> Dev.  

I then did a retrieve update set, which behaved weird. It pulled back update sets, but seemed to duplicate those that already existed in DEV2 - and it did not do it for ALL OF THEM.  Why would there be duplicates?  The ones in test that had been duplicated were already completed.  It pulled them in as previewed.

Any reason why this would happen?

[Alberto Consonn · Accepted solution]

Hi,

have a look at the solution provided in the thread below:

Cloning Instances and Update Sets

It might be helpful to understand the best practices in that case.

If I have answered your question, please mark my response as correct so that others with the same question in the future can find it quickly and that it gets removed from the Unanswered list.

Thank you

Cheers
Alberto

[Jason Stuart]

Alberto, thank you for the reply! I have seen this.  The issue is that it duplicated update sets.  For example, the update set was completed prior to clone in production.  So when it cloned to our test instance, it was marked as committed.  When I ran a Retrieve Completed Update Set from Test (which again connects to DEV), it returned a new version of the completed update set as Previewed.  

[Alberto Consonn]

Have a look here:

https://docs.servicenow.com/bundle/geneva-custom-application-development/page/build/system_update_se...

Never change the Update Set field value (update_set) in a Customer Update record (sys_update_xml). If a customization is made in the wrong Update Set, take the following action:

1. Switch to the desired Update Set.
2. Modify the object (record) that was originally changed. You can make a trivial change, such as adding a field.
3. Save the record.
4. Back out the change just performed, and then save the record again.

   This action ensures that the latest version of the object is included in the desired Update Set and prevents duplicate updates for the same object in a single Update Set.

[Jason Stuart]

Thank you, do you think this may have something to do with the following?

Set completed Update Sets on the production instance to ignore. This state ensures the Update Set is not reapplied when cloning the instance.