Every ERP project is judged, in the beginning, by the software. Which system was chosen, how it was configured, which modules went live. But when an ERP go-live goes badly, the software is rarely the culprit. The system usually works exactly as designed. What sinks the launch is the data that was poured into it, because an ERP does not run the business you have; it runs the business your data describes. If that data is wrong, incomplete, or mistranslated, then a perfectly configured system will confidently run on wrong numbers from the first day, and the people who depend on it will know within hours that something is off. Migration, the unglamorous work of getting clean, correct data into the new system, is the part almost everyone underestimates, and it is where most go-lives are quietly won or lost.
The reason this is so dangerous is that migration tends to be treated as the last step rather than a project in its own right. Months go into selecting and configuring the ERP, and then, close to go-live, someone turns to the question of moving the data and discovers that years of history spread across an old system and a dozen spreadsheets are far messier than anyone admitted. Now the hardest and most consequential part of the whole project is being rushed, under deadline pressure, at the exact moment there is no slack left. That sequencing is how good software ends up going live full of bad data.
Migration is not a copy and paste
The mental model that causes the damage is thinking of migration as moving data from one place to another, like copying files between drives. It is nothing like that. The data has to be cleaned, because the source is always dirtier than expected. It has to be reshaped to fit the new system's structure, which almost never matches the old one field for field. Old codes, categories, and account structures have to be mapped deliberately to new ones, and every one of those mappings is a decision someone has to make correctly. Records have to be loaded in the right order, because a sales order needs its customer and its items to exist first. And at the end, the result has to be checked against what it should be. Each of those steps is real work, and skipping any of them shows up later as data nobody trusts.
Why migration is underestimated
Migration is underestimated for the same reason data quality generally is: the mess is invisible until you go looking. From the outside, the existing data looks fine, because the current systems and the people using them quietly work around the gaps every day. It is only when you try to extract, clean, and load it into a system that enforces structure that the duplicates, the missing fields, the three different spellings of the same customer, and the balances that do not add up all surface at once. Teams that budgeted a week for migration discover it needs a month, and because the discovery happens near the end, there is no time to do it properly. The work was never small; it was only hidden.
The specific ways migration goes wrong
The failures are consistent across projects. Dirty data gets carried straight over, so the new ERP launches with the same duplicates and errors the old system had, now enshrined in the expensive new platform. Mappings are made wrong or hastily, so old categories land in the wrong new buckets and reporting is subtly incorrect from day one. History is handled carelessly, with teams either dragging years of irrelevant transactions across at great cost or dropping history they actually needed. And, most damaging of all, nobody reconciles: the data is loaded, the system goes live, and no one has confirmed that stock quantities, customer balances, and account balances in the new ERP actually match the old system. When the first report comes out wrong, trust collapses, and a system people do not trust is one they route around, which defeats the entire purpose of buying it.
Clean, map, validate, reconcile
Doing migration well is not mysterious; it is disciplined. Start early, and treat it as its own workstream running alongside configuration rather than a task bolted on at the end. Clean the data at the source before it moves, and use the exercise to fix problems rather than transport them. Agree the mapping from old structure to new explicitly, with the people who understand both. Load into a test environment first, never straight into production, and then reconcile: the stock, customer and supplier balances, and account totals in the new system must match the old system to the figure, not roughly. Put the migrated data in front of real users, because the people who know their own records spot a wrong one instantly. Only when a trial migration reconciles cleanly and users confirm it looks right do you run the real cutover. That reconciliation step is the difference between a system trusted on day one and one abandoned by day three.
Decide what history to bring, on purpose
One decision deserves singling out, because getting it wrong is common and expensive: how much history to migrate. The instinct is to bring everything, which feels safe and is almost always a mistake. Master data and open items, such as current customers, suppliers, products, open orders, and current balances, generally have to come across. Full transaction history usually does not, and hauling years of it into the new system is slow, costly, and imports old messes you would be better leaving behind. The sensible pattern is to migrate the master and open data, bring in a limited window of recent history where it genuinely earns its place, and keep the deep history in an archive or the old system for reference. Choosing this deliberately, rather than defaulting to move it all, keeps the migration lean and the new system clean.
A worked example
A manufacturing business engaged us to move onto ERPNext after years on an ageing system propped up by spreadsheets. The configuration was straightforward. The data was not. When we extracted it, the item master had thousands of duplicates and inconsistent units, several customers existed under three or four slightly different names, and the stock balances in the old system did not reconcile with what was physically in the warehouse. Had we loaded that as-is, ERPNext would have gone live looking exactly as untrustworthy as the system it replaced. So we treated migration as its own project. We cleaned and de-duplicated the master data, agreed how the old structure mapped onto ERPNext, ran the migration into a test company first, and reconciled stock and financial balances against the old system and a physical stock count until they matched. Only then did we cut over. The go-live was quiet, which is exactly what you want, because the numbers were right from the first day and the team trusted the system immediately rather than spending months second-guessing it.
Treat migration as the project it is
It is natural to pour attention into choosing and configuring the ERP, because that is the visible, exciting part of the project. But the software is the easy half. The system will only ever be as trustworthy as the data you carry into it, and that data is almost always messier, larger, and harder to move than anyone plans for. The organisations whose ERP go-lives succeed are not the ones with the cleverest configuration; they are the ones that treated data migration as a serious project of its own, started it early, and refused to go live until the numbers reconciled. Before your next go-live date is set, the question worth asking is not whether the system is configured, but whether the data going into it has been cleaned, mapped, and reconciled, because that is what people will actually judge the project on.
Getting clean, correctly mapped, reconciled data into a new ERP such as ERPNext, so the system is trusted from the first day rather than quietly worked around, is a core part of what our ERP and CRM implementation work is built around. Book a discovery call and we will help you make sure your go-live is decided by good data, not undone by bad.
Frequently asked questions
What is ERP data migration?
ERP data migration is the work of moving your existing business data, such as customers, suppliers, items, open orders, stock balances, and account balances, out of your old systems and spreadsheets and into the new ERP in a form it can actually use. It is far more than copying files across. The data has to be cleaned, reshaped to fit the new system's structure, mapped from old codes and categories to new ones, loaded in the right order because records depend on each other, and then checked to confirm it is correct. Because the new ERP runs the business on whatever data it is given, migration is the step that decides whether the system starts life trustworthy or broken, which is why it deserves to be treated as a project in its own right rather than a task at the end.
Why do so many ERP go-lives struggle with data?
Because migration is consistently underestimated and left too late. Teams spend months configuring the software and then treat moving the data as a final step, only to discover that years of legacy data are messier than anyone believed: duplicates, missing fields, inconsistent codes, and balances that do not reconcile. On top of that, the old structure rarely maps cleanly onto the new one, so decisions about how to translate it get made hastily under go-live pressure. The result is that a correctly configured ERP goes live full of wrong or incomplete data, users immediately stop trusting it, and the project is judged a failure even though the software itself works exactly as intended.
How much historical data should you migrate into a new ERP?
Less than most people assume, and only what the business genuinely needs. Open and active records, such as current customers, suppliers, items, open orders, and current balances, generally must come across. Full transaction history usually does not; dragging years of old transactions into the new system is expensive, slows the project, and imports old messes you would be better leaving behind. A common and sensible approach is to migrate master data and open items into the ERP, bring in a limited window of recent history where it is genuinely useful, and keep the older history accessible in an archive or the old system for reference rather than loading all of it. Deciding this deliberately, rather than defaulting to move everything, is one of the highest-value choices in a migration.
How do you make sure migrated data is correct?
By validating and reconciling rather than assuming the load worked. Before loading, clean the data and agree how each old field maps to the new structure. Load into a test environment first, never straight into production. Then reconcile against known totals: stock quantities, customer and supplier balances, and account balances in the new ERP should match the old system to the figure. Have real users check the records they know well, because they spot wrongness immediately. Only once a trial migration reconciles cleanly and users confirm the data looks right should you run the real cutover. This validation step is what separates an ERP that people trust from day one from one they quietly work around because the numbers looked wrong the moment they logged in.