Most ERP data migration advice tells you to “clean your data” and “test thoroughly” and leaves it there. It’s not wrong, but it’s not much use either. What does cleaning your data actually involve when it’s spread across an old NAV system, a decade of spreadsheets, and a till or EPOS platform that was never designed to talk to an ERP system in the first place? What does “testing thoroughly” mean when you’ve got multiple sites, each with their own stock counts and supplier records?
This article gives you a working ERP data migration checklist rather than a description of one, with specific guidance for EPOS and till history, multi-site stock, and supplier or loyalty data, the areas generic ERP guides tend to skip over entirely. The migration approach will depend on the source system and intended target. Moving from a supported Microsoft ERP product may use Microsoft’s migration tooling, while a reimplementation from another platform may rely on configuration packages, structured templates, opening balances and agreed historical data sets.
In this article:
- Why ERP data migration is harder than it looks for multi-site businesses
- The ERP data migration checklist
- Getting data migration right the first time
- Frequently asked questions
Why ERP data migration is harder than it looks for multi-site businesses
Data exported from legacy systems seldom aligns perfectly with the structure, coding and business rules agreed for the new ERP solution. An old NAV system, years of spreadsheets, and a disconnected till or EPOS platform may each structure the same information differently. Every source therefore needs to be reviewed and assessed before it is approved for migration.
Multi-site businesses face a further layer of complexity that most migration guides don’t touch: duplicate SKUs that exist under different codes at different sites, supplier records that were set up separately by each location and never reconciled, and stock counts that simply don’t match between sites when you actually compare them side by side. None of this shows up until someone sits down and looks properly, which is exactly why underestimating this stage is one of the most common causes of ERP project delays. It’s not that the work is impossible; it’s that most businesses don’t budget the time or attention it actually needs.
If you’ve read our piece on common ERP implementation mistakes, you’ll know this is one of the seven that comes up again and again. This article goes a level deeper into what to actually do about it.
What EPOS and till data brings to the migration
Transaction history, product mixes, and till configurations are not a simple export-and-import job. Till systems typically store sales data in a structure built for day-to-day trading, not for long-term reporting or integration with an ERP platform, so this data needs its own mapping exercise rather than being bundled in with general stock or financial records. Skipping this step is a common reason migrations that looked complete on paper fall apart once real trading data starts flowing through the new system.
What multi-site stock reconciliation involves
Before a single, unified data set can go into Business Central, stock records from every site need to be compared and reconciled against each other. This means identifying where the same product exists under different codes, resolving conflicting stock counts, and agreeing on a single source of truth for anything that doesn’t match. It’s tedious work, but it’s far cheaper to do before go-live than to discover the discrepancies afterwards, when they show up as inventory errors across your live system.
The ERP data migration checklist
Here’s what a working checklist looks like, stage by stage.
Stage | What to do |
Audit | Catalogue every data source (ERP, EPOS/till, spreadsheets, supplier portals) and who owns each one |
Cleanse | Remove duplicates, standardise formats, and resolve conflicting records across sites |
Map | Match legacy fields to Business Central fields, flagging anything with no direct equivalent |
Migrate | Carry out agreed trial migrations in a controlled sequence, taking account of data dependencies, volume, risk and validation requirements |
Validate | Confirm completeness, accuracy, control totals and key relationships against agreed source information |
Test | Use representative business scenarios to confirm that migrated data behaves correctly within the configured solution and connected systems |
Work through these stages in order, and resist the temptation to skip ahead to migration before the audit and cleanse stages are properly finished. Every stage you rush here shows up as extra work, or extra risk, later.
Data governance and ownership
The customer normally owns the accuracy, completeness and approval of its business data. The implementation partner owns the agreed migration method, templates, mapping guidance and import activities within scope. Both parties should agree responsibilities, cut-off dates, validation criteria and sign-off arrangements before migration work begins. Named data owners within the customer’s business should resolve conflicting records and confirm what “correct” means when sources disagree.
Common mistakes at this stage
A common mistake is over-migrating: bringing across outdated or redundant data simply because it exists. This adds cost, slows testing and can clutter the new system. Agree which master data, open transactions, balances and historical records are needed in the live solution, and which information should remain available through an archive. Retention decisions should reflect legal, tax, audit and operational requirements rather than usage frequency alone.
Getting data migration right the first time
A checklist helps, but it does not fix inconsistent legacy data or unclear ownership on its own. A successful migration combines an experienced implementation partner with active customer ownership. The partner should provide a clear method, structured templates, mapping support and controlled import processes. The customer must provide knowledgeable data owners, resolve conflicting records and validate that the migrated information is complete and accurate.
If you’re planning a data migration as part of a Business Central implementation, talk to MADIC’s implementation team about how we plan and run this stage for hospitality, retail, furniture and fashion businesses.
Frequently asked questions
What are ERP data migration best practices?
Audit every data source before you start, cleanse and standardise records rather than migrating them as-is, map fields carefully against the new system, and validate against the original source data, not just record counts, before going live.
What should be on an ERP data migration checklist?
At minimum: a full audit of data sources, a cleansing and deduplication pass, field mapping against the new system, a staged migration plan, validation against source data, and a full trading-day test before go-live.
What are the risks of ERP data migration?
The biggest risks are lost or duplicated records, broken links between related data such as stock and supplier records, and migrating errors from the old system straight into the new one. Most of these come from skipping the cleansing and validation stages.
How do you migrate data to Business Central?
The method depends on the source system and the scope of data being moved. Supported Microsoft products may use built-in migration tooling, while reimplementations from other systems may use configuration packages, structured Excel templates, opening balances or custom migration processes. The approach should be agreed during discovery and tested through one or more trial migrations.
How long does legacy data migration take?
The duration depends on the number and condition of the source systems, the volume and complexity of data, the amount of history being moved, and how quickly the customer can cleanse and validate it. The timetable should be established after an initial data assessment and refined through trial migrations.