ServiceNow is constantly evolving, with new features, functionalities, and security enhancements being released regularly. Keeping your ServiceNow instance up-to-date is crucial for maximizing its value, ensuring compatibility with other systems, and protecting your data from vulnerabilities. Oblytech’s Platform Upgrades & Enhancements services provide expert guidance and support to help you navigate the upgrade process, aiming for fewer risks and a smoother transition to the latest ServiceNow version.
We provide training and support to your team on the new ServiceNow features and functionalities, aiming for a smooth transition and user adoption.
We conduct thorough testing and validation after the upgrade to check that all functionalities are working as expected and that your data integrity is maintained.
A platform owner preparing for a release upgrade is weighing two costs that do not appear on the same budget line. Upgrading costs testing time, rework of custom code and a period of user disruption. Waiting costs the security fixes, feature gains and vendor support that the current release will eventually lose. The decision is seldom about the release itself. It is about the state of the instance on the day the upgrade would start. An instance with a clean inventory of custom code, a tested sandbox and named testers can move quickly. An instance with unknown customizations and integrations that no one has documented will take longer than the release notes suggest, however carefully the project is planned on paper.
A useful first judgment is therefore readiness rather than urgency. Ask whether the team can describe every customization that touches a core process, whether the integrations that depend on the instance are listed with their owners, and whether a sandbox copy of production exists for trial runs. If the answers are no, the work to be done before the upgrade is larger than the upgrade itself, and that work should be scheduled as its own item.
An upgrade test cycle is credible when it can show, for each area of the platform the business depends on, that the area was exercised after the upgrade and behaved as it did before. That requires a sequence. The order below describes how the cycle is usually framed, and it can be used to test whether a proposal includes each stage.
A frequent gap is in stage four. Teams test the screens they remember and miss the scheduled jobs and integrations that run without anyone watching them. Those are the failures that appear days after the upgrade and are hardest to trace back to it.
Not all customization carries equal risk. Some components are stable across releases and need only a check. Others depend on internal behavior that the vendor may change, and they need to be rewritten or reviewed in detail. A buyer should expect the impact review to rank components by risk rather than treat them as a single list.
| Component type | Why it is exposed during an upgrade | What to check first |
|---|---|---|
| Scripts that call internal APIs not documented for external use | Internal behavior can change without notice between releases | Confirm the call still exists and returns the same shape of result |
| Business rules that run on core tables | Changes to base tables or execution order can alter when they fire | Confirm the order and the conditions under which each rule runs |
| Client-side scripts and UI customizations | Changes to the form framework can break layout or behavior | Test every customized form on each supported browser the business uses |
| Integrations using stored credentials | Credentials and endpoint settings can be reset or invalidated | Test each integration with a live transaction, not a connection check alone |
| Scheduled jobs and reports | They run outside working hours, so failures can go unnoticed | Review the job history for the first full cycle after the upgrade |
The production window is the most exposed part of the process, and the plan for it should be written so that a tired team can follow it. The plan states the sequence of steps, who may approve a pause, the conditions that trigger a rollback, and the time after which a rollback is no longer practical. Many teams set that last point too late. Once users have created records under the new version, reverting becomes a data problem as much as a platform problem, and the decision needs to be made before those records accumulate.
The first days after go-live need deliberate attention. Monitoring should be watched more closely than usual, support staff should know which errors are expected, and a short channel should exist for users to report anything odd. Many upgrade defects are found in this period, and the speed of the response depends on whether the people who will fix them are already in place.
An upgrade is a natural moment to introduce enhancements, and it is also the moment when the most change can go wrong at once. A reasonable rule is to keep the upgrade itself to the changes needed for compatibility, security and supported functionality, and to hold new capability for a later release once the instance is stable. Where a new feature directly replaces a customization that carries high risk, it may justify inclusion, but that choice should be made in the impact review with the testers involved, not decided late in the project.
Upgrade support typically centers on the technical movement of the platform and the testing that proves it works. It usually does not decide whether the business should adopt a new feature, redesign a process that the upgrade exposes as inefficient, or change the licensing arrangement. It also does not remove the need for business owners to sign off their own processes. Where those questions arise during the project, they should be logged and handled as separate decisions, otherwise the upgrade timetable absorbs work it was never sized for.
Skipping is possible only within the limits the vendor supports for direct movement between versions. Where a skip is not supported, the instance has to move through intermediate versions, each with its own test cycle. The supported path should be confirmed before the plan is drawn up, not discovered during it.
That depends on the size of the customization, the number of integrations and how much of the regression testing is automated. A useful estimate comes from the impact review, which shows how many components need work. Any duration given before that review is a guess.
A failed sandbox upgrade is information. It shows a dependency or a customization that the impact review missed. The response is to diagnose the cause, correct it in the instance, and repeat the sandbox run before any production date is confirmed.
The business owner of each core process should sign off the processes they depend on, and the platform owner should sign off the technical result. A single sign-off from one role leaves gaps that surface after go-live.
If a release is approaching and the inventory is incomplete, the first useful step is a readiness check of the state of the customizations, integrations and sandbox before a date is fixed. Discuss your upgrade planning requirements. Upgrade work is one part of the wider service described in the support and maintenance overview, and the performance tuning and upgrades page is the related page for tuning work that often runs alongside.
The target release and the go-live window are separate decisions, and the target should be settled first. The target is the newest release the instance can reach on a supported path that still delivers something the business needs. The window is the period in which testing, cutover and heavier support can be absorbed without a clash with a close, a busy period or another freeze.
Teams often default to the newest release. A better question is which release returns the most value for the rework it demands. A release that closes a security gap the business has been carrying earns its place quickly. A release whose gains sit in modules nobody uses is a reasonable case for waiting one cycle, if the wait is written down with its reasons.
The window is usually set by the business calendar rather than the platform calendar. The usual constraints are the close for finance-facing processes, peaks in service desk volume, and changes already scheduled by other teams. Where those changes run through a formal process, see change governance and release management.
| Window option | What it offers | What it risks |
|---|---|---|
| Quiet period with low request volume | Fewer users affected if a rollback is needed | Staff leave often falls here and thins the testers |
| Straight after another large change | Shares an existing approval path | Defects from both changes blur together |
| Inside a month-end or quarter-end close | An orderly-looking calendar date | Heavy finance processing runs during the change |
Fix the window once three conditions hold. The platform owner has agreed the target release. Named testers for each core process are available for the whole test period. The business owners have confirmed in writing which hours they can lose, and they have agreed how business-owned validation will run before the window opens. If one is missing, move the date rather than shrink the testing. This avoids a go-live date fixed in a planning meeting and kept after the evidence stopped supporting it.
Scope and timing interact. The longer the gap between the current release and the target, the more change one project must reconcile. A single larger step often needs a longer test cycle than two smaller moves, though the supported path may leave no real choice. Record that judgment and its reasons so it can be revisited if early testing finds more change than expected. A readiness assessment before the date is fixed is a low-cost way to test it.
Guides from the Oblytech ServiceNow library that explain the practice behind this page.