ServiceNow Upgrades and Release Readiness Integration Patterns
Pre-Upgrade Integration Assessment
Before upgrading, audit all active integrations. Check ServiceNow API versions in use; if the new version deprecates an API, integration will break. Contact external system vendors: do they support the new ServiceNow version? Some integrations may require updating before the upgrade.
Likely integration issues: REST API endpoints changed, SOAP service signatures changed, authentication mechanisms updated, data format changes (date formats, field names). Assess each integration and estimate effort to update it if needed.
Integration Testing During Upgrade
In a test instance, test all active integrations after the upgrade. Run inbound integrations (pulling data from external systems into ServiceNow): confirm data is correctly ingested. Run outbound integrations (pushing data from ServiceNow to external systems): confirm updates are sent correctly. Run bidirectional integrations: confirm both directions work.
If an integration fails, diagnose: does the external system support the new API version, or does the integration code need updating? Fix the integration in the test environment before production upgrade.
Third-Party Integration Dependencies
Many integrations depend on third-party connectors (Salesforce integration, SAP integration, etc.). Before upgrading, verify that ServiceNow-provided connectors are compatible with the target version. If a connector is not compatible with the new version, vendors may have updates available. Apply updates before the upgrade.
Custom integrations: scripts and workflows that integrate with external systems may rely on version-specific features. Test custom integrations thoroughly in staging.
API and Webhook Updates
If your integration uses webhooks or custom REST APIs published by ServiceNow, check the API documentation for the new version. API changes are usually documented in release notes. Test with the new API before upgrading production.
For webhooks: if you subscribe to ServiceNow events (incident created, change approved), verify the webhook event structure is the same in the new version. If the structure changed, subscriber code may break.
Data Synchronization and Reconciliation
After the upgrade, check that data synchronization is working correctly. Run a data reconciliation: compare counts between ServiceNow and external systems. If counts are off, something is wrong with data flow post-upgrade. Investigate and remediate before resuming normal operations.
Schedule reconciliation jobs to run automatically post-upgrade so discrepancies are caught and alerted on.
Cutover Strategy for Integrations
If upgrades require integration changes, coordinate the upgrade and integration changes carefully. Option 1: upgrade, then update integrations afterward. This risks data loss if integrations fail during the upgrade. Option 2: update integrations first (in the current version), test them, then upgrade. This ensures integrations are ready before the upgrade happens.
Option 2 is usually safer: get integrations working with both the old and new versions if possible (compatibility mode), then upgrade. After upgrade, remove compatibility logic and use only the new version APIs.
Vendor Support Verification
Before planning an upgrade, contact each third-party vendor whose connector or integration is in use. Ask: does your product support ServiceNow version X.Y? What changes are required? Will you provide support if issues arise? Document vendor responses and support status for each integration point. This inventory prevents surprise incompatibilities discovered during testing.
Integration Compatibility and Backward Compatibility
When upgrading, consider whether integrations can work with both old and new versions. Some changes are backward-compatible (new API version continues supporting old endpoints). Others break backward compatibility (old endpoints are removed). Understand which integrations can be updated incrementally and which require synchronized cutover with the ServiceNow upgrade.
Data Migration and Integration Testing
Some ServiceNow upgrades include data model changes that require data migration in integrations. An integration that pulls user data may have the user table schema change in a new version. Identify such changes early and plan migration scripts. Test data migration in a staging environment with realistic data volumes to confirm the process works and performance is acceptable.
Rollback Strategy for Integrations
If an integration breaks during upgrade and causes critical data loss or workflow failure, you may need to roll back the upgrade or revert to a backup. Plan rollback strategy: how long can it take, what data will you lose, how do you communicate to users. Practice rollback in a staging environment so you understand the process before you need it in production under pressure.
Sorting integrations by what breaks first
Integrations do not all fail in the same way after an upgrade, and treating them as one group wastes test time. Some fail at the authentication step, before any data moves. Some fail at the message format, where a field has been renamed or a date is parsed differently. Others fail silently, because the call succeeds but the record it writes is no longer the one the other system expects. Sorting each integration by its most likely failure point tells the test team where to spend its first hour.
| Integration type | Most likely first failure | Check that exposes it early |
|---|---|---|
| Token-based connection to an external API | Expired or rotated credentials after a change to the authentication settings | A single authenticated call from the integration’s service account, before any batch runs |
| Scheduled import into a table | A transform map that no longer matches the source column names or types | An import of a small known file, followed by a field-by-field comparison |
| Outbound message to a third-party system | A message definition that sends a field the receiver now rejects | A test message captured at the receiver, not merely a success code from the sender |
| Event-driven notification to a subscriber | An event payload with a different structure from the one the subscriber parses | One real event triggered in the test instance, with the payload read by the subscriber |
| Integration through a mid-level server | A version mismatch between the server and the platform after the window | A connectivity and version check on the server before the window opens |
Keeping old and new behavior available during the change
The safest integrations can accept both the old and new behavior for a period. A receiver can be set to read either field name, or a sender can keep producing the old format alongside the new one until the receiver has been moved. This dual running needs a named end date and an owner who removes the old path. Left in place, a dual path adds to the things that can fail and makes every later fault harder to attribute.
- List each integration that relies on a field, format or endpoint the release notes describe as changed.
- For each one, agree with the other system’s owner whether dual running is possible, and what the receiver needs in order to accept both versions.
- Build the dual path in the current release, test it there and only then move to the upgraded instance.
- Remove the old path after the first full business cycle that uses the new one, and record the removal in the integration register.
Watching integrations after the window for silent drift
An integration can keep returning success while the data it moves has drifted. Counts between the two systems are the most direct check, but a count can match while the content differs. Sample a fixed set of records each day after the window and compare them field by field against the source. Where the two systems use different identifiers, keep a mapping table in the integration register so the comparison can be run by anyone on the team. The integration error handling note describes what a support team needs to decide what to do next once counts and samples show a fault.
Confirming the other side is ready before the window
Much of the risk sits with the party you do not control. Ask each external owner for a written statement of the versions they support and the changes they need from you, and file the reply against the integration. A vendor who answers only in conversation has not confirmed anything that a release lead can rely on at the go or no-go meeting. Where a connector comes from a third party, check whether it has been certified against the target release before the window, not after.
Frequently asked questions about integrations in an upgrade
Should integrations be upgraded before or after the platform?
Where dual running is possible, prepare the integrations on the current release first, so they accept both behaviors, and move the platform afterwards. Where it is not possible, the two must be scheduled as one change with a rehearsed rollback that covers both sides.
How much of the integration estate should be tested in each window?
Every integration that moves data for a critical process, every time. Lower-risk integrations can be tested on a rota, provided the rota is written down and each one has been exercised in recent windows.
Who should own an integration after its builder leaves?
A named owner on the team, recorded in the register, with the external contact’s details beside it. An integration without a current owner is more likely to fail quietly during a window.
The integration cutover readiness note covers what should be true before cutover starts.
Related guides: Performance Tuning & Upgrades.
Frequently asked questions
What should we do if an integration breaks during the upgrade?
Have a rollback plan ready. If an integration is critical and breaks post-upgrade, you may need to revert the upgrade and fix the integration in the current version first. This is why testing integrations before upgrade is essential; discovering issues in production is expensive.
How do we minimize disruption during integration upgrades?
Update critical integrations before the main system upgrade if possible. Use feature flags or configuration switches to enable/disable integrations, so you can disable a broken integration without rolling back the entire upgrade. Have a manual workaround for critical integrations (if data synchronization breaks, can you manually sync until the integration is fixed).
Should we update integrations gradually or all at once?
Update non-critical integrations first (low-volume, low-risk data flows). Test them, confirm they work, then update critical integrations. This reduces risk; if early integrations break, you have not yet touched critical data flows.
Related guides
Planning, running or fixing a ServiceNow programme? Tell us where you are and we will suggest a sensible next step.
Contact us