The Kingston release of ServiceNow is upon us and with it, the deprecation of support for Helsinki. In practice, this means a lot of businesses are upgrading from Helsinki to Kingston and dealing with the big changes between these versions, which include machine learning, refined end-user experience and major incident management.
In the past we’ve helped many clients to upgrade, ranging from small to global organisations in various sectors. In this way, we’ve gained a real depth of knowledge about the practicalities of upgrading to the latest version of ServiceNow, from Fuji to Istanbul, Geneva to Jakarta, and so on.
Here are our 5 top tips for upgrading ServiceNow to Kingston:
1. Get everyone on board
Early, clear communication across the business is vital to the success of any upgrade. You need to explain what is happening and why, in order to set expectations for resource requirements, particularly for people to assist in process testing the platform, along with anticipated outages and what’s coming in the way of new features.
The key is to ensure that internal resources are planned in and available, and to maintain regular and clear communications between developers, the technical team and BAs with regards to requirements and timeframes. Upgrading is a significant piece of work but it doesn’t have to be long-winded.
Our top tip: Keep the timeline for the upgrade as short as possible, to ensure fewer outages and less disruption for the business. Smaller organisations should be planning for around two weeks, while larger businesses are looking at a maximum of one to two months.
2. Don’t overcomplicate things
Keep things simple. Our experience of lots of upgrades of various sizes is that there’s no need to test everything – only the things that have impact. Concentrate on new functionality and don’t spend time worrying about bug fixes to your existing system – this is a real time waster.
We also find that keeping things straightforward is also the best approach when it comes to Release Notes analysis. You simply need to work out what’s changing and whether anything needs turning off (e.g. new functionality the business may not be ready for).
Our top tip: Skip logs of items you’ve previously customised can run to thousands of items and can be both time consuming and tedious.The best tactic is to split the logs into sections so they are easier to manage. Ignore any reports, notifications and form layouts and focus on the business logic, such as Business Rules and Script Includes.
3. Get your testing right
Having a solid plan in place for testing is crucial. The best approach is to undertake the initial unit testing by both developers and BAs. Following this, business testing by process owners or the already agreed business resources allocated to the task.
In both cases, fixes should be implemented afterwards by developers before moving on to the next round of testing. It’s also important to manage regression testing packs and ensure they are up to date.
Our top tip: Implement a process to carefully segregate existing defects in your configuration from those introduced by the upgrade. Without this, you can spend more time on triage of existing defects than on actually doing the upgrade.
4. Plan your development freeze early
Freezing development while upgrading is essential because as soon as you change something you make the testing you’ve done so far redundant. The key is to get the business on board early with a full understanding of the situation, otherwise they will be clamouring for BAU changes in the middle of the upgrade.
Before upgrading, clone back from Production to ensure all your environments are synced. Good communication around exactly when this will occur is vital – people will lose work if they aren’t expecting it.
Our top tip: We recommend running a minimum of three instances – Dev, Test and Prod. After upgrading, maintain a pre-upgrade version to refer back to if there are issues and to remove the pre-existing defect noise.
5. Take the opportunity to revert
Ensure there is time for technical teams to revert updates back to OOTB where possible. Analysis and testing of this requires planned effort but the savings realised increase with every upgrade undertaken.
Learn the lessons about which processes are more critical than others (not every item needs to be tested), and those areas where you were short on time and others where you had more than enough. Ensure you include feedback from both the business and internal developers, BAs and the technical team.
Our top tip: Upgrades are a fact of life and there will always be another on the horizon. Record what went well and what didn’t – and why – and use that as the basis of your next upgrade plan.
For more information or advice on your upgrade plans, contact us today – we’re always happy to share our experience and expertise.