Planning Recovery If Your ERP Go-Live Goes Wrong. Account for shipments, payments and other real-world changes.
Restoring an application to an earlier state does not reverse every business event that occurred after that state was saved. A shipment may have left the building. A customer may have acted on a confirmation. A payment instruction may have reached an external party. The restored records must still be reconciled with those events.
Plan recovery around the changing business state during cutover. Before live activity begins, a technical rollback may return the implementation to a known position. After external effects occur, recovery may require reconstruction, controlled corrections, or a temporary operating arrangement as well as technical restoration.
There may be several recovery boundaries rather than one universal point of no return. Identify them by process, define the available options on each side, and rehearse the evidence needed to choose. The practical deliverables are a recovery-option matrix and a continuity register tied to explicit decision authority.
Walk the cutover sequence with business, technical, and continuity owners. Mark when the organization creates effects that cannot be undone simply by restoring its own application data.
Relevant events may include releasing goods, sending an accepted business message, issuing a document used by another party, or starting work in a connected system. Some effects can be corrected, but correction is a new controlled action with its own authority and evidence requirements.
For each event, identify the record that proves it occurred, the systems or people that know about it, and the consequence of replaying or omitting it. Also identify uncertain outcomes, such as a request sent without a received acknowledgment.
Distinguish a technical limit from a business limit. A backup may remain technically restorable long after restoring it would create a difficult reconciliation problem. Conversely, a business process may be held at a safe boundary while a technical correction proceeds. The recovery plan needs both views.
Use plain descriptions rather than relying on labels that different teams interpret differently.
Technical rollback restores a defined earlier system state. The plan must specify which components and data are included, which changes would be lost, and how events outside that restored state would be handled.
Fix-forward repairs the current state and continues from it. It requires a credible diagnosis, an authorized correction, verification of affected records, and enough time and capability to restore acceptable operation.
Controlled continuity performs a bounded set of critical activities through an approved alternative while normal processing is restricted or unavailable. It needs clear authority, a reliable record, defined limits, and a path for later reconciliation.
These options can be combined by process where the design permits it, but combinations create coordination demands. The decision must specify where each option applies and how shared data and dependencies remain consistent.
For each material recovery boundary, compare the available choices using the same questions:
Record where evidence is incomplete. A restoration procedure that has not been exercised with the relevant data volume carries different uncertainty from one demonstrated under comparable conditions. A manual fallback that depends on unavailable staff is not an available option simply because it appears in a plan.
Make the matrix specific enough to support a decision during an incident. Keep detailed technical and operating procedures linked and versioned, with the relevant owners responsible for their accuracy.
Work backward from the business constraints. If a recovery option needs time for execution, validation, and communication before operations resume, its latest useful decision occurs before that work begins.
Include uncertainty in the evidence. A diagnosis may still be developing while the remaining recovery window shrinks. Define who compares the risk of waiting with the risk of acting on incomplete information. The cutover team should not discover this authority question during the incident.
Use triggers that describe conditions, such as an unresolved reconciliation difference, a failed critical business task, or an inability to establish the state of consequential transactions. The actual thresholds and acceptable operating windows belong to accountable business and technical owners.
Revisit options as live events occur. A choice available before order release may require additional reconstruction afterward. Record the boundary crossed and the resulting change in recovery options so that decision makers are not relying on an earlier state of the plan.
Create an evidence plan for work around the transition boundary. Identify source records, target records, acknowledgments, message identifiers, physical movement records, approvals, and the relevant timestamps. Determine how they will remain available if a system is restored or replaced.
Control inbound and outbound processing according to the approved recovery procedure. The team needs to know what may still arrive, what is held, and what has already been transmitted. Otherwise restoration can be followed by automatic replay of work that has already had an external effect.
Assign a clear status to uncertain transactions and investigate them before consequential replay. A missing acknowledgment is not proof that nothing happened. The responsible owner should establish the external state through the approved route and record the finding.
Protect the evidence using the organization's access and retention rules. Recovery urgency does not justify copying unnecessary sensitive data into uncontrolled logs or broad communication channels. The plan should make appropriate handling possible under pressure.
Consider a hypothetical distribution business that discovers an inventory-processing problem shortly after live order release. Some goods have been picked but remain in the warehouse. Others have been handed to transport, and customers have received dispatch confirmations.
Restoring the application to its pre-release state would not bring those goods back or erase the customer messages. The recovery team must preserve which shipments actually left, which picks can be held, and which external confirmations were issued.
One approved option might restore part of the technical environment while reconstructing completed shipment records from controlled evidence. Another might hold further release and repair the current records. The business may also need a restricted continuity arrangement for genuinely critical work while reconciliation proceeds.
The appropriate choice depends on tested recovery capability, record quality, operating obligations, and authorized decisions. This illustrative scenario does not prescribe a remedy. It shows why “we can restore the backup” answers only part of the business recovery question.
For each activity that may continue outside normal processing, define its purpose, scope, owner, permitted volume or duration, and stop condition. Some activities may need to remain suspended because a safe alternative cannot preserve the required controls.
Use a controlled continuity register with unique references. Capture the initiating request, authorization, action taken, time, responsible person, supporting evidence, and later processing status. Define who may amend the record and how corrections remain traceable.
Set rules that prevent two teams from processing the same request through different routes. Tell affected staff which channel is authoritative during the fallback and how to identify already handled work. Preserve required approval separation and review controls in a form suited to the temporary arrangement.
Plan the return work before approving the fallback. Someone must compare the register with restored or repaired records, resolve conflicts, and confirm that each activity is entered once with the correct business effect. Manual continuity creates a reconciliation obligation that must be staffed.
A useful exercise includes representative events on both sides of the recovery boundary. Restore or repair the intended components, then prove that the business can account for work that occurred outside them.
Test an uncertain transaction, a duplicate input, a partially completed activity, and a continuity-register entry where relevant. Observe whether the team can establish the correct state and explain the evidence. A technically successful restoration with unresolved transaction meaning is an incomplete recovery result.
Measure decision time, evidence collection, execution, validation, reconciliation, and communication. Include the people who will approve the outcome, not only those who perform technical recovery. Record limitations where the exercise differs from the intended operating conditions.
Revise the recovery-option matrix and continuity procedures from what the rehearsal shows. If a route takes longer than the available window, change the plan or the operating constraint through the appropriate authority before relying on it.
Agree what must be true before restrictions end. Relevant evidence includes validated critical tasks, reconciled transition transactions, controlled remaining exceptions, available support, and clear communication to affected teams.
Assign an owner to every unresolved item that can safely remain open. State its treatment and review condition. Returning to normal operation should not make continuity records, customer commitments, or reconciliation differences disappear from view.
Before cutover, ask the recovery owners to describe the first live event that changes their preferred option. Then ask what evidence and authority they would need immediately afterward. Those answers reveal whether rollback is a practical business plan or merely the name of a technical procedure.