Software demos are about features. Go-live is about data. More ERP projects stumble on migrating data than on any missing feature, because dirty, unmapped, last-minute data turns a capable system into one nobody trusts on the first morning. The migration is the least glamorous part of the project and the one most likely to decide whether it succeeds.
The part of the project nobody demos
When you evaluate an ERP, you watch it do things: raise an order, run a report, post a journal. What you do not see is the work of getting years of your own data, spread across spreadsheets, an old system and a few people's heads, into it cleanly. That work is invisible in the sales process and enormous in the project. It is also where the timeline usually slips, because it is the one part that cannot be faked or rushed at the end.
An ERP is only as trustworthy as the data inside it on day one. If the opening balances are wrong, the stock figures are off, or half the customer records are duplicated, people stop trusting the system in week one and quietly go back to their spreadsheets. The software did not fail. The migration did.
Why data migration goes wrong
The failure modes are consistent across projects.
Dirty source data, discovered late. The old records are duplicated, inconsistent, and full of gaps everyone worked around for years. That mess only becomes visible when you try to move it, usually too late to clean calmly.
Left to the end. Migration gets treated as a final technical step rather than a stream that runs the whole project. Squeezed into the last two weeks, it is rushed exactly where it needed care.
Migrating everything. Teams try to bring ten years of history across because "we might need it." More data means more to clean, map, reconcile and get wrong. Most of it is never looked at again.
No owner. Migration sits between the implementer and the business, so nobody fully owns it. The implementer does not know which records matter; the business assumes the implementer has it handled.
No reconciliation. Data gets loaded and nobody checks that the totals in the new system match the old one. The errors surface later, in front of a customer or an auditor.
What good migration looks like
Good migration is a discipline, not an event. Treat it as its own workstream from day one, with a plan, an owner and time, not a task bolted onto the final sprint. Cleanse at the source early, while there is still time to do it calmly, and fix the process that let the data get dirty so it does not simply re-rot. Map deliberately, deciding field by field what moves where and what gets dropped, rather than tipping one system into another. Migrate less: bring the master data and balances you actually need, and archive the deep history somewhere you can still reach without loading it into the new system. Rehearse the cutover with at least one full dry run on real data, so go-live repeats something that already worked rather than being a first attempt. And reconcile everything that matters, proving the new totals match the old before anyone relies on them.
A worked example
A distributor moving to ERPNext wanted to migrate a decade of transactions, every customer record and all historical stock movements. The honest scope was much smaller: current customers and suppliers, open orders and invoices, live stock levels, and clean opening balances. The ten years of closed transactions were archived and kept accessible for reference, not loaded. Cleansing the customer master alone removed thousands of duplicates that would have followed them into the new system. A dry-run cutover two weeks before go-live surfaced a mapping error in tax codes that would have corrupted every invoice, caught with time to spare. The go-live was quiet, which in a data migration is the highest compliment there is.
Migrate less, trust more
The instinct on an ERP project is to bring everything and sort it out later. The discipline that actually works is the opposite: migrate less, clean what you move, prove it reconciles, and rehearse the switch. A new ERP earns trust on its first day or spends months clawing it back, and that first day is decided almost entirely by the data you put in it.
If you are planning a move to ERPNext and want the migration treated as the make-or-break stream it is, that is exactly where we start. Our team scopes and runs it as part of an ERP and CRM implementation engagement. Book a discovery call and we will map what actually needs to move, and what does not.
Frequently asked questions
Why is data migration the riskiest part of an ERP project?
Because it is invisible in the sales process, larger than anyone expects, and it decides whether people trust the system on day one. Missing features can be added later; a system full of wrong balances and duplicate records loses its users in the first week, and that trust is hard to win back. Migration is also the one stream that cannot be faked in a demo or safely rushed at the end.
What data should we migrate to a new ERP?
Less than you think. Bring the master data you actively use (current customers, suppliers, products), open transactions (unpaid invoices, live orders), current stock levels, and clean opening balances. Archive deep transaction history somewhere accessible rather than loading it into the new system. Migrating everything multiplies the cleaning, mapping and reconciliation work for data most people never look at again.
How long does ERP data migration take?
Longer than the plan usually allows, because the time goes into cleansing and reconciliation, not the technical load. The load itself can take hours; getting the data clean, mapped and proven correct takes weeks and should run alongside the whole project rather than at the end. The single biggest time-saver is deciding to migrate less.
Should we run the old and new systems in parallel?
Often, briefly, for the highest-risk areas like finance, yes. A short parallel or verification period lets you prove the new system produces the same numbers as the old one before you switch the old one off. It is not free, so keep it focused and time-boxed rather than running everything twice indefinitely, which exhausts the team and delays commitment to the new system.