ERP Data Migration: A Practical Approach That Holds Up at Go-Live
An ERP system is only as trustworthy as the data inside it. Whether you are moving to Dynamics 365 Business Central, Dynamics 365 Finance and Operations or another platform, data migration is where many programmes find their biggest risks. A clear approach, run as a workstream with its own owner, turns it into a controlled process.
1. Agree the scope before you touch the data
Decide what actually needs to move. Most programmes split data into four groups:
- Configuration and reference data such as chart of accounts, payment terms and units of measure.
- Master data such as customers, vendors, items and employees.
- Open transactions and balances such as open invoices, stock on hand and fixed asset values.
- History, which is often better archived and reported from a data platform than loaded into the new ERP.
Every extra year of history adds cost, risk and reconciliation effort. Challenge it.
2. Profile the source data
Before designing any mapping, measure what you have: duplicates, missing values, invalid codes, orphaned records and inconsistent formats. Profiling gives you facts to take to the business and an honest estimate of the cleansing effort. Cleansing decisions belong to the business owners of the data, not to the migration team.
3. Build the mapping and transformation rules
For each target entity, document the source fields, the transformation rule, the default where data is missing and the owner who approved it. Keep these rules in a version-controlled document or repository, since they change during the project. Typical tooling includes SQL Server and SSIS, Azure Data Factory, the data management framework in Dynamics 365 Finance and Operations, and configuration packages or APIs in Business Central. Choose tools your team can support after go-live.
4. Make the process repeatable
Script the extract, transform and load steps so that the tenth run is the same as the first. A repeatable, automated migration is faster to rehearse, easier to fix and far less dependent on individual knowledge.
5. Validate and reconcile at every stage
Reconciliation is how you prove the migration worked. Build it into the process:
- Record counts from source to staging to target.
- Control totals for amounts, quantities and values.
- Financial reconciliation of the trial balance and the sub-ledgers (customers, vendors, inventory, fixed assets) to the general ledger.
- Business validation, where users check a sample of records and run real processes against migrated data.
Record the results of each run so that you can show improvement over time and give auditors a clear trail.
6. Rehearse more than once
Run several mock migrations with increasing realism, ending with a full dress rehearsal on the cutover timeline. Each run should end with a list of defects, fixes and timings. The rehearsals tell you how long cutover will really take and whether your plan for the weekend works.
7. Plan cutover and the first month
Write a cutover runbook with named owners, timings, checkpoints and a rollback decision point. Freeze changes in the legacy system on an agreed schedule. After go-live, keep the migration team available for the first period close, since that is when the remaining data issues tend to surface.
Common mistakes
- Treating migration as a technical task and leaving the business out of cleansing and sign-off.
- Loading too much history.
- Starting reconciliation late, so that issues surface during the final rehearsal.
- Relying on manual steps that nobody has written down.
If you are planning a move to Dynamics 365, my guide to moving from AX 2012 to Dynamics 365 Finance and Operations covers the wider programme around the data.
Need help with a Dynamics 365 or ERP project?
I advise on architecture, implementation, integration and data migration for Dynamics 365 and enterprise platforms. Get in touch at declan@feelyconsultants.com or find me on LinkedIn.