To prepare clean data for ERP migration, decide what to move, audit your existing records, remove duplicates, standardise names, units and tax details, reconcile balances with physical counts and statements, map old fields to new ones, run rehearsal migrations and have users verify results. Migrate only what you need and archive the rest.
- Migrating bad data only makes the new ERP faster at producing wrong answers.
- Move masters and opening balances; archive old transactions.
- Rehearse the migration more than once and reconcile each time.
- Business users, not just IT, must verify the data.
Why does data quality decide ERP success?
An ERP presents the data you give it with great confidence. If customers appear three times, items have inconsistent units or opening stock is wrong, every report and decision built on them inherits the error. Users quickly lose faith and go back to private spreadsheets, which defeats the project.
Data preparation is therefore a business task, not a technical afterthought. Only your staff know which supplier is dormant or which item code is obsolete. Allow weeks for it in the project plan and assign named owners for each data set, such as items, customers, vendors, accounts and stock.
What data should you actually migrate?
Resist the temptation to move everything. Master data such as items, customers, vendors, price lists and chart of accounts is essential, as are opening balances for ledgers, stock and outstanding invoices. Open transactions such as pending purchase and sales orders are usually needed too.
Historical transactions from many years rarely need to enter the new system. Archive them in a searchable form, such as exports or the old system in read-only mode, and keep summaries if required. Moving less data lowers risk, shortens cleaning time and keeps the new system fast.
- Chart of accounts and opening ledger balances
- Items with codes, units, tax categories and prices
- Customers and vendors with GST and contact details
- Opening stock by location and batch
- Open orders, outstanding invoices and bills
How do you clean the data?
Start with an audit: export each data set to a sheet and look for duplicates, blanks, inconsistent spellings and obsolete records. Sort by name, phone number and GST number to find near-duplicates. Decide a naming convention, and apply it consistently, for example a standard format for item descriptions.
Standardise units of measure, tax settings and address fields. Verify GST numbers and PANs where applicable against official sources. Mark inactive parties and items rather than deleting them blindly. Keep a log of changes so that anyone can see what was merged or removed and why.
- Merge duplicate customers, vendors and items
- Use one naming convention and one unit per item
- Fill mandatory fields such as tax category and address
- Flag dormant records for archive
- Keep a change log of merges and deletions
How do you reconcile opening balances?
Reconcile before you load. Match ledger balances to trial balance, bank balances to statements, receivables and payables to party confirmations where possible, and stock to a physical count. Differences should be explained and corrected in the old system or recorded clearly as adjustments.
Choose a cut-over date, ideally at a month or quarter end, so that balances are clean and easy to verify. Keep documentation showing how each balance was obtained, as your accountant and auditors will want to trace the opening position of the new system.
How do you map, rehearse and verify the migration?
Create a mapping sheet showing each old field, its destination in the ERP, any conversion rule and the owner. Test a small sample first, then a full rehearsal in a test environment. Compare totals, counts and spot-check individual records. Fix mapping errors and run again until the results match.
Have business users verify, not only the implementation team. Ask the storekeeper to check stock for ten items, the accountant to check ledgers and sales staff to check key customers. A signed-off checklist from each owner before final cut-over creates accountability and catches mistakes while they are cheap to fix.
What happens after the final migration?
Freeze changes in the old system during the final load, and confirm that totals agree. After go-live, monitor for unusual balances, negative stock and unmatched invoices in the first weeks. Early anomalies often reveal migration issues that can be corrected quickly.
Protect the quality you worked to build. Define who may create or change master data, introduce simple approval for new items and parties, and review duplicates periodically. Data hygiene is an ongoing habit, and without it the new system will slowly decay back to the old mess.
Step by step
- Decide scope. List which masters, balances and open documents move, and which history will be archived.
- Audit and clean. Export data, remove duplicates, standardise names and units and fill mandatory fields.
- Reconcile balances. Match ledgers, bank, receivables, payables and stock to evidence at the cut-over date.
- Map fields. Document how each source field maps into the ERP and how values are converted.
- Rehearse and verify. Run test migrations, compare totals and have business users sign off.
- Cut over and monitor. Load final data, freeze the old system and watch for anomalies after go-live.
Frequently asked questions
How long does data cleaning take?
It depends on volume and quality, but weeks rather than days is common for businesses with years of messy records. Start early, in parallel with configuration.
Should we import all old invoices?
Usually not. Import open items and keep historical documents archived and searchable. This keeps the system lighter and the migration simpler.
Who is responsible for data accuracy?
The business. Implementation partners can provide templates and tools, but your teams own the correctness of items, parties and balances.
Can we migrate directly from Tally?
Often yes, with export tools or integration scripts, but masters and balances still need review. Confirm approach and test results with your accountant.
What if we find errors after go-live?
Correct them through proper adjustment entries and note the cause. Keep a short issue log in the first weeks and fix patterns at the source.
Need help with this? See our ERP Implementation service or talk to Yash Parikh.