What makes an ERP switch nerve-racking is not the new system. It is that the old one is not allowed to stop: invoices have to go out, suppliers have to be paid and salaries have to be paid on the twenty-fifth, wherever you are in the migration. A switch that disrupts those flows costs more in trust than it ever saves in licenses.
That is why we plan ERP migrations backward, from the flows that must never stop to everything else. This is what the strategy looks like.
Clean up before you move
A migration is the best cleanup opportunity you will ever get, and the worst one to waste. Before anything moves, we go through:
- Chart of accounts and dimensions. The old system's structure is often an archaeological layer of old decisions. The new one should reflect how you want to follow up the business going forward, not how someone wanted to do it ten years ago.
- Registers. Customers and suppliers that have not had a transaction in several years are not moved; they are archived. A clean register in the cloud is worth more than a complete one.
- Open items. Unpaid customer and supplier invoices are the only part of the ledgers that has to be moved as items. The history beyond that is handled as history, not as live data.
The rule of thumb: move the structure looking forward, the data selectively and the history as an archive.
Choose a cutover model based on risk, not the calendar
In practice there are two honest models:
- Hard cutover at a period change. Everything switches over at a month-end or year-end. Simplest and cheapest, and the right choice when the business is consolidated and the flows are few.
- Phased transition. The accounts receivable and accounts payable flows move first, accounting follows, and for a limited period parts run in parallel. The right choice with several companies, high invoice volume or integrations that cannot be moved at the same time.
What matters is that parallel running, if used, is planned and time-limited, with clear rules for what is registered where. Unplanned parallel running, when the old system lives on "just in case" with no end date, is the most expensive form of ambiguity there is.
Protect the sacred flows
Invoicing, supplier payments and payroll must never depend on the rest of the migration going to plan. In concrete terms, that means:
- Invoicing is verified first. Before cutover, test invoices are sent through the whole chain, from supporting documents to distribution and incoming payment, so the first live invoicing in the new system is not the first time the chain is tested.
- Payment files are tested against the bank. The bank connection and the signing flow are validated with small amounts before the first real payment run.
- Payroll gets its own plan. Payroll often runs in a separate system; what has to be secured is the payroll data and how it is posted. That connection is tested separately, before the first payroll run after the switch.
After go-live: two closings as the answer key
The migration is not done at go-live. It is done when the first month-end close in the new system agrees with the opening balances without investigations, and the second goes faster than the old system's closing did. Until then, we keep close reconciliations and do not hand over to ongoing management.
Everything we do along the way is documented (account mappings, decisions, routines), so the knowledge of your new environment sits with you and in the structure, not with a single consultant. That is how a switch becomes an investment instead of a dependency.