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.
Answers before you ask.
The detailed, time-sequenced operational plan governing the transition from a legacy system to a new system at go-live. It lists every task, its owner, start time, duration, dependencies, success criteria, and the rollback action if it fails — providing the minute-by-minute execution guide for the cutover weekend, so the transition runs to a precise, rehearsed script.
Because if a cutover task fails, the team must know immediately how to reverse it or recover, rather than improvising under time pressure. Pre-defined rollback actions for each task mean a failure can be handled to a plan. Without them, a failed step during the tight cutover window can escalate into a chaotic, damaging situation with no clear recovery.
Because the cutover happens in a limited window (often a weekend), tasks must run in the right order and fit the available time. Sequencing with durations and dependencies lets the team execute in a valid order and see whether they are on schedule. Without this, tasks can run out of order or overrun, jeopardising the go-live within its window.
The cutover plan sets out the overall approach and sequence; the runbook is the detailed, executable, minute-by-minute task list derived from it. The plan is the design of the cutover; the runbook is the operational script the team follows on the night. The runbook operationalises the plan to the level of individual timed, owned tasks.