ERP Cutover Planning: A Go/No-Go Checklist and Recovery Plan

Quick answer: When is an ERP ready for cutover?

Switch business operations only when testing is signed off, final data is validated, dependencies and user access are ready, and support can take ownership. Your cutover plan should identify who authorizes launch, what evidence they require, and how operations will recover if a critical check fails. Microsoft’s go-live guidance treats these as readiness requirements—not tasks to finish after launch. (learn.microsoft.com)

Use the following framework to build a project-specific runbook. It is intended for business owners, finance and operations leaders, and IT teams—not as a substitute for your ERP’s deployment instructions. Have qualified implementation personnel approve migration, integration switching, and recovery procedures.

1. Define launch gates and decision authority

A cutover runbook needs more than task names and completion percentages. Microsoft recommends recording task sequence, timing, owners and backup owners, instructions, verification, sign-off, and rollback arrangements. It also recommends deciding who makes the final go/no-go decision. (learn.microsoft.com)

For your own runbook, give every activity these fields:

Field	What to record
Task and dependency	The action and what must finish first
Accountable owner	One person responsible, plus a backup
Planned and actual timing	Include the time zone
Completion evidence	Report, log, approval, or other retained record
Acceptance criterion	What must be true to pass
Failure action	Fix, escalate, stop, or invoke recovery

Separate two decisions:

• Permission to start cutover: prerequisites, people, tools, and recovery arrangements are ready.
• Permission to release the ERP: final migration and production verification have passed.

A practical governance model is for the cutover manager to coordinate evidence, functional owners to approve their areas, and a named business sponsor to authorize launch. Document the arrangement before the event.

Agree on hard stops in advance. Suggested examples include an unexplained financial difference, missing operational inventory, failed critical access, or an unavailable shipping interface without an approved alternative.

An accepted issue should have a documented business impact, workaround, owner, and resolution date. Do not let “accepted” mean “not investigated.”

2. Map dependencies and control the transaction freeze

Microsoft’s checklist calls for aligning external systems and service providers with the go-live scope and timing. A successful ERP import alone does not establish that those dependencies are ready. (learn.microsoft.com)

Build a dependency register covering the services your business actually uses: identity, banking, ecommerce, warehouse systems, carriers, reporting, scheduled jobs, and document delivery.

For each connection, ask:

• Who stops the old flow and starts the new one?
• Where will incoming transactions wait?
• How will the team identify the last processed message?
• Who checks acknowledgments and handles retries?
• What evidence confirms the connection is ready?

Define the transaction freeze by activity—not merely by saying “the old ERP closes Friday.” Specify the cutoff for orders, receipts, shipments, invoices, payments, and master-data changes. Decide how physical warehouse activity will be handled during the freeze.

As a practical control, assign one owner to a temporary transaction register. Record each permitted exception, its unique reference, and whether it belongs in the final migration or subsequent processing. Avoid uncontrolled dual entry.

Also distinguish the transaction freeze from a configuration or code freeze. Any late change should undergo an explicit impact review rather than silently replacing the rehearsed cutover baseline.

3. Validate final migration and reconcile business balances

Separate migration work into three groups:

• Configuration: settings such as currencies, tax codes, and operating parameters.
• Master data: customers, suppliers, and products.
• Open transactions and balances: outstanding orders, inventory, and unpaid balances.

Microsoft distinguishes configuration from migrated data and identifies master records and open transactions as different migration categories. Give each group its own validation evidence. (learn.microsoft.com)

Follow the tested load sequence. Record the source cutoff, extract identification, mapping version, rejected records, and load results. Microsoft’s migration guidance calls for documenting sequence, dependencies, ownership, and pre- and post-cutover activities. (learn.microsoft.com)

For a distributor, consider this reconciliation pack:

Area	Suggested comparison
General ledger	Opening balances by entity, account, and relevant currency
Receivables and payables	Open documents and totals against approved source reports
Inventory	Quantity by item, location, and applicable tracking dimensions; value separately
Open orders	Outstanding quantities, status, and customer or supplier references
Relationships	Orders resolve to the correct customers, products, and locations

Use the same cutoff and comparable definitions on both sides. Retain a mapping explanation where the target structure differs. Data governance matters here: Microsoft identifies inconsistent business definitions as a reason departments can report different values. (learn.microsoft.com)

Illustrative calculation: Suppose the frozen source report contains $240,000 of open customer balances, while the target contains $237,500.

Difference = target − source = −$2,500

That is a discrepancy to investigate, not permission to insert an unexplained balancing entry. The controller should verify the underlying documents, mapping, exclusions, and any approved transformation before signing off.

Agree tolerances before cutover. Do not invent them when a difference appears.

4. Prove that real users can perform critical work

Test with intended business roles, not just administrator accounts. Microsoft’s finance and operations guidance explicitly calls for testing with migrated master data, opening balances, and the correct security roles. (learn.microsoft.com)

