Data migration into a new ERP runs into trouble because of the condition of the old data, not the number of records. Duplicate item codes, units that do not reconcile and opening stock that never matched the physical count are found late and block go-live. Profile a real extract before you fix a price or a date, and treat reconciliation to the ledger as the main deliverable.
The trouble starts in master data
Transaction history is large, but it is regular. Master data (items, vendors, customers, price lists, chart of accounts) is smaller and messier. Five faults appear again and again.
One material, several codes
Over the years, three people create the same bright bar in three ways: by size, by grade and by supplier code. The old system tolerated all three. The new one, which counts stock by item, will show three half-empty bins. Check: group items on description and specification, then count the clusters that hold more than one code.
Units that cannot be converted
Steel bought by the tonne, stored by the piece and sold by the metre needs conversion rules. In the old system those rules lived in a clerk's head or in a sheet. Check: for each item with more than one unit, find the written conversion. If none exists, someone must define it before data moves.
Parties missing fields the new system demands
A new ERP may demand a GSTIN, a state code, a credit limit or a bank account that the old records never held. Check: list the mandatory fields in the new system and count how many old records are blank for each. Connecting an ERP to the GST portals explains why the tax fields matter.
Opening stock that never matched the count
If the old stock figure has drifted from the physical count for years, loading it moves the drift into the new system on day one. Check: run a physical count on a sample of high-value items before the cutover and compare it to the system.
Rules stored as exceptions
A customer who gets a special rate, a vendor with a different payment term, a warehouse that skips a gate pass. These exist as notes, flags or free-text fields. Check: search the free-text fields for repeated phrases. Each repeated phrase is usually an unwritten rule.
Why it comes to light late
Migration is scheduled as the final job, after screens and workflows are built. By then, every delay pushes on the go-live date. A small test load hides the faults too: a sample of 200 tidy records loads cleanly, and the full set may not.
The fix is to move the data step to the front. Pull a full extract in the first weeks of the project, and learn the faults while the plan can still absorb them.
A four-step plan
1. Profile before you quote
Run counts on a real extract: duplicates, blanks, unit mismatches, orphan records, dates in the future. A one-page profile report lets both sides price the cleaning work against facts. Quotes made before profiling are guesses. See the five cost drivers of a custom ERP.
2. Move less history than people ask for
Open balances, open orders and open invoices must move. Eight years of closed transactions rarely need to. Hold old records in an archive that users can read but not change, linked from the new system. Each year of history you load adds cleaning work and test time.
3. Make reconciliation the deliverable
A load that finishes without errors has proved only that the records fit the fields. Prove the numbers.
- Stock value in the new system equals the ledger for each store.
- Open receivables and payables match the control accounts, party by party.
- Record counts and checksums match for each table moved.
- A named finance owner signs the reconciliation, not only the project manager.
The old and new systems should run in parallel for at least one month-end before the old one stops. The method is described in legacy modernisation without a big-bang rewrite.
4. Rehearse the cutover
Do the full move at least twice on a copy: extract, clean, load, reconcile, with a stopwatch. Write down the rollback steps, and test them. On the real day, nothing in the sequence should be new.
Roles during the move
Data work stalls when ownership is unclear. Name these people early.
- Data owner per area. One person each for items, parties, stock and opening balances, with authority to decide which record survives a merge.
- A finance signatory. The person who confirms that the balances agree with the ledger.
- A technical lead on the old system. Someone who can extract data and explain what each field means, including the fields that were reused for something else.
- A plant or branch representative for stock counts and for confirming that locations in the system exist on the ground.
What a good outcome looks like
The result you want is a close in which the accounting figures come out of one system and agree with the stores, because reconciliation was built into the load. The steel manufacturer ERP case study describes a build in which close time and stock discrepancies were the measured outcomes.
Questions buyers ask
Why is ERP data migration hard?
Old master data holds duplicates, missing fields, unwritten unit rules and stock that no longer matches the count.
How much history should move?
Open items, balances and a short recent history. Keep older data in a read-only archive.
Who signs off the migrated data?
A named finance owner, against ledger control accounts, party by party and store by store.
When should migration start?
In the first weeks, with a profile of a real extract, and not as the last task.
Where Brihat Infotech fits
Every custom ERP build at Brihat Infotech includes a reconciled data migration and a written cutover and rollback plan. Start a conversation.