Short answer: ERP data migration fails for predictable reasons: duplicate and inconsistent master data that only the business can resolve, opening balances that do not reconcile, stock records that disagree with physical counts, missing historical context, and the assumption that migration is the vendor's job. The workable approach is to migrate master data and opening balances only, keep history in the old system for reference, clean product and customer lists before the project starts, and treat reconciliation as a business task rather than a technical one.
ERP Trends · Pakistan
ERP Data Migration: What Actually Goes Wrong, and How to Prevent It
It delays more go-lives than any other task, and the reason is almost never technical.
By Pearl Solutions · Updated September 2026 · 10 min read
Ask an implementation team what pushed a go-live date and the answer is monotonously consistent: data.
Not the software. Not integration. Not training. Data — specifically, the discovery that the business does not have the clean, reconciled starting position everyone assumed it had.
This is worth understanding before you start, because almost all of it is preventable and almost none of it is the vendor's to fix.
The central misunderstanding
Most owners picture migration as a technical transfer: take the data from the old system, put it in the new one. Under that picture, it is obviously the vendor's job.
The technical transfer is the easy part and usually takes days. What takes weeks is everything that has to happen before the transfer is possible — and that part requires decisions only the business can make.
The division that actually holds: the vendor can move, transform and load data. Only you can decide that "Ali Traders" and "Ali Trader Lahore" are the same customer, that the 340 units in the system but 280 on the floor means someone took 60, and which of your four price lists is the real one.
What actually goes wrong
1. Duplicate and inconsistent master data
This is the biggest one and it surprises nearly everyone. The same customer appears three times under different spellings. The same product exists twice because two people created it. Suppliers are recorded by shop name in one place and proprietor name in another.
In the old system this was survivable because a human read the list and knew. In an ERP it is not, because reports aggregate by record, and three versions of one customer means a credit limit that does not work and a receivables figure that is spread across three accounts.
Resolving it is slow, manual, and requires someone who actually knows the customers. No tool does this for you, because the knowledge is not in the data.
2. Opening balances that do not reconcile
Your go-live needs a starting position: what customers owe you, what you owe suppliers, what is in the bank, what stock you hold and at what value.
The problem appears when those figures do not agree with each other. Receivables per the customer ledger do not match the total in the accounts. Stock value in the inventory sheet does not match the balance sheet. These gaps often existed for years without anyone noticing, because nothing ever forced the comparison.
An ERP forces the comparison on day one. It will not accept a trial balance that does not balance, and it should not.
This is the point where projects get emotional. The gap was not created by the ERP project — it was revealed by it. But it surfaces during the project, so it feels caused by it. Expect this, and plan for a reconciliation exercise with your accountant before go-live rather than during it.
3. Stock records that disagree with the floor
Whatever your system says, the physical count is the truth. If the two differ materially, you must decide what to load — and the only correct answer is the physical count.
Loading system quantities because they are convenient means starting the new ERP with a known error, and then spending six months blaming the ERP for stock problems it inherited. Do a full physical count as close to go-live as you can manage, and load that.
4. Trying to bring ten years of history
A common instinct: migrate everything, so nothing is lost. It is usually a mistake.
Historical transactions carry the assumptions of the old system — old product codes, old tax treatments, customers who no longer exist, prices in structures you have since abandoned. Forcing them into a new model is expensive, slow and produces history you cannot fully trust anyway.
| Data | Migrate? | Why |
|---|---|---|
| Customers, suppliers, products | Yes | Needed to transact from day one |
| Open receivables and payables | Yes | You must chase and pay these |
| Current stock quantities and values | Yes | Starting position |
| Open sales and purchase orders | Yes | Still to be fulfilled |
| Bill of materials, routings | Yes | Needed to produce |
| Closed transactions from prior years | Usually no | Keep the old system read-only for reference |
| Historical stock movements | Usually no | High effort, low use |
Keeping the old system available in read-only form for a year costs very little and removes the entire argument. Anyone who needs a 2023 invoice can go and look at it.
5. Nobody owns the decisions
Migration generates a stream of questions: is this customer still active, which of these two product codes survives, what do we do with the stock that has been sitting since 2022, is this PKR 40,000 balance real or an old error.
If there is no named person empowered to answer these quickly, each one becomes a small stall. Twenty of them becomes a six-week delay. This is the most common mechanism by which migration slips, and it is an organisational problem rather than a data one.
A sequence that works
- Clean master data before the project starts. You can do this in Excel today, with no vendor and no cost. Deduplicate customers and suppliers, agree one code per product, mark dead records inactive. This alone removes most migration risk.
- Agree the cut-off date early. Everything before it stays in the old system; everything after it happens in the new one. Ambiguity here creates transactions recorded in neither.
- Reconcile before you migrate. Get receivables, payables and stock to agree with the ledger while you still have time. With your accountant, not during go-live week.
- Physical stock count close to go-live. Load reality, not records.
- Do a test load first. Always. Load into a test environment, have the actual users look at their own data, and fix what they find. The people who will spot a wrong customer are the people who deal with that customer.
- Load, verify, then freeze. Verify totals against the reconciled figures before anyone transacts.
The highest-return action in this entire article: start cleaning your product and customer lists now, before you have chosen a vendor. It is free, it is entirely within your control, and it removes the single most common cause of go-live delay.
How long it really takes
For a typical 20 to 150 employee business with reasonably organised records, expect three to six weeks of elapsed time — most of it spent on business decisions and reconciliation, not on loading.
If records are scattered across multiple people's spreadsheets with no single master list, expect longer, and expect most of the extra time to be spent by your staff rather than the vendor's.
That distinction matters when you plan capacity. The migration burden falls disproportionately on your accounts team and your storekeeper, at the same time as they are learning a new system and doing their normal jobs. Plan for that or it becomes the reason the project stalls.
Before you start
Data quality is one of the twelve items in our ERP readiness checklist, and it is among the three that most strongly predict how the project will go. If you are still choosing a partner, ask each one directly how they handle reconciliation and who they expect to do it — the answer tells you a great deal about whether they have delivered before.
Frequently Asked Questions
Cleaning master data and reconciling opening balances, not the technical transfer. The transfer itself usually takes days. What takes weeks is deciding that three spellings of a customer are one account, resolving stock records that disagree with physical counts, and making receivables, payables and stock agree with the ledger. These require knowledge of the business, so they cannot be delegated to the vendor.
Usually not. Migrate master data such as customers, suppliers and products, plus open receivables and payables, current stock quantities and values, open orders, and bills of materials. Leave closed prior-year transactions and historical stock movements behind, and keep the old system available in read-only form for a year. Old transactions carry the assumptions of the old system and forcing them into a new model is expensive and produces history you cannot fully trust.
Because an ERP forces figures to agree that may have quietly disagreed for years. Receivables in the customer ledger may not match the accounts total, and stock value in the inventory sheet may not match the balance sheet. The ERP did not create these gaps, it revealed them, but because they surface during the project they feel caused by it. Reconciling with your accountant before go-live rather than during it avoids the problem.
For a 20 to 150 employee business with reasonably organised records, three to six weeks of elapsed time, with most of it spent on business decisions and reconciliation rather than loading. If records are scattered across several people's spreadsheets with no master list, expect longer, and expect the additional time to be absorbed by your own accounts and warehouse staff rather than the vendor's team.
Clean your product and customer lists in Excel now. Deduplicate customers and suppliers, agree one code per product, and mark dead records inactive. This costs nothing, needs no vendor, is entirely within your control, and removes the most common cause of go-live delay. Pearl Solutions, an Official Odoo Partner in Lahore delivering ERP since 2006, can review your current data before a project starts. Call +92 300 7774979 or email info@pearlsol.com.