Build a short, role-based evidence list:

• Can an order-entry user find the correct customer and create an order?
• Can warehouse staff access their required work?
• Does an approval reach the intended approver?
• Can finance retrieve the reports needed for reconciliation?
• Are prohibited actions still blocked?

Include negative checks. For example, if policy prohibits a user from approving their own transaction, test that restriction rather than checking only that approvals work.

Complete full process testing in an appropriate nonproduction environment. Microsoft directs finance and operations teams to use a sandbox for testing rather than production. Keep cutover verification limited to approved checks, with any resulting transactions explicitly controlled. (learn.microsoft.com)

Confirm that required licenses and training are ready as well as technical access; Microsoft includes all three in go-live preparation. (learn.microsoft.com)

5. Write recovery steps before you need them

A recovery plan should explain how business operations resume—not simply state “restore the backup.”

NIST distinguishes the recovery time objective (RTO), concerning how long a resource can remain unavailable, from the recovery point objective (RPO), concerning the point to which data can be recovered and the associated tolerance for data loss. Its guidance also recognizes the additional time needed to reprocess work. These are useful planning concepts, not a universal ERP recovery promise. (nvlpubs.nist.gov)

Have technical and business owners document:

1. Triggers: which failures require stopping or recovery.
2. Authority: who can order recovery and who executes it.
3. Recovery point: the verified backup, snapshot, or supported alternative.
4. Containment: how users, interfaces, and scheduled jobs are controlled.
5. Transaction disposition: how post-cutoff work will be identified and reconciled.
6. Restart checks: data validation, access, integrations, and business approval.

Do not equate restoring the new ERP with returning to the old ERP. Treat those as separate procedures and require the implementation team to prove whichever route the business intends to use.

For a product-specific example, Microsoft’s Business Central online restore guidance describes creating a new restored environment while the original remains available. Default cleanup disables certain integrations, and Microsoft advises holding job queues after restoration. This illustrates why a database recovery is not automatically an operational restart. The details are product-specific and were checked on October 26, 2026. (learn.microsoft.com)

Identify the point beyond which simple fallback is no longer credible. If new shipments or payments have occurred, require an explicit reconciliation plan before resuming elsewhere.

6. Use a distributor’s checkpoint-based runbook

The following is a hypothetical planning example, not a tested schedule or promised implementation timeline. Assume a distributor is replacing its ERP while retaining separate ecommerce and carrier services.

Checkpoint	Owner	Required evidence	Stop condition
Authorize freeze	Operations lead	Cutoff acknowledged; exception register assigned	Warehouse activity cannot be controlled
Confirm source cutoff	Legacy-system lead	Final extract identified; interface positions recorded	Transactions remain unaccounted for
Complete final load	Migration lead	Load logs and rejected-record disposition	Required records fail
Approve reconciliation	Controller and inventory owner	Signed balance and quantity comparisons	Differences remain unexplained
Validate access and dependencies	IT and functional leads	Role checks and interface verification	Critical workflow is unavailable
Authorize release	Business sponsor	All gates passed; accepted issues documented	Required approval is missing

Add actual timestamps, backup owners, evidence locations, and latest decision deadlines to the working version.

Rehearse this sequence with the responsible people and representative tools and data. Microsoft recommends mock cutovers, investigating problems, and updating the plan before execution. (learn.microsoft.com)

Suppose inventory reconciliation fails. The migration lead’s “load completed” message does not override the inventory owner’s failed checkpoint. Stop progression, investigate, and reassess the remaining window.

If there is insufficient time to correct, revalidate, and preserve the agreed recovery option, the sponsor should postpone launch under the preapproved decision rules.

7. Prepare communications and post-launch support

Define support scope, hours, escalation priorities, tools, access, and handover responsibilities before launch. Microsoft’s support strategy guidance recommends checking support readiness before go-live and giving support teams practical experience during implementation. (learn.microsoft.com)

Prepare four messages in advance:

• Freeze starting: prohibited actions and the exception process.
• Cutover continuing: current checkpoint and next update.
• Launch approved: where to work and how to request help.
• Launch postponed or recovery activated: where operations resume and how held work will be handled.

Use one authoritative status channel. Users should not infer launch approval from a working login.

During hypercare, the period of elevated support immediately after launch, monitor both technical health and business completion. Suggested checks include stuck interface messages, failed postings, unprocessed orders, shipment completion, and new reconciliation differences. Microsoft’s checklist includes monitoring, help-desk readiness, support handover, and hypercare. (learn.microsoft.com)

Set hypercare exit conditions rather than assuming support can step down on a predetermined date. Require stable critical processes, assigned residual issues, and an accepted handover.

Before releasing users, ask one final question:

Can each accountable owner show evidence that operations can proceed—and explain what happens if their area fails?

If the answer is unclear, the decision pack is not yet complete.