OBLYTECH Logo
Enquire Now
OBLYTECH Logo

ServiceNow / Practical guide

ServiceNow Upgrade Planning for Operational Continuity

ServiceNow upgrade planning is more than scheduling a platform change. It is the work of understanding what the organisation depends on, how customisations and integrations behave, what users need to know, and how the team will respond if the result is not as expected.

For ServiceNow platform owners planning an upgrade while protecting operational continuity..

ServiceNow upgrade planningupgrade readinessServiceNow testing
Discuss this ServiceNow topic

Guide map

Scheduling ServiceNow Upgrades Around Live Operations

Define what continuity means for the service

Continuity means the users who depend on a service can still complete their normal tasks throughout the upgrade window, not just that the platform stays online.

Inventory customisations and dependencies

Write down which services must keep running during the upgrade, and the longest interruption each one can tolerate.

Test workflows, integrations, and access

Run each critical workflow as a user with the same roles as production, since permission changes are a frequent source of surprises after an upgrade.

The practical framework

Plan a ServiceNow upgrade around customisations, integrations, data, testing, users, rollback, communication, ownership, and post-upgrade review.

Operational continuity should be defined before the plan becomes a checklist. Which services, workflows, reports, integrations, and support paths must remain usable?

Define what continuity means for the service

Identify the critical user journeys and decisions that must work after the upgrade. A technical health check may pass while a request catalogue, approval, notification, report, or integration has changed in a way users cannot operate.

Set the acceptance evidence and owner for each important path. The ServiceNow performance tuning and upgrades service is the relevant internal route when an upgrade needs platform and operational review.

Inventory customisations and dependencies

Review custom logic, integrations, roles, reports, data rules, scheduled work, and user-facing templates. The inventory should identify ownership and usage, not simply list technical objects.

Look for dependencies that are undocumented or maintained by one person. A change can be technically compatible and still create support risk when no team knows why a customisation exists.

Test workflows, integrations, and access

Test real workflows and exceptions: request, incident, approval, assignment, reporting, integration failure, permissions, notifications, and recovery. Compare expected and actual results and record open decisions.

Do not rely on a demonstration of the happy path. The ServiceNow implementation service provides the related internal delivery route when upgrade testing sits inside a larger programme.

Plan communication and support

Users need to know what is changing, when the change affects them, and where to report a problem. Support teams need the known changes, validation evidence, escalation path, and owner for each critical issue.

Communication should not promise an outcome the test evidence cannot support. State what is known, what is being checked, and when the next decision will be made.

Make rollback and post-upgrade review concrete

Rollback should identify triggers, owner, dependencies, data effects, and validation after recovery. The team should decide when rollback is safer than continued diagnosis and what happens if rollback is not available.

After the upgrade, review incidents, failed workflows, user questions, performance signals, and deferred items. The platform upgrades and enhancements service is the internal route for controlled follow-up work.

Common questions

Questions teams ask about upgrade planning

Is testing the same as upgrade readiness?

No. Testing provides evidence for selected paths. Readiness also includes ownership, communication, support, dependencies, rollback, data, and a decision about open limitations.

When should rollback be considered?

When the observed result threatens an agreed continuity condition, the response path is understood, and recovery is safer than continuing the current state. Define the trigger before pressure makes the decision unclear.

The research-grounded boundary

An upgrade decision is easiest to defend when the reasoning is written down at the time. For ServiceNow upgrade planning, record which services, customisations and integrations were judged at risk, the evidence behind each judgement, and who approved moving ahead. For upgrade planning operational continuity, the final test is whether another responsible person can reproduce the decision from the retained record.

Define continuity before the upgrade plan

An upgrade plan built from a vendor checklist tells you what to test. A continuity definition tells you what must keep working for the business to carry on. Start with the services, workflows and support paths that cannot stop for long: the request catalog a payroll team relies on, the approval chain for purchases, the incident routing the service desk depends on, the integration that feeds a finance report. Each entry becomes an acceptance path with a named owner. Technical health checks can pass while one of those paths quietly fails, so the continuity list should drive the test scope.

