The ERP transition plan on the wall has a cutover date, a training schedule and a go-live weekend. What it does not have, usually, is the thing that decides whether the cutover quarter can be closed: a list of every record type the business runs on, with the single date on which the new system becomes the one that owns it.
Without that list, there is a window of about ninety days in which two systems hold the same orders, invoices, stock and projects, and every record in flight during that window can be counted twice, not at all, or in each system at a different value. That window is where transitions fail, and it fails quietly, at month end, in the finance team.
The double count. An open sales order is migrated to the new system on cutover day and also still open in the old one. It ships from the old warehouse module and is invoiced from the new books. Revenue recognised twice, stock decremented once, and the reconciliation finds it in week three if someone is looking.
The gap. A receipt arrives in the week after cutover and is entered in neither system, because the warehouse team was told the old one was closed and the new one did not have the purchase order yet. Stock on hand is wrong in both. The count at month end does not match either system and is written off, which is the cost we described in what an ERP migration actually costs: the licence delta is the smaller half.
Every transition failure is one of those two, applied to one record type, on one side of one date. The plan's job is to make both impossible for each record type, one at a time.
A business of a hundred and fifty people runs on perhaps a dozen record types that the ERP will own: customers, suppliers, products, price lists, open sales orders, open purchase orders, stock on hand, open invoices and bills, open projects or jobs, fixed assets, the general ledger balances, and the historical transactions behind them.
They do not all move on the same date, and planning as though they do is the first error. Master data, customers, suppliers, products, prices, can move early, be verified at leisure, and be frozen in the old system from the moment it moves, with a rule that any change in the window is made in the new system and the old one is read-only for that type. Open transactions, orders, invoices, bills, cannot be frozen, because the business keeps trading; they move as a snapshot on a date, and anything created after that date is created in the new system only. Stock moves last, on a count, because a count is the only way to know what the number is. Ledger balances move after the old system's final close, which is after everything else.
So the plan is a sequence: master data, then open transactions, then stock, then balances, each with its own ownership date, and the ninety days is the span between the first and the last. We wrote the question of which system is the record for what, in the steady state, in ERP versus CRM, and what each is the record for. A transition is that question asked once per record type, with a date attached.
For each type, the plan states one sentence: from this date, the new system owns this record type, the old one is read-only for it, and anything in flight on that date is listed by number. That sentence makes the double count impossible, because only one system may write the type, and makes the gap visible, because the in-flight list is a checklist to be cleared.
The in-flight list is the part most plans skip, and it is the whole of the risk. The open orders on the order date, by number, with their status in each system until each one closes. The receipts expected in the stock window, by purchase order, so that the one that arrives on the wrong day is entered in the right system. The invoices unpaid on the invoice date, so that the payment that arrives next week is applied once.
The record-type plan also settles who is doing what, which the training schedule does not. Each ownership date has a group of people whose work changes on that day and not before: the sales administrators on the order date, the warehouse team on the stock date, finance on the balances date. Training them all for the go-live weekend trains them for a day that is not theirs, and they forget by the time their date arrives. Training each group in the week before its own date, on the records it will own, is less work and sticks.
It also settles the question every transition raises in week two, which is who may still enter something in the old system. The answer is on the list: anyone, for a record type whose date has not come; nobody, for one whose date has passed. Without the list, the answer is whoever asks loudest, and that is how the gap gets made.
Running both systems in parallel for a month is the usual advice and it is usually wrong, because it doubles the work of every transaction and guarantees the two diverge. The narrow version is right: parallel running only for the records in flight on each ownership date, until each one closes, with a weekly reconciliation of that list and nothing else. The list shrinks every week and is empty by the end of the window. That is the transition ending, and it is a measurable event rather than a feeling.
The instinct is to cut over on the first of the month or the first of the quarter so that the books are clean. The effect is to put the busiest week of the finance calendar, the close, on top of the busiest week of the transition. Cut over in the middle of a period, close the old system's partial period, open the new system's partial period, and accept one month with two sets of books. It is more work on paper and far less in practice, because the two tasks are not competing for the same people in the same week.
This is also the single biggest difference between a transition that costs what the estimate said and one that does not. We priced the exit from one suite in what leaving NetSuite actually costs; the cutover quarter's close was the line that varied most between the companies we looked at, and the ones that cut over on a period end were the ones that paid for it.
Write the list of record types. For each, write the ownership date and the in-flight rule. Count the days between the first date and the last. That is your window, and if it is less than sixty you have planned to move stock before you can count it.
We run ERP transitions under a guaranteed estimate, with the record-type plan as the first deliverable, because the estimate cannot be guaranteed without it. Discovery is no-risk: we build the record-type list for your estate with you, 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:
ERP Migration Cost: The Line Items Nobody Budgets For (article)
What Leaving NetSuite Actually Costs: Migration, Data, and the Modules You Will Not Replace. (article)
How to Read an ERP Estimate (video)
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.
