Selecting the right partner can affect your implementation timeline, budget, data integrity, reporting, and business continuity. Dynamics 365 implementation experience is valuable, but it does not automatically prove that a team can extract data from your legacy ERP, account for customizations, resolve dependencies, or reconcile financial records.
The 15 questions below are designed for CIOs, ERP program leaders, enterprise architects, and procurement teams evaluating providers in the United States and Europe. Use them to compare delivery methods and evidence, not just sales presentations.
1. Experience and technical fit
1. Have you migrated from our specific legacy ERP and version?
Experience with Dynamics 365 alone does not establish expertise in your source system. A migration from Dynamics AX 2009 or AX 2012, for example, may involve legacy customizations, modified business logic, and historical data structures that need detailed investigation.
Evidence to request: References that identify the source and target versions, migration scope, key challenges, and lessons learned.
Warning sign: Broad ERP experience without evidence of work on your source platform or version.
2. Have you handled migrations of comparable complexity?
Compare projects by complexity, not just by the number of migrations delivered. Relevant factors include data volume, legal entities, custom fields, integrations, geographic requirements, and business-critical processes.
Evidence to request: A case study covering similar complexity, the challenges encountered, the approach taken, and outcomes that can be verified.
Warning sign: Success claims based only on project counts, logos, or broad customer testimonials.
3. Who will actually deliver our migration?
The people assigned to your project matter more than the credentials shown during sales discussions. Confirm who will lead discovery, mapping, transformation, validation, cutover, and issue resolution.
Evidence to request: Named roles, relevant experience, delivery ownership, expected availability, and a clear escalation path.
Warning sign: Senior specialists lead the sales process, but their role in the actual delivery team is unclear.
2. Methodology and data control
4. How will you assess our legacy data before estimating the project?
A reliable estimate depends on an understanding of the source systems, data quality, customizations, dependencies, volumes, and business requirements. The assessment should also define the data scope, migration approach, environments, testing, and cutover planning.
Evidence to request: A discovery report with documented findings, assumptions, exclusions, dependencies, risks, and a proposed migration scope.
Warning sign: A firm estimate and fixed timeline are offered before meaningful discovery has taken place.
5. How will you decide what to migrate, archive, or retire?
Not every historical record needs to be loaded into the new ERP. Some data supports daily operations, some must remain available for audits or reporting, and redundant information may be eligible for retirement. These decisions should involve business owners and relevant retention requirements.
Evidence to request: A documented data-disposition process, clear retention decisions, business-owner approvals, and a record of what will remain accessible outside the new system.
Warning sign: The proposal assumes everything must be migrated or excludes older records using a blanket date rule.
6. How will you handle data mapping and transformation?
Legacy fields and values rarely match the target system perfectly. Source fields, reference data, custom logic, relationships, and formats may need to be mapped or transformed to meet Dynamics 365 requirements.
Evidence to request: Approved mapping specifications, transformation rules, ownership of exceptions, and a controlled process for changes.
Warning sign: Important mapping decisions are postponed until testing or cutover, leaving little time to resolve inconsistencies.
7. How will you prove that migrated data is accurate and complete?
A successful load is not the same as a successful migration. Record counts alone can miss incorrect balances, broken relationships, missing attributes, or incomplete business records. Validation should reflect the data and processes that matter to the business.
Evidence to request: Reconciliation reports, field-level validation rules where appropriate, exception tracking, business-process testing, and agreed acceptance criteria.
Warning sign: The partner considers migration complete simply because records loaded without technical errors.
3. Automation, tools, and security
8. Which migration activities are automated, and which remain manual?
Automation can improve repeatability and reduce repetitive effort, but its value depends on what is automated and how complex the data is. Ask about extraction, transformation, loading, validation, reporting, and repeat migration cycles.
Evidence to request: A task-by-task explanation of automated and manual steps, along with how errors are logged and reviewed.
Warning sign: General automation claims without evidence of how the approach improves control or addresses your requirements.
9. How will you manage repeated migration cycles and changing requirements?
Data corrections, revised mappings, configuration changes, and test findings can all require additional migration runs before go-live. The process should make each run repeatable and its results comparable.
Evidence to request: Version-controlled mapping rules, documented changes, repeatable execution, and traceable exception handling between cycles.
Warning sign: Each test run requires extensive manual rebuilding, or changes cannot be traced from one cycle to the next.
10. How will our data be protected throughout the migration?
Data may pass through extraction environments, staging areas, transformation tools, and test systems. Each stage needs appropriate controls, particularly when financial, customer, employee, or other sensitive information is involved. Clarify responsibilities across the partner and any subcontractors.
Evidence to request: Documented access controls, secure data handling, environment controls, retention and deletion procedures, and named security responsibilities.
Warning sign: The partner offers general security assurances but cannot explain its practices or accountability.
4. Delivery, risk, and accountability
11. How will you manage cutover and protect business continuity?
Cutover is more than the final data load. It coordinates migration with business operations, integrations, testing, reconciliation, and the transition away from the legacy system. The plan should be rehearsed before the production cutover.
Evidence to request: A documented cutover plan with rehearsal results, responsibilities, go/no-go criteria, contingency arrangements, timing assumptions, and reconciliation checkpoints.
Warning sign: There is no realistic rehearsal, or no clear authority for making decisions when issues arise.
12. What happens when data problems threaten the timeline?
Data defects, missing dependencies, and unexpected transformation requirements can affect delivery. Evaluate how the partner identifies risks, prioritizes problems, assigns ownership, and communicates the likely effect on schedule or business operations.
Evidence to request: Risk and issue registers, severity definitions, named owners, escalation procedures, and a process for assessing schedule and business impact.
Warning sign: The client is expected to resolve all data problems without a defined support or escalation model.
13. What support will you provide after go-live?
Migration-related problems can surface once users begin processing live transactions. Agree in advance who investigates failed records, reconciliation differences, and defects linked to migrated data after deployment.
Evidence to request: A documented hypercare model, support responsibilities, response expectations, knowledge transfer, and clear exit criteria.
Warning sign: Responsibility for migration-related defects becomes unclear as soon as the system goes live.
5. Commercial transparency and proof
14. What is included in your estimate, and what could increase the cost?
A low initial price may exclude discovery, data cleansing, additional migration cycles, complex transformations, or post-go-live support. Make sure the proposal explains what is included and how changes will be priced.
Evidence to request: A defined scope, assumptions, exclusions, resource requirements, change-control terms, and pricing for additional work.
Warning sign: Major activities remain undefined, or the estimate depends on assumptions that have not been validated.
15. Can we speak to clients with comparable migration requirements?
References can reveal how a partner behaves when a project encounters difficulties, not just when everything goes to plan. Ask previous clients about delivery challenges, issue resolution, timeline management, and the quality of handover.
Evidence to request: References from comparable projects, with permission to discuss both challenges and outcomes.
Warning sign: Only generic testimonials or performance claims are available, with no way to substantiate them.
How to compare shortlisted Dynamics 365 migration partners
Use the same scorecard for every provider. Rate each category from 1 to 5, where 1 means insufficient evidence and 5 means strong, verifiable evidence. The weights below are a suggested evaluation model, not an industry standard.
| Evaluation category | Suggested weight |
|---|---|
| Relevant experience and technical fit | 20% |
| Methodology and data validation | 25% |
| Automation and security | 15% |
| Delivery, risk, and post-go-live support | 25% |
| Commercial transparency and references | 15% |
| Total | 100% |
How to calculate the weighted score: Divide the category rating by 5, multiply it by the category weight, and add the weighted points. For example, a rating of 4 out of 5 in a category weighted at 25% contributes 20 points out of 100.
Use the score as a comparison aid, not as a substitute for judgment. A high overall result should not outweigh a critical weakness in security, financial reconciliation, or delivery accountability.
Final considerations: choose a partner that demonstrates control
The right Dynamics 365 data migration partner should explain not only what it will do, but how it will manage uncertainty, validate results, protect data, and remain accountable throughout the project. Before committing, ask for documented methods, evidence from comparable projects, clear responsibilities, and measurable acceptance criteria.
Involving a specialist early can help identify data dependencies, clarify scope, and expose risks before they affect the implementation plan.
Frequently asked questions
What should I look for in a Dynamics 365 data migration partner?
Prioritize relevant experience with your source ERP, a documented migration methodology, proven mapping and validation controls, appropriate security practices, transparent pricing, and clear delivery accountability. Ask the provider to support its claims with project evidence.
Should we use our Dynamics 365 implementation partner for data migration?
Not automatically. Assess whether the implementation partner has the specialist skills, resources, and processes required for your source system and migration complexity. A dedicated data migration partner may complement the implementation team when additional expertise is needed.
When should we select a data migration partner?
Involve migration specialists early enough to assess the legacy environment, data dependencies, scope, effort, and risks before detailed plans and timelines are fixed.
How can we confirm that migrated data is accurate?
Use more than record counts. Reconcile relevant totals and financial balances, validate important fields and relationships, track exceptions, and ask business users to test representative processes before signing off.
Is a migration successful as soon as all records load?
No. A successful load only confirms that records were processed. The project should also demonstrate that the data is complete, accurate, consistent, secure, and usable in the target business processes.
