ServiceNow Certification Mock Exams
Click To View Now
-min.jpg)
If you're new to ServiceNow, you may have heard your coworkers talking about 'moving update sets' between Dev, Test, Prod or any other instances.
For me personally, I remember this sounding like a daunting task. Luckily, it's a simple process and once you do it a few times, you'll be a pro at it.
In this post, we'll go over the two most common methods for moving update sets between instances in ServiceNow.
Before we discuss how to move update sets in ServiceNow, let's discuss why you'd even need to move your update sets.
When you're developing in ServiceNow, you don't want to make a change that could cause your customers entire instance to shut down (if you like them, at least!).
To protect from this, most implementations will have at least 3 different environments. These environments are generally called Dev (development), Test and Prod (production). Let's break these down a little more:
In most implementations, it goes as follows: the developers will work in Dev, then when a story is ready to be tested (either internally or by the customer), the developers will move their updates (via Update Sets) to the Test environment. Once the story has been successfully tested, the updates can then be moved to Prod (you guessed it, via an Update Set!), which will make the changes live and ready to be used by the customer.
Okay, now that we know why we'd want to move an update set - let's get into how we can actually do it!
The first method we'll discuss is using XML. Technically, both methods use XML, but with this method we'll be using the XML file directly.
This method is pretty straightforward, and involves exporting the XML from one instance and importing it into another.
Note: if you're not familiar with what XML is, it's the file format and markup language that ServiceNow uses to transfer data. While it's not super important that you understand it as a beginner, it's definitely a good idea to learn about it. The ServiceNow Docs on XML and the W3 Schools tutorial are a great place to start.
To migrate your update sets using XML, you'll do the following:
Move your update set to a state of 'Complete'. You cannot export the XML for an update set unless it has been marked Complete. Once you do that, you'll get a new Related Link called 'Export to XML' as shown below:
Alternatively, you can right click in the form header to open the Form Context Menu, and then go to Export > XML (This Record) as shown below:
When you export the XML (using either option), the update set will be downloaded to your computer. Keep note of where it gets stored, as you'll need the file to re-upload it in the next step.
Once you've exported the XML, you're ready to upload it into the new environment. Start by going to the environment that you'd like to move the update set to. Once you're there, navigate to System Update Sets > Retrieved Update Sets in your application navigator as shown below:
On the Retrieved Update Sets list view, click on the 'Import Update Set from XML' Related Link, which is located at the bottom left of the screen:
On the next page, you'll be prompted to choose a file to upload. Select the the XML export of your update set, and then click the 'Upload' button. Once it uploads, you'll see it in the Retrieved Update Sets list.
Click on your update set in the list, and then click 'Preview Update Set'. The preview is going to compare your updates to the new instance to detect potential problems. If there are no issues with your update set, then you should see a message like below:
Note: if there are errors, then you will have to either 'skip' or 'accept' your update. What this means is that the environment that you're migrating to has a newer version of what you're trying to upload. This can happen for numerous reasons, but you'll have to work though each individual error and make sure you want your update to be uploaded. In some cases, this may mean talking to other developers on your team who may have made more recent changes, or talking to a product owner to see which change they need to be promoted.
If there are no errors, or once you've resolved them all, go ahead and click 'Commit Update Set'. The commit is going to actually upload your update set (whereas the preview simply tested it to make sure there were no issues).
Similarly to the preview step, if there are no issues committing your update set, then you should see a message like below:
And that's it! You've officially moved your update set to a new instance. To verify that everything went in smoothly, you should always check the new environment to make sure your updates are working properly (i.e. if you added a new field to a form, go make sure that field is there).
In the next method, we'll discuss how you can move update sets without exporting and importing XML.
The second method we'll discuss involves retrieving the update set from a remote instance. In order to do this, you'll have to make sure that a remote instance is configured as a source instance. Usually this is done by a platform team or the architect/senior level developer on your team. If you're not sure if this is configured, it's probably best to ask them.
To migrate your update sets using Update Sources, you'll do the following:
Navigate to System Update Sets > Update Sources in your application navigator as shown below:
Choose the remote instance that you'd like to retrieve your update set from (if you're in Test, then this will probably be Dev. If you're in Prod, this will probably be Test).
Once you're on the remote instance form, click the 'Retrieve Completed Update Sets' UI Action as shown below:
This will retrieve all completed update sets from your source instance. Once the retrieval is complete, you'll see a success message.
Next, go to the 'Retrieved Update Sets' related list:
Find your update set, and click into it. It should be in a state of 'Loading'.
Once you've clicked into your update set, click the 'Preview Update Set' UI Action. The preview is going to make sure that your update set doesn't have any changes that will cause issues in the new environment. If there are no issues with your update set, then you should see a message like below:
Note: if there are errors, then you will have to either 'skip' or 'accept' your update. What this means is that the environment that you're migrating to has a newer version of what you're trying to upload. This can happen for numerous reasons, but you'll have to work though each individual error and make sure you want your update to be uploaded. In some cases, this may mean talking to other developers on your team who may have made more recent changes, or talking to a product owner to see which change they need to be promoted.
If there are no errors, or once you've resolved them all, go ahead and click 'Commit Update Set'. The commit is going to actually upload your update set (whereas the preview simply tested it to make sure there were no issues).
Similarly to the preview step, if there are no issues committing your update set, then you should see a message like below:
And that's it! You've officially moved your update set to a new instance. To verify that everything went in smoothly, you should always check the new environment to make sure your updates are working properly (i.e. if you added a new field to a form, go make sure that field is there).
Migrating your update sets between instances is like riding a bike - once you learn how to do it, it becomes really easy! However, if you're new to it, then it can definitely be tricky. All developers go through beginner mistakes and have to learn how to migrate update sets, so don't feel discouraged if you're having trouble.
We hope this article can be something you refer back to as you're moving your update sets in ServiceNow. If you have any questions or need help, don't hesitate to reach out to us at servicenowresource@gmail.com.
Thanks for reading!