Path typeWhat a failure looks like to usersAcceptance evidence
Request submission and approvalRequests stuck in a stage with no notificationA test request completes every approval stage
Incident routingRecords assigned to an inactive groupSample incidents route to the expected group
Integration to a finance or HR systemRecords created twice or not at allReconciled sample with counts and identifiers
Scheduled reports used for decisionsTotals differ from the prior period without explanationComparison against a signed-off baseline
Customization with a single maintainerBehavior changes with nobody able to explain whyOwner confirms intended behavior in writing

Inventory what the platform depends on

An inventory of customizations is a common first task, and it often produces a list of objects with no information about use. Add three attributes to each item: the owner, the business process it supports, and the date it was last used. A scheduled job that last ran a year ago and that nobody can name is a candidate for removal before the upgrade, not a risk to test. A business rule every request depends on needs a full regression check. The inventory should answer which items the business relies on and who would notice if they broke.

Look especially for dependencies that exist only in one person’s knowledge. A customization may be technically compatible with the new release and still create support risk if nobody knows why it exists. Record the reason in the inventory before testing begins.

A procedure for the go or no-go decision

  1. Confirm the continuity paths, owners and acceptance evidence are complete.
  2. Run the critical path tests in a production-like environment and record results against expectations.
  3. Review open defects by their effect on the continuity paths rather than by count.
  4. Confirm user and support communication is ready, covering what is changing and where to report problems.
  5. Agree the rollback triggers, the rollback owner and the data effects of reversing the upgrade.
  6. Record the decision, the accepted limitations and the review date for those limitations.

Set the rollback trigger before the upgrade window opens. Under pressure, a team without an agreed trigger keeps diagnosing a fault long after continuing has become the more dangerous choice. The trigger should name an observable condition, such as a critical path failing its test after a defined fix attempt, and the person who can call the rollback.

Communication users can act on

Users need three things: what will change, when it will affect them, and where to report a problem. Avoid promising outcomes the test evidence does not support. A message that says the new interface is faster will be judged against the first slow page. Support teams need a different message: the known changes, the validation evidence for each critical path, the escalation route, and the owner of each open issue.

After the upgrade

The post-upgrade review is where hidden dependencies surface. Review incidents and failed workflows from the first two weeks, user questions, performance signals and the list of deferred items. Deferred items need an owner and a date, or they become the next upgrade’s surprise. Feed the lessons back into the inventory so the next cycle starts from a better record. Hypercare should end on a stated condition rather than on a calendar date alone.

Questions about upgrade readiness

Can an upgrade be tested without a full copy of production data?

A representative copy is usually more reliable than a small sample, because many faults depend on data volume and combinations of records. If a full copy is not practical, the sample should include the records behind each critical path and the edge cases the business has reported.

Should customizations be removed before the upgrade?

Remove the ones nobody uses or can justify. Removing customizations that are still used simplifies testing but moves the risk into the business process they supported, so each removal needs a decision and a communication.

When should an upgrade be delayed?

When a continuity path has no acceptance evidence, when a critical customization has no owner, or when support cannot absorb the expected change. Delay for a stated set of reasons, record them, and set a date for the next decision.

Does a passing automated test suite mean the platform is ready?

It means the covered cases behave as expected. Readiness also depends on the uncovered paths, the data, the dependencies and the people who will support the change afterwards, so the suite is one input among several.

Planning the next upgrade around proof

If your next platform upgrade is being planned from the release notes alone, a continuity review is one practical way to find the paths that need proof. Contact OBLYTECH to plan your upgrade around operational continuity. The platform performance and upgrade readiness service covers the readiness work, and the upgrade compatibility guide covers compatibility issues in ServiceNow upgrades.

A practical next step

Need a clearer ServiceNow operating model?

OBLYTECH can discuss the questions raised by this guide and the next review step. See the ServiceNow consulting services page for the commercial route.

Useful starting pointBring the current question, scope, ownership concerns, and evidence needs into the first review conversation.

Review ServiceNow consulting

ServiceNow guides on this topic

Guides from the Oblytech ServiceNow library that explain the practice behind this page.

More from the blog

Related reading