Data migration is a controlled business decision
Migration is not successful because a file imported without an error. The target records must be complete enough for the approved workflow, mapped to the intended meaning, reconciled with trusted sources and accepted by an authorized owner.
The organization owns the meaning and approval of its source data. The implementation team can profile, map, transform and load it, but should not silently decide which duplicate customer, opening balance or historical record is correct.
1. Name owners and define the migration scope
- Business owner for each data domain
- Source-system contact and extraction responsibility
- Migration analyst or technical mapping owner
- Reviewer for quality, balances and exceptions
- Authorized sign-off and cutover decision
State which companies, branches, periods, master records, opening balances, open transactions, documents and history will move. Also state what will remain in an archive or legacy system.
2. Inventory every source before designing the load
List databases, spreadsheets, documents, devices and external systems. Record the owner, format, volume, encoding, identifiers, relationships, date and currency rules, access method, extraction frequency and known quality problems.
Do not assume the newest file is authoritative. A source register should identify which source wins when the same record exists in several places.
3. Agree on the target data model and mapping
Map source fields to target fields with meaning, type, required status, allowed values, transformation, default, reference dependency and validation rule. Confirm how identifiers will be preserved or replaced and how old identifiers can be traced after go-live.
- Customers, suppliers, employees, items and chart of accounts
- Branches, warehouses, projects, cost centers and currencies
- Opening balances, stock on hand and open documents
- Attachments, historical transactions and audit requirements
4. Clean data under business authority
Profile missing values, duplicates, invalid codes, impossible dates, inconsistent units, inactive records and broken relationships. Create correction rules and an exception list. Business owners should approve merges, closures, conversions and material adjustments.
Keep the original extract and the approved transformed version. An undocumented spreadsheet correction cannot be audited or repeated reliably.
5. Protect migration environments and files
Migration data may contain payroll, identity, financial, supplier or beneficiary information. Limit access, use approved transfer and storage, separate environments, protect credentials, log material activity and define when temporary files will be removed. Production data should not be copied into uncontrolled test tools.
6. Run repeatable trial migrations
A trial should use the intended extraction, transformation and load sequence. Record runtime, failures, rejected rows, manual steps and dependencies. Repeat the process after corrections so the final cutover is based on a rehearsed procedure rather than a one-time script.
Test data must arrive early enough for configuration review, integrations, training and UAT, while still being controlled against unauthorized use.
7. Reconcile structure, counts and value
Validation needs more than row counts. Compare control totals and representative records across the source, transformed data and ERP.
- Record counts by company, branch, status or period
- Opening trial balance and account balances
- Customer and supplier receivables or payables
- Inventory quantity and value by item and location
- Open orders, commitments and document totals
- Relationships, attachments and sample history
Define tolerances, exception ownership and the evidence required for sign-off.
8. Plan cutover, freeze, rollback and communication
The cutover plan should state the last legacy transaction, data freeze, final extraction, load order, reconciliation, integration activation, access release and authorized go-live decision. Include estimated durations, owners, checkpoints and communication.
A rollback plan should explain what triggers it, how systems and users return to a safe state, how transactions created during the attempt are handled and who authorizes the decision.
9. Retain evidence and close temporary access
After acceptance, preserve the approved mapping, scripts or configurations, extracts, reconciliation, exceptions and sign-off according to policy. Remove temporary credentials and files, confirm archive access and record the ongoing owner for data quality.
Primary guidance used for this article
This checklist was cross-checked against Microsoft’s official implementation guidance for configuration and migration data, its data-management checklist and its guidance on data migration governance and cutover alignment. The principles are adapted generically; they do not imply that Fida uses or resells Dynamics 365.