Moving changes from one instance to another (update sets, anything else that works better?)

[Brian Whyte]

Questions about moving changes from one instance to another...

Seems like update sets are the way that changes made in one instance are meant to be moved from the instance that the changes were made and prototyped over to the target production instance.  If so, why is it that many times, these update sets don't work properly in the target instance or miss dependencies? I've noticed that if you start an update set and make it active and then make a significant number changes across a lot of different capabilities, it never seems to capture all the change when moving to the other instance.   Many times when importing the update set at another instance, it throws dependency errors out the wazoo.  Then, I find myself playing the game of figuring out what table that missing dependency is in and exporting lots of other XML file exports from various tables.  This is odd to me and seems like something that really needs to be addressed unless I'm doing something wrong.  In this case, both instances (development and production) are the same exact version. I know someone will ask.

Is there a better way to move changes from one instance to another that works even when there are lots of changes?  Is Service Now working on addressing this in a different way to make it easier to move changes from one instance to another?

[Zach Koch · Accepted solution]

When it comes to the base platform, update sets, whether through XML or Update Sources, is the main way that updates are moved across the environments. If you build a scoped app, you can use Source Control with something like Github, but for non scoped apps update sets are the main mechanism. Update sets don't capture everything in them, such as data, or in the case of Flow changes, it condenses the updates to one update record, so it definitely can be confusing to know what was captured and what wasn't. Application Scope adds another layer of complexity, as if you have a change in Global, and a change in another scope, both related to the same requirement, it can be challenging to get them all moved. In that case you can create a Global Batch update set, then make any update set you need to move, Global, or Scoped, and make your new Global Batch update set the parent. If ServiceNow is working on another mechanism to move Updates, I haven't heard of it.

Here is also a KB that can help determine what will be captured automatically (there are ways to push Data into an update set manually with a script or OOTB API) 

Update set KB 

[Brian Whyte]

Helpful, but real disappointed on how this works.  For the cost of this product, I do wish it was a full capture and I think this feature is a bit misleading.  I guess that's why three instances (DEV, QA, and PROD) is pretty important so one can figure out all the dependency mess when migrating from DEV to QA. 

[Zach Koch]

It definitely can be confusing and I can understand the need to capture more things more easily when desired. One of the main reasons that all Data isn't captured by default, like an Incident record for example, is that you could unintentionally bring over development/test records or other Data into your Prod environment that you don't want in there. If you have certain records, like the aforementioned incident record, you can do an Export to XML for all the records that are included in the filter you used to return the records. 

For example, my filter here on the incident table brought back two records. I can right click the column and hit Export, then hit XML to download a file of all the records. I can then do the same process in my target environment and go to that table, right click the column again and hit import, and then choose that XML file as the import file. You can use this to capture any Data records you want to move.