ServiceNow Upgrades and Release Readiness: Roles, Responsibilities and RACI

Upgrade Program Manager: Coordinating the Upgrade

The Upgrade Program Manager oversees the entire upgrade project. Responsibilities: establish upgrade timeline and milestones, coordinate testing across teams, manage communications to stakeholders, escalate blockers, track readiness metrics. The manager ensures the upgrade stays on schedule and all parties are prepared. They are Responsible for overall upgrade coordination, Accountable for delivery, Consulted on major decisions, and Informed of blockers or risks. The manager is the single point of accountability for the upgrade; if anything goes wrong, they own it.

Upgrade Technical Lead: Testing and Validation

The Upgrade Technical Lead plans and conducts technical testing. Responsibilities: design testing strategy (unit tests, integration tests, performance tests, compatibility tests), execute testing in sandbox and staging environments, document test results, identify and escalate issues, recommend go-live or postponement based on test results. The lead is Responsible for technical readiness, Accountable for test quality, Consulted on testing plans, and Informed of business blockers. The lead’s recommendation carries weight: if they recommend postponement due to test failures, that recommendation should be respected.

Application Owners: Validating Business Functionality

Application owners test functionality relevant to their applications. Responsibilities: identify business-critical workflows to test, participate in testing, validate that functionality still works after upgrade, identify business issues, communicate to their teams. Owners are Responsible for business validation, Accountable for identifying show-stopping issues, Consulted on trade-offs (if an issue cannot be fixed before go-live, is it acceptable?), and Informed of upgrade status. Owners ensure the upgrade delivers business value, not just technical compliance.

Customization Owner: Compatibility Review

Custom configurations and customizations must be reviewed for compatibility with the new release. Responsibilities: inventory all customizations (configurations, plugins, scripts), research ServiceNow release notes to identify breaking changes, test customizations in sandbox, remediate incompatibilities, document what was changed and why. The owner is Responsible for identifying and fixing compatibility issues, Accountable for customization readiness, Consulted on whether to keep or remove customizations, and Informed of release notes and breaking changes. Customizations that are no longer needed should be removed during the upgrade; customizations that have incompatibilities must be fixed before go-live.

Stakeholder Communication Owner

Someone must manage communications: when is the upgrade, how long will it take, what will users experience, what changes will they see? Responsibilities: prepare communications for users, managers, and leadership, coordinate message timing (announce early enough for people to prepare, not so early they forget), address frequently asked questions, escalate user concerns to project leadership. The owner is Responsible for communication planning and execution, Accountable for messaging accuracy, Consulted on announcement timing, and Informed of user concerns. Good communication reduces anxiety and increases adoption after the upgrade.

IT Operations: Cutover Execution

IT Operations coordinates the upgrade with ServiceNow: the vendor applies the release to each instance in a window scheduled through the support portal, and operations validates the instance afterwards and resumes integrations and scheduled jobs. Responsibilities: create a detailed cutover runbook (step-by-step upgrade procedure), rehearse the cutover in sandbox multiple times, confirm that integration endpoints and MID Servers are ready for the window, agree the recovery plan with ServiceNow support since a release family upgrade cannot be rolled back by the customer, oversee the cutover, monitor the system immediately after. Operations is Responsible for cutover execution, Accountable for on-time completion and system stability, Consulted on infrastructure requirements, and Informed of any technical issues. An operation that seems routine often encounters surprises; rehearsal catches most surprises.

Example RACI for Upgrade Decisions

Approve Upgrade Timeline: Program Manager Responsible, CIO or IT Director Accountable, Technical Lead and Application Owners Consulted. Approve Test Plan: Technical Lead Responsible and Accountable, Application Owners Consulted. Identify Compatibility Issues: Customization Owner Responsible and Accountable, Technical Lead Consulted. Approve Go-Live Date: Program Manager Responsible, CIO Accountable, Technical Lead and Application Owners Consulted. Execute Cutover: IT Operations Responsible and Accountable, Program Manager Informed. Post-Upgrade Validation: Application Owners Responsible, Technical Lead Accountable, IT Operations Informed.

Stakeholder Engagement and Communication

