ServiceNow Upgrades and Release Readiness Requirements Workshop Questions

This page sets out the questions to settle before a ServiceNow upgrade is planned. The questions cover the current version and upgrade cadence, the custom code and integrations that must still work, downtime tolerance and testing.

Current Version and Upgrade Cadence

What version of ServiceNow are you currently running? Is it a recent version or several versions behind? If you are more than 2-3 versions behind, you are exposed to security vulnerabilities and lack access to new features.

Answer impact: If you are significantly behind, the upgrade effort is larger. Each skipped version includes breaking changes that must be addressed. The first upgrade after multiple skips is risky. Consider a phased upgrade strategy: upgrade to an interim version first, then to the target version.

How often do you plan to upgrade? Annual upgrades are common and manageable. More frequent upgrades (biannual) keep you current but require sustained resources. Less frequent upgrades (every 18+ months) risk accumulating breaking changes.

Customization Inventory and Version Dependencies

What custom code exists in your instance? Inventory all business rules, workflows, client scripts, and API integrations. For each, document: what it does, which version-specific features it depends on, whether it will work after the upgrade.

Answer impact: A heavily customized instance has upgrade risk. Each customization is a potential compatibility issue. An out-of-the-box instance upgrades smoothly; a highly customized instance requires extensive testing and remediation. If customization inventory is not known, conduct it before planning the upgrade.

Do you have ServiceNow partner support, or are you managing upgrades internally? Partners often have upgrade playbooks and experience; internal teams may not. Budget accordingly.

Integration and Third-Party Connector Compatibility

What systems integrate with ServiceNow? List every integration: CRM, ERP, ITSM tools, communication platforms. For each, confirm the vendor supports the target ServiceNow version. Do any integrations need updates?

Answer impact: If any vendor does not support the target version, you may be blocked from upgrading until they provide support. Contact vendors early; give them notice of your upgrade plans so they can provide updates if needed.

Downtime Tolerance and Cutover Timing

How much downtime can your business tolerate? If ServiceNow is down for two hours on a Saturday, is that acceptable? What about during business hours? Business hours downtime is much more disruptive than weekend downtime.

Answer impact: Tolerance for downtime dictates cutover strategy. If you cannot tolerate any business-hours downtime, you may need parallel running (old and new versions running simultaneously for a period, with data synchronized between them). This is complex and expensive but preserves continuity.

When is the best time to upgrade? Identify low-activity periods (weekends, holiday weeks, off-season for your business). Plan upgrade during these windows to minimize impact.

User Communication and Support Readiness

Do users know an upgrade is coming? Have they been informed of what will change? UI changes, new workflows, and new features should be communicated before the upgrade so users know what to expect.

Answer impact: Communication and training prevent post-upgrade confusion. Users who are surprised by UI changes or new workflows will struggle and create support tickets. Pre-upgrade communication reduces support load post-upgrade.

Is the support team (help desk, platform support) prepared for the upgrade? They need to understand what changed and be ready to help users. Warning sign: if support team members are not aware of the upcoming upgrade or its scope, communication is not adequate.

Testing Strategy and Resource Allocation

Do you have a test instance that matches production? Testing the upgrade in a realistic environment requires a production-like test instance. If you do not have one, building it adds effort and time to the upgrade project.

How much time can you allocate for testing? Comprehensive testing takes weeks; abbreviated testing takes days. The less time you spend testing, the higher the risk of surprises in production.

Post-Upgrade Stabilization Period

Plan for a stabilization period after upgrade where issues are monitored closely and support is ramped up. The first week after upgrade is critical; bugs and issues often surface. Have extra staff available for support. Plan to defer non-critical work during the stabilization period so people are available to address upgrade-related issues. After a week of stability, return to normal operations.

Document all issues found during stabilization. Track whether issues are upgrade-related bugs, customization incompatibilities, or existing instance problems coincidentally discovered during upgrade. This documentation helps prioritize fixes and provides feedback to ServiceNow vendor about issues with the upgrade process. Post-stabilization, document lessons learned and improvements for the next upgrade cycle.

Make the output a log of outcomes, not a list of prompts

A question list is a prompt, and a prompt on its own rarely changes anything. What a requirements workshop has to produce is a record in which every question ends in one of three states: decided, deferred with a single accountable person and a revisit date, or rejected as out of scope for this upgrade. Anything still open when the room empties means the session has not finished, however productive the discussion felt. Set this expectation before the first slide, because many workshops drift into discussion and leave the recording of outcomes to a note-taker who is already tired.

The practical test is simple. Ask at the end whether a person who missed the session could read the log and know what the team has agreed, what it is still arguing about, and who is responsible for each open point. If the answer is no, the output is minutes, not a plan.

Matching attendees to the decisions they own

The people who answer the questions matter more than the number of people present. A useful room includes someone who can make a cutover call, someone who knows the custom code well enough to say which items are fragile, someone from operations who has handled outage calls, and a business representative for the process that cannot tolerate interruption. Sales or account contacts from the vendor side can answer product questions, but they should not steer the scope, and internal stakeholders who only want updates are better served by a short written summary afterwards.

Spotting answers that close a question without answering it

Some answers sound complete and carry no information. “We test everything” and “the vendor will tell us if something is wrong” are two common examples. Ask for the test list, or ask for the vendor’s confirmation in writing. A related trap is treating silence as evidence: “nobody has reported problems with that workflow” means there are no tickets, which is not the same as there being no problems. Check the incident history for the area before accepting the claim.

Where the workshop depends on memory, ask the owner to point to a record. A configuration export, a support ticket or a test result is a stronger answer than a recollection, and the log should note which kind of evidence each answer rests on.

A short procedure for running the session

The order below keeps the session moving and makes the output reusable for the test plan and the change record.

1. Send the question set and the inventory request well ahead of the session, so owners arrive with evidence rather than opinions.
2. Open with the stop conditions, so the group knows in advance which findings would delay the upgrade.
3. Take the question areas in dependency order, from the target release through to communication.
4. Record each answer in the decision log with its source and its status: decided, deferred or rejected.
5. Read the deferred items back aloud and give every one an owner and a revisit date.
6. Circulate the log and ask for corrections within a fixed window, after which the log becomes the baseline for the test plan.

The stop conditions deserve particular attention. Typical examples include no test instance that resembles production, an unresolved vendor position on a core integration, or a business peak that falls inside the planned window. The notes on release acceptance criteria are a useful reference for setting them. Writing these down before the session means the team is not negotiating them under schedule pressure, when everyone wants the date to hold.

Questions people ask after the workshop

How long should the decision log be kept?

Keep it until the upgrade has been stable for long enough that the post-upgrade review is complete, then archive it with the change record. Its value is highest in the next cycle, when the team can see which assumptions were wrong and which questions were never asked.

What if the business refuses any downtime at all?

Record that position as a constraint and bring the options back to the same group. Zero tolerance usually leads to a discussion of parallel running or a phased rollout, both of which cost more. The business should choose between those costs knowingly rather than discover them during cutover.

Should integrations be covered in the same session as the platform questions?

Cover the support status in the main session, then hold a separate working session with each integration owner. Integration testing involves different people and different evidence, and a single session tends to run out of time before the detail gets reached.

Who signs off the deferred items?

The person who owns the risk should sign off, not the person who raised the point. If the owner of a deferred item is unclear, the deferral is not finished, and it should go to the sponsor for a decision before the log is accepted.

The output of this session feeds the testing plan and the licensing review. Read the testing and acceptance checklist next, and take the deferred items from the log into the licensing and cost planning so that open points carry their owners forward.