SAP Cutover Plan Template and Runsheet Columns

Decision context

A cutover plan is a runsheet, not a project plan. It is read at three in the morning by someone who did not write it, so every row has to answer who is doing this, on which system, what has to finish first, how long it should take, and what proves it worked.

Most published SAP cutover templates are a task list with a date column. That is the part that survives contact with a real weekend the least. The columns below are the ones that get used when a task overruns and the command centre has to decide whether to continue, wait, or roll back.

Adranum does not sell a spreadsheet. It records the dependency evidence behind the sequence, binds each validation result to the exact package that was executed, and keeps a rollback checkpoint that can be verified rather than assumed.

Runsheet columns that earn their place

Fourteen columns cover almost every SAP cutover. Anything beyond this tends to be reporting decoration that nobody updates during the window.

• Task ID. A short stable key such as CUT-0410. Predecessors reference this, not the task name, because names get edited.
• Stream. Basis, data, functional, interface, security, business, or command centre. Streams let the command centre see which lane is blocked.
• Task description. One imperative sentence. If it needs two, it is two tasks.
• System and client. The exact SID and client. A task that runs in two systems is two rows.
• Predecessor task IDs. Explicit, not implied by row order. Row order changes; predecessors should not.
• Owner and deputy. A named person for each, not a team. The deputy column is what makes a 30-hour window survivable.
• Planned duration. Taken from the dress rehearsal, not from an estimate.
• Planned start and planned finish. Calculated from the critical path and refreshed after every rehearsal.
• Actual start and actual finish. The only way to know whether the window is ahead or behind.
• Status. Not started, running, done, blocked, skipped. Five values, no percentages.
• Verification. The concrete check that proves completion: a record count, a job log return code, a reconciliation report, a signed-off test ID.
• Downtime flag. Whether the row requires business downtime. This is what turns the runsheet into a downtime budget.
• Gate. Whether this row is a go or no-go decision point, and who owns that decision.
• Rollback reference. The rollback step ID that reverses this task, or the explicit note that it is not reversible.

The four gates most SAP cutovers need

A gate is a row where the runsheet stops and a named person decides. Gates should be few and unambiguous. Four is typical for a conversion or a large data migration.

• Gate 1, business freeze confirmed. Open transactions closed, period-end postings complete, interfaces stopped and queues drained, users locked. Owned by the business process lead.
• Gate 2, source extraction and reconciliation complete. Extract counts and control totals match source. Owned by the data lead. This is the last comfortable point to abort.
• Gate 3, technical validation complete. System up, jobs scheduled, interfaces reconnected, smoke tests passed, authorizations checked. Owned by the Basis lead.
• Gate 4, business verification and go-live. Business users confirm balances, open items, and a small set of critical transactions in the production target. Owned by the program sponsor.

Duration numbers you cannot borrow

The durations that decide whether a cutover fits its window are landscape-specific and cannot be taken from a template. Measure them in the dress rehearsal on production-sized data.

The usual overruns are the long tail of a data load, dictionary activation and conversion in a system conversion, after-import method and XPRA execution, index rebuilds, and the first full backup after the target is stable.

• Final delta extraction and load per object, measured at production volume rather than on a subset.
• Downtime-relevant conversion and activation phases in a system conversion.
• After-import methods and XPRA execution for the transports in the go-live sequence.
• Index and statistics rebuild before the first business use.
• Backup windows before and after the point of no return.
• Reconciliation report runtime, which is frequently forgotten and frequently long.

What the workflow must cover

• Sequence from evidence. Derive predecessor order from observed object, table, and interface dependencies rather than from the order the streams submitted their tasks.
• Verification per row. Attach the concrete check that closes a task, so completion is a recorded result and not a status field somebody set.
• Rollback pairing. Require every irreversible row to be named as irreversible, and every reversible row to reference the step that reverses it.
• Rehearsal timings. Carry measured durations from each dress rehearsal back into the plan so the downtime budget is based on observation.

Implementation workflow

Start with a bounded customer scenario and explicit acceptance criteria. Preserve native SAP permissions and accountable review while the software creates a repeatable evidence chain.

1. Build the task list per stream with owners and deputies.
2. Add explicit predecessor IDs and mark the downtime-relevant rows.
3. Insert the gates and name the decision owner for each.
4. Run a mock cutover and replace estimated durations with measured ones.
5. Freeze the runsheet, then run the window against it and record actuals.

Evidence to require

A transformation claim should resolve to observable artifacts, decisions, and execution receipts. Ask for the following evidence in a representative evaluation:

• Task and predecessor graph
• Owner and deputy assignment
• Measured rehearsal durations
• Downtime budget
• Gate decision record
• Per-task verification result
• Reconciliation output
• Rollback checkpoint

Boundaries and non-claims

Adranum separates analysis, proposal, human review, package creation, customer-local validation, and production execution. A later state never rewrites the evidence that supported an earlier decision.

• A template cannot supply your durations. Only a rehearsal at production volume can.
• Business downtime tolerance, regulatory reporting dates, and interface partner windows are customer constraints that no tool decides.
• A runsheet does not make an irreversible step reversible. It makes the irreversibility visible before the window starts.

Buyer checklist

• Does every row name an individual rather than a team?
• Is every predecessor an explicit task ID?
• Which durations are measured and which are still estimates?
• Who owns each gate, and can that person be reached at 03:00?
• Which rows are past the point of no return?