ERP Data Migration: The Part That Actually Takes the Time

Every ERP timeline slips on the same thing. Not development — data. The system is configured and waiting while somebody works out which of the four entries called “Ram Traders” is the real supplier and what the opening balance should be.

This is predictable, and it is planable.

Migrate balances, not history

The instinct is to bring everything across so the new system has the full picture. It is almost always the wrong call.

Migrate: master data (items, customers, suppliers, employees, chart of accounts) and opening balances as at the cutover date — stock quantities and values, customer and supplier balances, bank and cash, fixed assets with accumulated depreciation, employee leave balances.

Do not migrate: years of transaction history. It is expensive to map, it is where most migration errors originate, and the benefit is almost entirely “we might want to look at it”.

Instead: keep the old system running read-only for a defined period. If someone needs a transaction from three years ago, they look it up there. This costs almost nothing and removes the largest and riskiest part of the migration.

The exception is where you genuinely need history in the new system for trend analysis or a regulatory obligation. That is a real requirement, and it should be a decision rather than a default.

Clean before you load

Migrating dirty data means the new system is wrong on day one, and everyone concludes the new system is bad.

What to expect to find, because it is in every dataset:

• Duplicate masters. The same supplier under three spellings, with balances spread across all of them.
• Items with inconsistent units. Some records in cartons, some in pieces, no indication which.
• Customers who are the same person. Different phone number formats, name spelled differently.
• Stale records. Suppliers not transacted with in five years, items long discontinued.
• Balances that do not tie. The stock ledger and the accounts disagree; nobody knows which is right.

That last one has to be resolved before migration, not after. Loading a stock value that does not match the financial records means the new system starts unreconciled and you can never prove it is correct.

The business owns this, not the vendor

Only your staff can decide which duplicate is real, which items are still sold, or whether an old balance is genuinely collectible. A vendor can do the mechanical mapping; they cannot make those calls and should not be asked to.

Name someone in the business who owns the migrated data and has the authority to decide. Projects without that person stall in exactly this phase, waiting for decisions nobody feels able to make.

Do it more than once

Never migrate once, on go-live day.

First pass, early. Load whatever exists into a test environment. It will fail in dozens of places. That is the point — it produces the actual list of data problems, which is far more useful than a meeting about data quality.

Second pass, after cleaning. Fewer failures. Now check the numbers rather than the mechanics.

Third pass, a rehearsal. Full run, timed, on final data, with reconciliation. This tells you how long cutover will actually take, which is usually longer than assumed.

Fourth, the real one. Boring, because everything has already been discovered.

Teams that skip the rehearsals discover during cutover that the load takes six hours rather than two, and go live tired.

Reconcile before you accept it

The migration is not done when the load succeeds. It is done when the numbers are proven.

Non-negotiable checks:

• Total stock quantity and value equals the old system, per item category
• Sum of customer balances equals the receivables control account
• Sum of supplier balances equals the payables control account
• Trial balance balances, and equals the old system’s
• Employee count and leave balances match
• Fixed asset cost and accumulated depreciation match

Each check should produce an exact match or a documented, understood explanation. “Close enough” at this stage becomes an unexplainable variance that persists for years.

Watch the encoding and the dates

Two mundane things that cause disproportionate damage:

Character encoding. Devanagari text in names, addresses and item descriptions will corrupt if encoding is not handled consistently through export, transform and load. Check a record with Nepali text specifically at every stage — a name that survives the export can still be mangled by the import.

Date formats. Ambiguous formats mean 03/04/2026 is two different dates. And where the old system stored Bikram Sambat dates, the conversion has to be explicit and verified against known reference dates, not assumed.

Both fail silently. Neither shows up in a row count.

Freeze before cutover

Between the final data extract and go-live, the old system has to be frozen for the data being migrated. Otherwise transactions entered during the gap exist in neither system.

Practically: announce a cutoff, extract, load, reconcile, go live, then enter the frozen-period transactions into the new system manually. Keep the window short — a day or a weekend — because manual re-entry is the part staff resent most.

Budget honestly

For a mid-sized business with reasonably kept records, data preparation and migration is commonly a third of the total effort. For a business with messy records it can exceed the configuration work outright.

Plan for that from the start. Discovering it in month three is how ERP projects get their reputation.

Once the data is in, the rollout sequence matters as much — rolling out an ERP in stages covers that.

We build and implement ERP software for businesses in Nepal, and we would rather spend three weeks on your data than go live with numbers nobody trusts. Talk to us.