Everything you need to know about ServiceNow platform releases and how to ensure your upgrade experience is a success.
Like any investment, you want to be getting the best out of ServiceNow – and keeping up with platform releases is essential to do so.
However, the mere mention of a platform upgrade often triggers apprehension, conjuring images of downtime, disruptions and unforeseen challenges.
Not to worry. In our comprehensive guide, we dive into the world of ServiceNow upgrades, helping you understand their importance and arming you with the knowledge to navigate them with confidence.
What are ServiceNow upgrades?
Put simply, ServiceNow upgrades are the process of updating your ServiceNow platform to a newer version (or ‘family’). These upgrades typically include improvements, bug fixes, new features and enhancements to existing functionality.
As a cloud-based platform, ServiceNow regularly releases these platform upgrades to ensure you have access to the latest features, functionality and security fixes.
How often do upgrades happen?
Due to their size, scope and the work required to implement them correctly, ServiceNow family releases occur roughly every six months or twice a year – typically landing in March and September.
Whilst smaller patches and minor updates may be released throughout the year to address critical issues or vulnerabilities, these platform-wide releases are a much larger, more involved process that requires significant preparation and project management to complete.
Why do I need to upgrade ServiceNow?
There are several reasons why upgrading ServiceNow is important:
1. Access to new features and functionality
ServiceNow regularly introduces new features, enhancements and functionalities in its releases.
Upgrading ensures that you’re benefitting from the very latest capabilities for your products, which can improve productivity, efficiency and your user experience.
2. Security enhancements
Updates often include security patches and enhancements to address newly discovered vulnerabilities and threats.
Staying up-to-date with upgrades helps protect your organisation’s data and systems from potential security breaches.
Failure to keep on top of your upgrades could leave you exposed to an attack or data breach – and nobody (except the bad guys) wants that.
3. Bug fixes and performance improvements
Each platform release will come with a host of smaller fixes and improvements to resolve known bugs and performance issues identified in previous versions.
It’s best practice to apply these updates to keep your IT environment operating smoothly and efficiently.
4. Compliance
Many industries have regulatory and compliance standards that need to be adhered to.
A typical requirement for many of these standards is that your IT products are kept up-to-date and use the latest version or release.
If you fall behind in the upgrade schedule, not only will you be missing out on new features and fixes, but you could be in breach of your compliance requirements, too.
5. Vendor support
ServiceNow will support and assist you with both the current and previous releases. But fall behind by more than two releases and you’ll no longer be eligible for support and those all-important security patches.
To avoid putting your organisation at risk, you’ll need to upgrade at least once a year to continue receiving support such as documentation, training and technical assistance.
6. Compatibility with integrations and customisations
As ServiceNow evolves, older versions may become incompatible with newer integrations, applications and customisations.
You’ll need to account for any integrations and customisations you have as part of any release upgrade, but doing so will ensure key systems keep running vs. you being caught out by something breaking because it’s no longer supported.
Overall, upgrading ServiceNow regularly is essential for maintaining the security, reliability and functionality of your platform. It also ensures that you’re getting the full value from new innovations and improvements.
Want more insights on ServiceNow platform upgrades from our experts?
Book your free consultationServiceNow upgrade timeline
The current naming convention for ServiceNow releases is after place names or major cities.
Below is the timeline for existing and planned platform releases:
- Aspen, 2011
- Berlin, Q3 2012
- Calgary, Q2 2013
- Dublin, Q4 2013
- Eureka, Q2 2014
- Fuji, Q1 2015
- Geneva, Q4 2015
- Helsinki, Q2 2016
- Istanbul, Q1 2017
- Jakarta, Q2 2017
- Kingston, Q4 2017
- London, Q2 2018
- Madrid, Q1 2019
- New York, Q3 2019
- Orlando, Q1 2020
- Paris, Q3 2020
- Quebec, Q1 2021
- Rome, Q3 2021
- San Diego, Q2 2022
- Tokyo, Q4 2022
- Utah, Q2 2023
- Vancouver, Q4 2023
- Washington DC, Q1 2024
- Xanadu, Q4 2024
- Yokohama, Q1 2025
- Zurich, Q4 2025
What is the next ServiceNow release?
The next ServiceNow platform family release will be Xanadu in Q4 2024.
After that, Yokohama is scheduled to be released in Q1 2025.
What to expect during a ServiceNow upgrade
The impact a ServiceNow upgrade will have on your organisation will vary greatly depending on what’s being delivered.
If you’re operating multiple ServiceNow modules or products, the work required to plan and test the upgrade properly will be more extensive than if you’re only using ITSM, for example.
Similarly, if you have a heavily customised instance you’ll need to be far more thorough with your testing than if you’re predominantly using out-of-the-box configurations.
The more complex your upgrade, the more time and resources you’ll need to dedicate to appropriately project manage, test and communicate the process.
So no two upgrades will be exactly the same as every environment is unique – but working through your non-production instances, testing, fixing and validating before applying to production will always be the best approach.
Upgrading ServiceNow: The key steps to take
Each upgrade process will likely take you through the following stages:
- Phase 1 – Read the release notes and plan your upgrade
- Phase 2 – Prepare to upgrade your development instance
- Phase 3 – Verify configurations and schedule your development instance upgrade
- Phase 4 – Upgrade and validate the development instance
- Phase 5 – Upgrade and validate other non-production instances (if applicable)
- Phase 6 – Prepare to upgrade the production instance
- Phase 7 – Upgrade the production instance
Let’s look at each of these in a bit more detail.
Phase 1: Read the release notes and plan your upgrade
Before you get stuck into the upgrade process, it’s essential to read the release notes for the platform version you’re planning to move to.
Doing so will help you understand what’s new, what will change, and what needs to be tested. Knowing this information up-front will help you plan a safe and effective upgrade.
In particular, we’d recommend looking out for any items that you’ve previously customised that will be affected as these will be the most prone to break during the upgrade.
Phase 2: Prepare to upgrade your development instance
On your production instance, you’ll need to create a system clone and select your development instance as the Target Instance.
This allows you to simulate the upgrade on an accurate representation of your active configuration in a non-production environment.
As part of this phase, you should also:
- Identify the team of testers, users and stakeholders needed to validate functionality before and after the upgrade.
- Confirm any restrictions or limitations, such as change freeze windows that could affect the timing of any cloning, upgrades or testing.
- Create a comprehensive test plan outlining the scope, approach and timeline. Also, include how any defects will be identified and recorded during testing.
Phase 3: Verify configurations and schedule your development instance upgrade
When scheduling your development instance upgrade in the Now Support portal, it’s important to make sure that, as a minimum, the release family of the development instance matches that of the production instance.
This ensures that the upgrade happens in exactly the same way when you’re trying it out, and guides you on which release notes to review. Upgrading by two releases will give you many more features than upgrading by just one release!
Make sure that your development community is aware of what’s going on. Upgrades can impact in-flight development work and change how it works, so it’s best to pause or carefully manage other development while the upgrade goes in before resuming on the newer family release.
Once you’re happy that the instance is cloned and ready for development, you can schedule your upgrade! Now Support highlights the instances and upgrade versions available.
We recommend upgrading to the latest generally available patch or hotfix version, as this will contain the best build of the new family release with the fewest bugs.
Be sure to take note of the patch version you’re upgrading to and upgrade your production instance to the same version when the time comes!
Phase 4: Upgrade and validate the development instance
Once your upgrade is scheduled, you can track its progress with the Upgrade Monitor.
During this phase, you’ll need to resolve conflicts between the upgrade and any customisations you have in place.
The upgrade conflict resolution process is where the value of baseline functionality over customisation really pays off.
A minimally customised instance can be upgraded in a week – a heavily customised one, upwards of four weeks. A heavily customised instance requires more work to identify where ServiceNow’s improvements clash with the code and data model changes you’ve made; more testing to check the resolved conflicts have worked; and less agility in your organisation when adopting new features.
Those identified resolutions and fixes will then go into the latest version and your current update set, ready to apply to your other instances after they’re upgraded. By identifying your required update sets before you upgrade your higher-level environments, the process of exporting, importing and applying them to any other instances will be much easier.
Before and after upgrading, conduct smoke tests on your dev instance to identify and track defects or deviations from the pre-upgrade testing results. This will help you prepare any fixes that will be required once the upgrade is applied to your production instance.
How much do I have to test?
Different organisations have different testing requirements. In highly regulated industries running strict standard operating procedures you may wish to conduct exhaustive end-to-end tests of all your processes, whereas, for less critical infrastructure, a simple re-run of user acceptance testing may suit your requirements.
A typical test cycle for a ServiceNow upgrade normally lasts about two weeks. We see clients typically dedicating between one and three people per deployed product on a part-time basis, depending on the number of products deployed and the effort required.
At this point, you can re-use any automated tests that you may have set up using the Automated Test Framework (ATF) or other testing tools. This will save you a lot of testing effort and time.
Where can I find some testing scripts?
You should be able to reuse a lot of what you created when you first implemented your ServiceNow platform. Test scripts that were used during the original go-live can be executed again to make sure your existing functionality still works.
If you’ve built some ATF tests, you can re-run them again in the upgraded instance as they are designed to be release-family agnostic.
Should you be lacking either of the above, your process owners will be key to overseeing testing in the upgraded instance as they will be the ones that best know how their processes should operate.
You can use the release notes for each release family in the ServiceNow documentation to give you an idea of what to look out for, what’s been added, and what’s been removed.
Phase 5: Upgrade and validate non-production instances
If you have multiple non-production instances (you may have separate instances for testing and development, for example) you’ll need to repeat Phase 4 for each of them.
You may have your own terms or labels for these instances, but the process remains the same: clone, apply upgrade, note fixes, test, etc.
Best practice recommends working through your instances in a logical order, i.e., start with the instance furthest away from production and work towards your production instance.
Phase 6: Prepare to upgrade the production instance
Now that your non-production instances have been thoroughly vetted, tested and accurately represent your production instance, it’s time to prepare for the big one – pushing to production.
Key things to note when upgrading your production instance:
- Confirm with IT and management that all non-production instance defects have been fixed, validated and included in an update set.
- Ensure you have a solid change management process in place to track and communicate the upgrade and its impact throughout your organisation.
- Identify a suitable upgrade window. This usually falls out of normal work hours to reduce the impact on your users and services.
- Allow time within that window to run your test cases and validate that all integrations, key functionality and system performance meet your expectations.
We’d recommend allocating some time to respond to any errors within your upgrade window, just in case. No one’s going to complain if you complete the upgrade quicker than expected, but you can bet they will if it goes over your estimate.
Phase 7: Upgrade the production instance
To upgrade your production instance:
- Log in to Now Support
- Click ‘Instances’ in the left navigation menu
- Select the instance you wish to upgrade
- Then select ‘Upgrade Instance’ from the Actions menu
- Choose your chosen date and time for the upgrade and hit ‘Submit’
To validate the upgrade has been completed, head to the Upgrade Monitor or check the Upgrade Log in System Diagnostics for a notification that the upgrade has been completed.
Once the upgrade has been applied and validated, it’s time to apply your update sets, and fix scripts and perform that all-important UAT (user acceptance testing).
Smoke testing in production is always a good idea to sanity-check that the upgrade has gone smoothly.
If you’re subject to more stringent change management processes, operational acceptance testing (OAT) may also need to take place in production.
Need help with your ServiceNow upgrade?
Upgrading your ServiceNow instance sounds simple on paper, but the reality can be quite different.
As we mentioned above, it very much depends on the complexity of your instance and the extent of the preparation, testing and project management required. And that can be quite intimidating, whether it’s your 10th upgrade or your first.
Not to worry, we’re a dab hand at the upgrade process. If you want advice on how to approach your upgrade to ensure it’s a success, or simply want someone to handle the entire process for you, we’re here to help.
