10 Questions to Ask Before Starting a Dynamics 365 Migration
Data migration is consistently the most underestimated risk in a Dynamics 365 implementation. Most project plans allocate insufficient time to data quality assessment and migration design — and most teams discover this too late, when rework, delays and budget overruns are already inevitable.
These ten questions are designed to be asked before migration planning begins. If you cannot answer them with confidence, you have found your risk areas.
1. What is the actual quality of your source data?
Not the assumed quality — the actual quality. Have you run a structured analysis of completeness, accuracy, consistency and uniqueness across the records you plan to migrate? Most organisations overestimate source data quality until they look at it systematically.
2. Who owns each data domain?
Accounts, contacts, cases, opportunities — who is accountable for the accuracy of each? If the answer is ‘everyone’, the effective answer is ‘no one’. Data ownership must be assigned before migration design begins, because cleansing responsibilities need to sit with someone.
3. Do you know which records will not be migrated?
Not every record in a legacy system needs to move. Historical data that will never be accessed, duplicates, test records and archived cases often make up a significant proportion of source data. Defining what will and will not be migrated early reduces volume, cleansing effort and migration complexity.
4. Are your field mappings documented and agreed?
Every source field needs a defined destination in the target system — or a documented decision to not migrate it. Field mapping documents should be reviewed by both technical and business stakeholders before build begins. Mappings that are ‘mostly agreed’ at this stage create significant rework risk later.
5. What are the transformation rules?
Data rarely moves cleanly from one system to another in its existing format. Values need to be normalised, picklists need to be mapped, date formats need to be converted and free-text fields need to be cleaned. Every transformation rule should be documented, tested and approved before migration execution.
6. How will duplicates be handled?
Legacy systems accumulate duplicates over years of inconsistent data entry. Will duplicates be merged before migration, flagged for review after migration, or simply migrated as-is? Each approach has implications for data quality in the target system and for the effort required to manage them post go-live.
7. What is your test migration strategy?
A single production migration run with no prior testing is a high-risk approach. A structured test migration strategy includes at least two full test runs — one early to identify issues in design, one late to validate fixes and confirm go-live readiness — with documented reconciliation checks at each stage.
8. How will you reconcile migrated data?
After a test migration, how will you confirm that the right number of records migrated, that key fields populated correctly, and that relationships between records are intact? Reconciliation should be systematic and documented — not a visual spot-check of a few records.
9. What is the cutover plan?
The cutover period — when the legacy system is frozen and the final migration run is executed — is the highest-risk phase of any migration. Who is responsible for each step? What is the go/no-go criteria? What happens if a critical issue is discovered during cutover? These decisions should be made in advance, not during the event.
10. Who is accountable if something goes wrong?
This is the question most project plans avoid. If data quality issues surface post go-live, who owns the remediation? If the migration vendor delivers incorrect data, what is the SLA for resolution? Accountability structures for data migration risk should be agreed in writing before migration begins.
What to do with the answers
If you have clear, confident answers to all ten questions, your migration planning is in good shape. If you have gaps, each gap is a risk area that needs to be addressed before execution begins.
BODVE helps organisations assess migration readiness, design structured migration frameworks and validate data quality before go-live. If you are planning a Dynamics 365 migration and want an independent review of your approach, start a conversation.