Consider this scenario: An unanticipated update went live, or a flawed script was loaded into your production instance, and now operations are not working as expected. The pressure is on to get it fixed quickly.
When critical issues like these occur, ServiceNow uses a fix-forward strategy—immediately implementing a patch, workaround, or new code to correct problems as they appear. This approach maximizes business continuity while minimizing the risk of data loss.
This article explains why ServiceNow uses a fix-forward strategy rather than backup restoration on production instances, outlines the data integrity risks that make restoration impractical, and describes how to work with ServiceNow Support to resolve critical issues.
Data integrity considerations
Your first thought might be to request a production restoration. After all, non-production instances (development, test, demo) can be restored through the Now Support Service Catalog in four automated steps. However, production instances are fundamentally different. Restoring a production instance from a backup creates significant risks that are typically more detrimental to the entire instance than the initial failure.
Let’s look at the data integrity risks involved.
Live data is at stake. Production instances store incidents, requests, changes, and business records that users across the entire enterprise depend on daily. A restoration replaces all data with the backup state, which impacts the following categories:
- Transactional data includes all records users created or modified since the backup, such as incidents, requests, changes, problems, catalog items, and approvals. These records do not survive a restoration.
- Configuration data includes business rules, workflows, scripts, UI policies, and system properties. Any configuration changes deployed after the backup revert to the previous state.
- Integration state data includes queued messages, pending imports, and synchronization pointers. External systems may hold data that no longer matches the restored production state, requiring reconciliation.
Restoration causes downtime. The instance becomes unavailable during the restoration process, which can take more than six hours depending on the database size. User access is restricted, and the platform cannot process transactions.
Delta data is lost. Any records created or modified after the backup point disappear permanently, including new incidents, completed approvals, workflow states, and configuration changes.
Integrations require coordination. Production instances typically connect to external systems such as HR platforms, monitoring tools, and financial applications. Restoring a production database without coordinating integration shutdowns risks data corruption in downstream systems.
In a restoration scenario, disruption, data loss, and corruption of downstream systems would not be limited to a single business unit. The impact extends to all users across the entire instance.
What to expect during fix-forward resolutions
Each fix-forward resolution is unique because the exact issues depend on your instance configuration and the nature of the root cause. The ServiceNow support team works with you to resolve issues quickly as they arise.
Contact Support
The ServiceNow support team has dedicated resources and tools to ensure that your instance is operational with the least disruption possible.
When opening a case with Now Support, to make sure that your case is prioritized appropriately, in the Create a case form, include the following information:
- In the Instance(s) impacted section, from the drop-down list, choose your production instance.
In the Business criticality section, change the toggle switch to Yes.
For detailed steps on opening a case, see Create a case on Now Support.
Related Resources
