An ERP data cutover plan must prove that the business can stop the legacy system, extract the agreed population, transform and load it, reconcile meaning, obtain sign-off, and open operations within the available window. A technically successful import is not enough. Missing open orders, duplicated balances, broken account relationships, or unmapped tax codes can surface only when process owners attempt real work.
Rehearsals turn that one-time event into a measured production process. Each cycle runs the same version-controlled sequence against a production-representative snapshot, preserves source and target evidence, times every task, resolves exceptions, and updates the runbook. Microsoft recommends practicing the cutover plan in a test environment; SAP Migration Cockpit supports simulation before migration. Neither feature replaces independent business reconciliation or an executive go/no-go decision.
Freeze the migration scope and accounting boundary
Define objects, companies, periods, history, attachments, open transactions, master data, configuration, and excluded archives. State the authoritative source and extraction timestamp for each population. Distinguish configuration data, master data, open operational transactions, balances, and historical reference because they have different dependencies and validation. Microsoft guidance explicitly separates configuration from migrated data such as customers, products, vendors, open orders, stock, and balances.
Name the business cutoff rule: which transactions must complete, which freeze, which queue for later entry, and how late-arriving changes are handled. Establish currency, unit, time zone, sign, tax, and status semantics. A row count cannot reconcile an open order if partial fulfillment and cancellation states are transformed differently. The control definition must exist before the first rehearsal so teams do not invent favorable checks after seeing results.
| Data class | Primary control | Semantic validation | Typical owner |
|---|---|---|---|
| Master data | Distinct active keys and required attributes | Status, hierarchy, identifiers, and duplicate review | Domain steward |
| Open transactions | Count and value by type and status | Remaining quantity, dates, parties, and lifecycle | Process owner |
| Inventory | Quantity and valuation by site or item | Unit conversion, lot, serial, and availability | Supply chain and finance |
| Financial balances | Trial balance and subledger totals | Currency, sign, period, aging, and control account | Controller |
| History and attachments | Population and checksum or manifest | Linkage, readability, retention, and access | Records owner |
Design control totals before transformation
Produce source controls directly from the frozen extraction boundary. Use counts, distinct keys, sums, quantities, hashes or manifests, minimum and maximum dates, status distribution, and referential counts. Segment by legal entity, currency, site, object type, and other dimensions that localize loss. A single enterprise total can net overpayments against underpayments or hide one missing company behind another duplicate.
Carry controls through landing, transformed staging, load acceptance, and target business state. Transformation can legitimately change row shape, so document bridge equations: one legacy header becomes a header plus lines; closed records are excluded by rule; two codes map to one target value. Reconcile expected differences separately from unexplained differences and bind every approval to the exact extract and transformation version.
Create an executable cutover runbook
Each task needs ID, predecessor, owner, backup, system, command or procedure, inputs, expected output, duration estimate, evidence location, completion criteria, failure response, and decision deadline. Include business communication, access changes, scheduler pauses, interface drains, backups, smoke tests, and hypercare handoff. Avoid prose such as migrate customers; split it into observable steps that a coordinator can time and another operator can execute.
Model the critical path and reserve contingency. Parallelize only where objects and shared infrastructure allow it. A faster load that saturates the database can delay reconciliation and create a longer end-to-end path. Define checkpoints where continuing would make rollback harder, such as releasing outbound integrations or permitting new target transactions. The decision authority must be reachable at each checkpoint.
Run progressive rehearsals with production constraints
An early cycle proves mapping and tools on a subset. The next uses full volume and realistic infrastructure. Later dress rehearsals use production-like security, network routes, scheduling, staffing, blackout timing, and downstream interfaces. Scrub or protect production-derived data according to policy. Rehearse restart from failed steps, not only the happy path. A process that works once from the beginning may be unusable after a late failure in the actual window.
Capture actual start, finish, queue time, records, throughput, errors, retries, manual touch, and evidence completeness. Compare cycles using the same task IDs. Improvement should reduce critical-path duration and unresolved exceptions without weakening validation. Freeze tool and mapping versions before the final rehearsal unless a defect requires change; any late change needs targeted rerun and explicit risk acceptance.
| Rehearsal stage | Main objective | Exit evidence | Failure injected |
|---|---|---|---|
| Mapping rehearsal | Prove object rules and basic sequencing | Approved samples and mapped exceptions | Unknown code or invalid reference |
| Volume rehearsal | Measure throughput and resource contention | Full population completes within budget | Slow load or storage pressure |
| Operational rehearsal | Use real roles, networks, and handoffs | Every task owner and evidence path works | Credential or connection failure |
| Dress rehearsal | Exercise complete timed cutover and sign-off | Go-live window, controls, and decisions proven | Restart, rollback checkpoint, or late delta |
| Go-live | Execute frozen approved plan | Signed reconciliation and controlled opening | Only rehearsed response patterns |
Manage exceptions as a signed population
Every rejected, defaulted, transformed, or manually corrected record needs an exception ID, object key, rule, financial or process impact, owner, disposition, evidence, and approval. Set thresholds by category and materiality before go-live. Zero exceptions may be unrealistic, but unknown exceptions are unacceptable. Block critical conditions such as unbalanced ledgers, missing mandatory consent, unresolved duplicate keys, or orphaned open transactions regardless of percentage.
Separate data cleansing in the source, deterministic transformation, target correction, and post-go-live backlog. Each has different auditability and replay behavior. Do not fix records directly in production without updating the migration evidence and rerunning controls. A manual correction file should be versioned, dual-reviewed where appropriate, and traceable to source and target identifiers.
Define rollback and forward-recovery boundaries
Rollback before target opening may restore the legacy service, discard target loads, and replay queued work. After target transactions or external messages begin, reversal becomes more complex and forward repair may be safer. State the last reversible checkpoint, data needed to restore legacy operations, treatment of transactions entered during the window, and who decides. Test the technical restore and the business communication path.
A migration tool can support initial load without supporting continuous synchronization. SAP documentation describes Migration Cockpit as an initial-load mechanism rather than ongoing integration. Do not assume it will capture every late source change. Use a designed delta method, extend the freeze, or record controlled manual entry. Reconcile the final delta as its own population before opening.
Build a decision-ready go/no-go pack
The pack should show critical-path status, source freeze confirmation, extract identity, control results, exceptions by severity, target smoke tests, interface state, security readiness, operational staffing, rollback viability, and named approvals. Present facts against pre-agreed thresholds. A red item can still produce a conscious go decision only when the accountable authority records impact, mitigation, owner, and deadline.
Require finance, process, data, technology, security, and operations sign-off for their domains. Signatures are not ceremonial; each owner needs access to supporting evidence and time to investigate. Preserve the final runbook, logs, manifests, mappings, reconciliation workpapers, exception dispositions, and decisions under the program's audit and retention policy.
Reconcile again during hypercare
After opening, monitor failed transactions, interface backlogs, balance movements, inventory variance, duplicate creation, access issues, and manual workarounds. Re-run key controls after the first processing cycles and period close. Some defects emerge only when users consume migrated data. Keep legacy read access controlled and available for investigation without allowing unauthorized parallel processing.
Define exit criteria from hypercare: stable critical processes, closed material exceptions, accepted residual backlog, operating ownership, support knowledge, and reconciled first-cycle results. Transfer unresolved items with source evidence and accountable dates. A project is not complete when the loader finishes; it is complete when operations can trust and govern the target records.
Example: reconcile open receivables
A rehearsal migrates open customer invoices. Source controls include invoice count and document, local, and reporting-currency amounts by company, currency, aging bucket, and status. The transformation splits tax lines and remaps customer keys, so staging controls bridge one source invoice to several target lines while preserving document totals. Target checks reconcile subledger to control accounts and sample due dates, payment terms, and customer relationships.
The first full-volume run reveals a sign reversal for credit memos in one company that the global net total nearly hides. Segmented controls expose it. The team fixes the rule, reruns the immutable extract, and adds a blocking negative-document check. That evidence supports go-live far better than a loader report stating that all rows were accepted.
Key takeaways
- Define populations, cutoff semantics, and controls before the first rehearsal.
- Reconcile through extraction, transformation, load, and target business state.
- Progress from mapping tests to a timed dress rehearsal under realistic constraints.
- Track every exception with impact, owner, disposition, and approval.
- State the last reversible checkpoint and rehearse restart and rollback paths.
- Continue business reconciliation through hypercare and the first operating cycles.
Frequently asked questions
Are source and target row counts sufficient?
No. Transformations can split, combine, exclude, or default records. Use bridge controls, financial and quantity totals, status distributions, relationships, and business sampling tied to documented rules.
How many cutover rehearsals are needed?
Run enough progressive cycles to prove mapping, full volume, operational handoffs, restart, controls, and the complete window. The number depends on complexity; exit evidence matters more than an arbitrary count.
How should late source changes be handled?
Use a designed delta extraction, extend the transaction freeze, or record controlled target entry. Identify and reconcile the delta separately. Do not assume an initial-load tool provides continuous synchronization.
Conclusion
A defensible ERP cutover is a rehearsed control process, not a heroic migration weekend. Stable scope, segmented control totals, executable tasks, progressive rehearsals, signed exceptions, explicit recovery boundaries, and post-opening reconciliation let leaders decide from evidence. The target goes live when its records support trusted operations, not merely when the import reaches 100 percent.