A cutover runbook is the operational execution document for the transition from a legacy system to a new or upgraded target system at go-live. It is not a project plan and it is not a test script. It is a time-sequenced, task-level execution guide — covering every action that must occur during the cutover window, in the order it must occur, assigned to a named owner, with a defined start time, estimated duration, dependency on prior tasks, success criterion, and rollback procedure if the task fails. The runbook is the document that the cutover team executes against, not the document that describes what will happen — it describes exactly what each person does, and when.
Structure and Content
A cutover runbook for an ERP or EPM go-live is structured in three phases:
- Pre-cutover phase: Legacy system freeze, data extraction, final sign-off on migration datasets, environment preparation, team briefing and role confirmation
- Cutover execution phase: Data migration runs (in dependency sequence), system configuration final checks, interface activation, security provisioning, end-to-end validation, reconciliation sign-off
- Go-live confirmation phase: Business user access confirmation, post-cutover smoke testing, incident management activation, go / no-go decision point with rollback trigger criteria
Each task entry in the runbook contains: task ID, task description, owner (named individual, not role), dependency on prior task IDs, planned start time, estimated duration, actual start time (populated during execution), success criterion (measurable, not descriptive), and rollback action. The runbook is a living document during execution: actual start times and completion statuses are recorded in real time, so the cutover manager can see at any point whether the timeline is on track or drifting.
The rollback decision point — the latest time at which the team can abandon the cutover, restore the legacy system, and defer go-live — must be explicit in the runbook, with clear criteria for what constitutes a rollback trigger. Without a defined rollback window, teams continue cutover execution past the point at which a safe rollback is possible, and a recoverable problem becomes an unrecoverable one.
Common Gaps and Failure Modes
The specific failure that most reliably extends cutover duration beyond the planned window is tasks without time estimates: a runbook that lists 120 tasks with owners and sequence but no duration estimates cannot produce a critical path. The cutover manager cannot identify which tasks are on the critical path and which have float. When a critical-path task takes twice as long as expected, the team has no basis for deciding whether to accept the delay, accelerate subsequent tasks, or invoke the rollback decision. A runbook where every task has a duration estimate, and the total estimated duration is less than the available cutover window by a defined buffer, is the only runbook that gives the cutover manager genuine control of the timeline.
How Loop Wise Solutions Produces This
Loop Wise Solutions produces the cutover runbook as a programme deliverable at least six weeks before the go-live date — early enough to be rehearsed during the final trial migration run. We conduct a cutover rehearsal where the runbook is executed against the test environment, actual task durations are recorded, and the critical path is confirmed before the live cutover window. Tasks where the rehearsed duration exceeds the estimate are investigated and resolved — whether through process change, additional resource, or timeline adjustment — before the live cutover begins.
