ERP Migration and Upgrade
These are two different projects with two different risk profiles. Replatforming means deciding what data deserves to come with you.
Why It Matters
The hard part is not writing the load scripts. It is agreeing which records earn a seat on the new system. Most organisations try to carry everything, then spend months mapping history that nobody will ever query.
The version change itself is rarely the problem. The cost sits in proving that every modification, report, workflow and integration you built still behaves against your own processes.
We inventory data volumes, customisations, integrations and reports, and set the scope of what moves.
Deduplication, format standardisation and mandatory gaps filled, then field by field mapping rules.
At least one full dress rehearsal on production-like data, timed end to end, with reconciliation run.
Regression testing against your processes, and balances, stock and open items agreed with finance.
The runbook is executed with named owners, a go or no-go gate, and support through the first close.
What moves, what stays, how much history, and what the old system keeps doing after cutover.
Deduplication, format standardisation and mandatory gaps filled before loading, not after.
Repeatable, versioned extract and load routines, so a rehearsal can be run again without hand work.
Trial balance, stock valuation, receivables and payables compared line by line against the old system.
Your own processes tested against the new version, with automation for the tests you will rerun.
Timed steps, named owners, a go or no-go gate and a rollback path that has actually been executed.
The reconciliation targets are agreed in week one, so the data has something firm to be tested against.
Carrying twenty years forward costs money and adds risk. We say so, and we set up the read-only archive instead.
At least one full dress rehearsal on production-like data, timed end to end, before anyone commits to a date.
A rollback plan that has never been executed is a hope. Ours is run during rehearsal and timed like any other step.
A weekend window, stated up front. We would rather lose the argument early than the trust on cutover night.
Less than you think. Open items, current balances and two to three years of closed transactions covers almost every operational and reporting need. Everything older belongs in the old system, kept running in read-only mode for audit and statutory access. Most organisations try to carry twenty years forward, which multiplies the mapping work, the reconciliation effort and the risk, in exchange for records nobody opens.
A mid-market replatform from one ERP to another runs 4 to 9 months, depending on how many entities, warehouses and integrations are in scope. A version upgrade of the ERP you already run is a different size of job: 6 to 16 weeks, driven almost entirely by how much customisation has to be regression tested. We size both against your actual system before quoting.
Plan for a weekend. A realistic cutover window runs from a Friday evening transaction freeze to Monday morning opening, and the reconciliation in the middle of it is what takes the time, not the data load. Anyone promising zero downtime on an ERP cutover is either redefining downtime or has not reconciled the numbers yet.
Not entirely, but the freeze can be kept short. A parallel run, where transactions are entered in both systems for a defined period, gives you a comparison and a fallback. It also costs real effort because your team is doing the work twice, so it should be time-boxed to two to four weeks on the highest risk processes rather than run open-ended across everything.
Each one gets assessed: retire it, replace it with standard functionality that now exists, or carry it forward and retest it. Customisation debt is what makes upgrades expensive, not the version change itself. We inventory every modification, report and integration first, because that list is the real scope of the project and the real cost is regression testing it against your own processes.
By agreeing what correct means before we start. Trial balance, stock quantity and valuation, open receivables and payables, and open order counts are reconciled line by line against the old system, and the sign-off gate is that they agree. The riskiest part of a migration is not the software, it is defining correct late, so reconciliation has nothing firm to test against.
We will tell you whether you are looking at a 6 week upgrade or a 6 month replatform.
