How to Plan Your ERP Go-Live. Set the sequence, owners, checks and decisions before launch.
A cutover task list can look complete while leaving the execution team to invent important details during the transition. “Load balances” does not explain which predecessor must finish, what evidence proves the load is acceptable, or who may authorize the next step if a reconciliation differs.
Build the runbook as a dependency-led operating procedure. Each task needs a start condition, a qualified owner, an expected duration grounded in rehearsal, completion evidence, and a defined response when the result is uncertain. The sequence also needs decision checkpoints with named authority.
The objective is an executable transition that a qualified backup can follow. The runbook should preserve enough context to support good decisions under time pressure without becoming an unreadable collection of every technical instruction used by the program.
Start with the operating transition: what stops, what continues, what moves, and what restarts. Define the relevant locations, processes, data populations, integrations, and business calendars. State which activity remains outside the cutover scope.
Specify cutoff and freeze rules in operational terms. Identify the last transaction included in the old processing cycle, how late-arriving work is handled, and who may authorize an exception. A freeze announced only as a timestamp can leave teams uncertain about work already in progress.
Include external and physical activity. Orders may arrive through channels that remain open. Goods may be in transit. A customer may act on a message already sent. The runbook needs a controlled way to capture these events and connect them with the correct processing state.
Agree the communication route for the freeze and restart. Each affected operating owner should know what confirmation they must provide and what evidence allows their activity to resume. A project-wide announcement is useful but should not substitute for critical acknowledgments.
Build the dependency network before committing to start times. Identify what each task consumes and what it produces. A migration step may depend on a completed extract, an approved mapping version, an available target state, and confirmation that source activity has stopped.
Separate hard dependencies from convenient sequencing. Some work can proceed in parallel if it does not compete for the same environment, person, or data. Other work must wait for business validation even when the technical team is ready to continue.
Include the decisions themselves as dependencies. A checkpoint may require evidence from several tasks and an authorized approver who is available at that time. If the approver cannot attend, the plan needs an approved delegate or a changed sequence.
Review the critical path and the near-critical branches. A task with apparent spare time may still become critical if it uses the same specialist as another activity or if its output requires rework. Record those resource constraints rather than relying only on a diagram's task relationships.
Use a consistent schema so that owners can scan and report tasks quickly. A practical card contains:
Keep detailed commands in controlled procedures when that improves readability. The card should link to the exact approved version and identify any parameters that vary by environment. Avoid copying an unversioned procedure into several places where it can drift.
Make a rerun instruction specific. Some tasks can safely repeat; others can duplicate records, messages, or external effects. State what the owner must inspect before another attempt and who authorizes it when the outcome is uncertain.
A task is complete when the required evidence is available and accepted under the runbook's rules. “The command finished” may be an intermediate state if business validation has not yet occurred.
Place checkpoints where evidence permits a meaningful decision. Examples include accepting the final source state, approving loaded data, authorizing live processing, and releasing business users. The appropriate checkpoints depend on the transition design.
For each checkpoint, list the required evidence, unresolved conditions, decision authority, available options, and latest useful decision time. Define how the choice is recorded and communicated to all affected task owners.
Avoid a checkpoint that offers only a ritual confirmation. If there is no time or authority to respond to an unacceptable result, the decision has effectively been made earlier. Work backward from the recovery options to determine when the evidence must be ready.
Distinguish technical completion from business acceptance. Technical owners confirm execution and system state. Business and relevant control owners confirm that the evidence supports the next operating step. The cutover lead coordinates the decision without acquiring authority that belongs elsewhere.
Use rehearsal evidence to estimate task duration. Preserve the conditions behind each estimate, including data volume, available staff, environment capacity, and whether the task required intervention. A clean rehearsal result may not represent a run with known unresolved constraints.
Reserve time for validation and decisions explicitly. These activities should not be squeezed into whatever remains after technical execution. Likewise, identify the recovery time required before a latest safe decision point, using evidence appropriate to the recovery option.
Include shift changes, breaks, access preparation, and handover. The runbook depends on people maintaining attention and knowing the current state. A long transition with no planned relief can create an avoidable execution risk.
Do not apply a universal contingency percentage without examining the path. Some uncertainty can be absorbed by parallel work; other delays consume the remaining recovery window directly. Describe where time can move and where it cannot.
Consider a hypothetical cutover that loads open customer transactions and then releases order processing. The technical load completes within its planned duration. Business validation, however, finds a group of records with an unresolved status mapping.
If the runbook marks the load complete solely because the import succeeded, the release task may start before the business has accepted those records. A dependency-led runbook instead requires the agreed validation evidence and checkpoint decision before live processing begins.
The decision packet identifies the affected population, the operational consequence, the available correction, and the time required to prove the result. The authorized owners compare proceeding under a defined restriction, correcting and retesting, delaying release, or using the applicable recovery plan.
The cutover lead records the choice and updates downstream task states. The example illustrates why validation and authority must appear in the executable path; it is not a recommendation that any particular exception should be accepted.
Run a timed rehearsal that includes preparation, execution, evidence collection, checkpoint decisions, communications, and handover. A technical dress rehearsal can be useful, but it leaves different questions unanswered if operating owners and decision makers are absent.
Use realistic constraints where safe and feasible. Test the intended access, data shape, staffing, and dependency behavior. Record deviations from the intended launch conditions so that the result is not overgeneralized.
Introduce selected, controlled disruptions to examine the runbook's usability. A task may finish late, an approver may need a delegate, or a reconciliation may require investigation. Choose scenarios with the responsible owners and avoid creating unintended effects in shared or live services.
Observe where people ask for undocumented instructions. Those moments identify gaps in the task card, procedure, or authority model. A rehearsal that succeeds through the memory of a few experts has revealed a dependency that the runbook should address.
Record planned and actual duration, waiting time, rework, missing evidence, and decisions that required clarification. Separate slow execution from time spent waiting for prerequisites or approval. The remedies differ.
Assign each material finding an owner and a correction. Update the dependency network and downstream timing when a task changes. A local improvement can affect another activity's inputs, resource needs, or validation conditions.
Rehearse changed high-consequence steps again as appropriate. Editing the runbook does not prove that the revised procedure works. Keep the accepted version under change control and define how emergency revisions are approved and communicated during execution.
Maintain a clear live status vocabulary, such as not ready, ready, running, awaiting validation, complete, and blocked. Record the reason and next action for blocked work. A single “done” column cannot show whether the command ran, the evidence was checked, or the business accepted the result.
Before approving the runbook, ask a qualified backup to execute one representative task from its card and linked procedure. If they can identify the prerequisites, produce the evidence, and recognize when to stop and escalate, the document is becoming usable under the conditions for which it was written.