The ERP migration checklists you can download list the tasks, and the tasks are correct: cleanse the data, map the fields, load, test, train, go live. What they do not say is the rule that decides whether the cutover works or produces a quarter nobody can close. The rule is this: at every moment during the migration, each record has exactly one system that is right. An order, a customer, a stock count, an invoice. One system owns it, the other does not, and everyone knows which.
Migrations fail at the moments that rule is broken: the week both systems are live for open orders and some are shipped twice; the invoices raised in the old system after the customer list was moved to the new one; the stock that was counted in both and so exists twice on the balance sheet. This checklist is the sequence that makes those moments impossible. It is written for a suite exit, where the finance, inventory and order modules move together, but the rule holds for any ERP migration.
The cutover date, and the freeze window around it. The freeze is the period in which no new transactions are entered in the old system for a record type that is moving. It is usually a weekend plus a day, and it has to be announced to every team and to customers who place orders during it.
The record owner for each type, by name. Customers, suppliers, items, price lists, open sales orders, open purchase orders, open invoices, stock balances, general ledger balances, history. One person per type who says when it has moved and signs that the counts match.
What history comes across, and what stays in a read-only archive. Open transactions move. Closed history for the current and prior year usually moves as summary balances with the detail archived. Every migration we have seen started with a history list that was too long, and the cost of that list is the subject of our piece on what leaving a legacy suite actually costs.
Customers, suppliers, items, price lists, chart of accounts, tax codes, warehouses. These move first and they move while the old system is still the system of record for everything, because master data does not transact; it is referenced. Load it into the new system, reconcile counts and samples, and fix the duplicates and the stale records now, in the new system, with the owner signing each type.
The one-system rule during this step: the old system is right for everything. The new system holds a copy of master data that nobody transacts against. A new customer created in the old system during this step is added to the delta list for step four.
At the start of the freeze window, extract every open transaction: sales orders not fully shipped or invoiced, purchase orders not fully received, invoices not paid, bills not paid, and the stock balance by item and location. These are the records that will be transacted against in the new system from day one, and they are the records the rule most protects.
Load them in dependency order: orders before shipments, invoices before payments, stock balances last and as a single opening count per item and location. Reconcile the totals: open order value, open receivables, open payables, stock value, each against the old system's report at the moment of extraction, each signed by its owner.
The one-system rule during this step: the old system is right, but frozen. Nothing is entered in either system. A customer who orders during the freeze is written on a list, not in a system.
The general ledger moves as balances, not as journals: the trial balance at the freeze, by account, loaded as an opening journal in the new system, with sub-ledger detail for receivables, payables and stock matching the open transactions from step two. The reconciliation here is the one the auditors will ask for: trial balance old equals trial balance new, receivables ledger equals the sum of open invoices loaded, stock value equals the sum of opening counts times cost.
If the sub-ledger does not equal the general ledger in the old system, and it often does not, this is the step where the difference is found and posted as an adjustment with a reason, in the old system, before extraction. Do not carry an unexplained difference into the new system; it will never be explained later.
At the end of the freeze, the new system becomes right, one record type at a time, in the order of step two. Master data first: from this moment, a new customer is created in the new system and nowhere else. Then orders and purchasing: the delta list from the freeze is entered in the new system, and from this moment every order is entered there. Then invoicing and payments. Then stock movements. Each transfer is announced, each owner confirms, and the old system's entry screens for that type are locked.
This is the step where double counting happens in migrations that skip the sequence: an invoice raised in the old system because the finance team was not told that receivables had moved, a goods receipt entered in both because the warehouse was not sure. The lock on the old system's screens is the control. If the old system cannot be locked by module, it is locked entirely at the end of the freeze and the delta list is entered into the new system before anyone else logs in.
The migration is not finished at go-live. It is finished when the first month closes in the new system and the numbers reconcile: receivables collected against the invoices that were loaded, stock after the first count against the opening balance plus movements, and the trial balance against a forecast built from the old system's last close. Every difference is either a migration error, found now while it is cheap, or a real event that the old system would also have shown.
The old system becomes read-only, and stays reachable for the period the business and its auditors need, which is usually the current and prior financial year plus whatever the contracts require. It is not switched off on go-live day, and it is not left transactable either. The subscription cost of the read-only period is a line in the migration budget, alongside the others in our piece on the ERP migration cost line items nobody budgets.
Three decisions, then master data while the old system is right, then open transactions at the freeze, then opening balances reconciled, then cutover by module with the old screens locked, then the first close, then the archive. At every step, every record type has one owner and one system that is right. Write that column on one page, with the names and the dates, and it is the migration plan.
Discovery is no-risk: we write the cutover sequence for your record types with your owners, and you pay only if you go ahead.
The ERP Readiness Review is a 90-minute working session plus a written scorecard across master data quality, documented exceptions, integration scope and data ownership. Fixed scope, no obligation. Or see how we approach it.
More on the same problem:
"Something isn't working." "We're outgrowing our tools." "We're afraid to make the wrong move." No-Risk Discovery is a short, practical conversation that gets you clarity before you commit to anything big. We'll tell you if we're a fit. If we're not, we'll tell you that too.
Say who you are and ask. A person replies within one business day.