Successful upgrades require stakeholder engagement throughout. Business sponsors must understand what functionality changes with the upgrade, what benefits they will see, and what adoption effort is required. Application owners must understand which configurations may break and require fixes. Users must understand what will change in their experience, why the upgrade is necessary, and what training will be provided.

Communication should start early: announce the upgrade plans months in advance, provide updates regularly, and increase frequency as the upgrade date approaches. Final week before upgrade, send daily updates. Address concerns promptly: if a stakeholder worries about a specific functionality, confirm it has been tested and will work after upgrade. Testimonials from early adopters help: if another department already upgraded successfully, their perspective is valuable to skeptics.

Map decisions to people before mapping tasks to people

A responsibility matrix usually starts with activities: test the integrations, communicate with users, run the cutover. That order produces a long grid that looks thorough and still leaves the hard moments unassigned. The moments that matter are decisions: whether to proceed when one test area is red, whether to accept a known defect for go-live, whether to pause the cutover when the rollback clock is already running. Start with a short list of those decisions, name the person who decides each one, and only then fill in the work that feeds them.

For each decision, record three further things: who can stop it, who must be told before it is made, and who is told afterwards. The stopping right is the one teams forget. A testing lead who has no authority to halt a cutover, however bad the results, has a role in name only, and that gap usually appears at two in the morning when the window is closing.

Read the table as a prompt for your own list rather than a template to copy. A large program may split the stop right across several roles, while a small team may need one person to hold two seats. What matters is that the decider is not the only person who can say no, and that the person who can say no has the evidence to do it.

Settling disagreements before the cutover window opens

Many arguments in upgrade programs are not about facts. They are about risk appetite, and the people involved hold different views on what a tolerable defect looks like. A business owner may accept a cosmetic fault that a technical lead considers a warning sign for something worse. Neither view is wrong, which is why the tie-break rule has to exist before the disagreement does.

A workable rule states who breaks a tie, what evidence is needed to reopen a settled point, and how quickly the decision must be made. Keep the rule short. A rule that depends on a committee vote will be too slow for a live cutover, and a rule that leaves everything to the sponsor will be ignored when the sponsor is unavailable.

Running the role model with a small team

Smaller teams often cannot staff every seat. The usual result is that one person is at once the technical lead, the release coordinator and the person who writes the communications. That arrangement works when the combined roles are named openly, because the person can see where one hat conflicts with another. The most important conflict to avoid is the one where the author of a change also approves its production release. The safeguard is a second pair of eyes on the approval, even when the second person is a peer from another team.

1. Write the decision list and confirm each decider with the sponsor in one sitting.
2. Name the stop holders and confirm they have the access to act, not only the authority.
3. Agree the tie-break rule and the time limit for it, and put both in the cutover runbook.
4. Confirm who may call rollback and what the first three actions are once the call is made.
5. Rehearse one contested decision in the sandbox so the group knows how the rule feels under pressure.
6. After the upgrade, compare what happened with the decision list and update the list for the next cycle.

Signs that the roles are not working

• Decisions are made in a chat thread and nobody can say afterwards who approved them.
• The same person is asked to decide on test results they helped produce.
• A stop request is raised and nobody acts on it because the decider is in a meeting.
• The operations lead learns about the go-live date from a user, not from the program.

Questions about roles in upgrade programs

Should the vendor hold any of these roles?

A vendor can advise on the decision and supply evidence, but it should not hold the final decider role for your business. Keeping that role inside the organization means the people who carry the outcome also make the call.

How many people should hold a stop right?

Enough that a single absence does not remove the ability to halt, and few enough that a stop is not casually called. Two or three named holders with a defined trigger usually works better than a long list.

What if the sponsor is unreachable during the window?

The runbook should name an alternate for each decision, and the alternate should have been briefed beforehand. Relying on someone to answer a phone at a critical moment is a plan that tends to fail.

Does this model change after the upgrade is complete?

The stop rights end when the stability review is signed off, but the decision list survives as the basis for the next upgrade and for any emergency change that follows a similar pattern.

For the wider picture of how these roles fit the governance of the platform, see the upgrades and release readiness governance model. The change approval side of the same decisions is covered in the note on change review decision-making.