Dynamics 365 Data Migration Checklist

What You Will Know After Reading This

• How Dataverse service protection limits (6,000 requests, 1,200 seconds of execution time and 52 concurrent requests per user, per web server, in a five-minute window) shape your load design.
• How to run dynamics data mapping for legacy fields, GUID relationships and picklist-to-optionset alignment without breaking lookups.
• How to execute staging pipelines and sandbox mock loads with SSIS (KingswaySoft) or Azure Data Factory, and what each rehearsal must prove.
• How to run delta synchronization so the cutover window only carries records changed since the last full load.
• How to cut migration risk with plugin bypass, reconciliation counts and a tested rollback decision point.

Table of Contents

• Why Dynamics 365 Data Migration Projects Fail Before Cutover Weekend
• Dynamics 365 Data Migration Comparison Matrix and Scenario Math
• The Dynamics 365 Data Migration Pipeline: Legacy CRM to Dataverse
• The Ekfrazo 5-Stage Dynamics 365 Data Migration Framework
• Where CRM Migrations Fail: Hidden Foreign Key and Throttling Traps
• In-House Microsoft Dynamics Migration vs. Engaging an Integration Partner
• How Ekfrazo Delivers Secure Dynamics 365 Migrations
• Frequently Asked Questions

Why Dynamics 365 Data Migration Projects Fail Before Cutover Weekend

Most dynamics 365 data migration failures start months before cutover: teams load data in the wrong order, skip mapping sign-off and leave plugins running, so lookups break and histories vanish during go-live weekend.

A CRM database is not a spreadsheet. Every account, contact, opportunity and activity in Dataverse is tied to others through GUID-based lookups, and those lookups only resolve if the parent record exists when the child arrives. Treat the job as a CSV import and you get three predictable outcomes:

• Foreign key corruption. Contacts land without a parent account, opportunities point at the wrong customer, and activities attach to nothing. Users see blank lookup fields and lose trust in week one.
• Lost customer history. Created-on dates reset to the import date unless you map the source value to overriddencreatedon, which requires the prvOverrideCreatedOnCreatedBy privilege. Closed cases, email trails and notes either do not migrate or arrive stripped of context.
• Stalled go-lives. A load that ran in four hours against 50,000 test rows takes four days against 5 million production rows once Dataverse throttling, plugin execution and retry logic kick in. The cutover weekend runs out before the data does.

The fix is discipline, not heroics: profile the source, sign off the mapping, rehearse full loads in a sandbox, and run the final cutover as a small delta rather than a full reload.

Planning a Complex Microsoft Dynamics Migration? Stop guessing your data mapping and API throttling limits. Discuss a Dynamics 365 integration project with Ekfrazo’s senior architects.

Dynamics 365 Data Migration Comparison Matrix and Scenario Math

Each migration phase controls a specific risk. Skipping profiling, mapping sign-off, mock loads or delta reconciliation moves that risk into production, where duplicate accounts and orphaned opportunities distort forecasts and erode user trust.

Migration Phase	Technical Focus	Tool / Utility	Enterprise Risk if Skipped
1. Discovery and profiling	Record counts, null rates, duplicate clusters, orphaned child rows, attachment volume	SQL profiling queries, SQL 4 CDS (XrmToolBox), Azure Data Factory data flows	Duplicates and orphans reach Dataverse and multiply across every related table
2. Dynamics data mapping	Source-to-target field map, GUID strategy, alternate keys, picklist-to-optionset value maps, owner and team mapping	Mapping workbook, Metadata Browser and FetchXML Builder (XrmToolBox)	Unmapped optionset values reject rows; lookups resolve to the wrong parent
3. Staging and mock loads	Repeatable pipelines, load order, batch size and thread tuning, retry on HTTP 429	SSIS with KingswaySoft, Azure Data Factory, CData drivers, sandbox environment	The first full-volume run happens on cutover weekend, with no timing baseline
4. Delta sync and validation	Changed-since watermarks, upsert on alternate keys, row-count and checksum reconciliation	ADF incremental copy, KingswaySoft upsert, SQL reconciliation scripts	Records edited during the freeze window are lost or overwritten
5. Production cutover (CRM migration go-live)	Plugin and flow bypass, owner reassignment, post-load audit, rollback decision point	BypassBusinessLogicExecution, Plugin Trace Viewer, audit queries	Plugins fire on every row, loads time out, and there is no clean way back

Scenario: What Dirty Data Costs After Go-Live

Consider an illustrative enterprise moving 250,000 accounts, 1.2 million contacts and 3.5 million activities from a legacy CRM. Discovery was skipped, so a 7% duplicate rate in accounts migrates untouched.

• 17,500 duplicate accounts split contacts, cases and opportunities across two parent records. Account-level rollups understate revenue on both.
• 6,000 open opportunities averaging $25,000 form a $150 million pipeline. If 2% lose their account lookup during load, 120 opportunities ($3 million) disappear from territory and forecast views that filter by account.
• 300 sellers spending 20 minutes a day searching for the right duplicate burn 100 hours daily, about 22,000 hours across 220 working days.

The throttling math matters just as much. Dataverse allows 6,000 requests per user, per web server, in a five-minute window. Push 5 million single-record creates through one application user and that ceiling alone stretches the load past 69 hours. Batch 100 records per CreateMultiple call and you need 50,000 requests, which removes the request ceiling; the 1,200-second execution-time limit then becomes the constraint, so you tune batch size and threads in mock loads rather than on cutover night.

Plan for daily entitlements too. Application users draw from a tenant pool of 500,000 requests per 24 hours plus 5,000 per Dynamics 365 Enterprise license, so 300 licenses give 2 million a day. Microsoft counts each CRUD operation inside a batch, so 5 million creates equal 2.5 days of pool capacity. Microsoft states that strict enforcement of these allocations has not started yet, but it reserves the right to throttle overages.

The Dynamics 365 Data Migration Pipeline: Legacy CRM to Dataverse

A dynamics 365 data migration moves data through six controlled hops: extraction, profiling and cleansing, staging pipelines, sandbox mock loads, delta synchronization and production cutover, with a reconciliation gate between each hop.

[Legacy CRM / SQL]
        |  extract full snapshot + change watermark
        v
[Data Profiling & Cleansing]
        |  dedupe, null fixes, orphan report, optionset value maps
        v
[Staging & SSIS / ADF]
        |  staging DB keyed on legacy IDs + alternate keys
        v
[Mock Load in Sandbox]  <---- repeat until counts, timings, lookups pass
        |  load order: users/teams > accounts > contacts > opps > activities
        v
[Delta Sync]
        |  only rows changed since the last mock or full load (upsert)
        v
[Production Cutover]
           plugin bypass on, reconcile, audit, go / no-go

Read the diagram as a set of gates. Nothing moves to the next box until record counts, lookup resolution and error logs match the agreed thresholds from the box before it.

The Ekfrazo 5-Stage Dynamics 365 Data Migration Framework

The Ekfrazo framework runs every dynamics 365 data migration through five gated stages: discovery, data mapping, staging and mock loads, delta sync, and production cutover. No stage starts until the previous gate passes.

Phase 1: Source Discovery, Profiling, and Data Cleansing

You cannot map what you have not measured. Profile every source table before anyone writes a mapping row.

• Inventory every source system, table, custom field and attachment store, with row counts and size on disk.
• Measure null rates, invalid emails and phone formats, and free-text fields that should be picklists.
• Run duplicate detection on accounts and contacts (name + domain, email, tax ID) and agree survivorship rules with the business owners.
• List orphaned child rows: contacts with no account, opportunities with no customer, activities with no regarding record.
• Decide what not to migrate. Archiving closed activities older than an agreed cut-off is usually the largest single volume reduction; measure it in profiling before you size the load.

Gate: a signed data quality report with duplicate, orphan and archive decisions.

Phase 2: Data Mapping, Entity Relationship, and Optionset Alignment

Dynamics data mapping is where most hidden defects are created or prevented.

• Build a field-level map: source table and column, target table and logical name, data type, transformation rule, default value and owner.
• Choose a GUID strategy. Either let Dataverse generate GUIDs and keep the legacy ID in an alternate key column, or pre-generate GUIDs in staging so lookups can be set in a single pass.
• Define alternate keys on every table you will upsert, so delta loads match on legacy ID instead of extra lookup calls.
• Map every legacy picklist value to a Dataverse optionset integer. Add missing options to the solution before load; never rely on text matching at run time.
• Map owners to systemuser or team. Multi-target lookups such as Customer and Owner need the target table name as well as the GUID (in Azure Data Factory, the {lookup}@EntityReference column).
• Map createdon history to overriddencreatedon.

Gate: business sign-off on the mapping workbook and a frozen target schema in the sandbox solution.

Phase 3: Staging Environment Setup, SSIS/ADF Pipelines, and Mock Loads

Mock loads turn estimates into measured timings. Run at least two full-volume rehearsals.

• Land extracts in a staging SQL database, keyed on legacy IDs, with load-status and error columns on every table.
• Load in dependency order: business units, users and teams, then accounts, contacts, opportunities and cases, then activities, notes and attachments.
• With KingswaySoft on Dynamics 365 online, start near a batch size of 10 and about 10 threads, then raise threads until throttling messages appear. Azure Data Factory defaults to a write batch size of 10 and 10 parallel copies; Microsoft advises keeping write batch size at 10 or below.
• Use CreateMultiple or UpsertMultiple (100 to 1,000 records per call on standard tables) for custom .NET loaders. On standard tables one bad row rolls back the whole batch, so use them only on rows that passed validation.
• Honour HTTP 429 and its Retry-After header in every custom loader. Confirm your ETL vendor does the same.
• Record run time, error count and throughput for each table so the cutover plan uses measured numbers.

Gate: a mock load that completes inside the cutover window with error rates under the agreed threshold.

Phase 4: Delta Synchronization and Pre-Cutover Validation

The cutover window should carry only what changed since the last full load.

• Load the bulk of history into production days or weeks early, then capture changes using modified-on watermarks or change tracking in the source.
• Upsert deltas on alternate keys so reruns are idempotent and never create duplicates.
• Reconcile per table: source count, staged count, loaded count and rejected count must balance.
• Spot-check 50 to 100 records per major table with business users, including lookups, owners and optionset labels.
• Run user acceptance on real migrated data, not test data.

Gate: reconciliation report signed off and a go / no-go decision recorded with a named rollback owner.

Phase 5: Production Go-Live, Plugin Deactivation, and Post-Load Auditing

Cutover is a rehearsed runbook, not an improvised weekend.

• Freeze the legacy system or switch it to read-only.
• Bypass custom synchronous and asynchronous logic with BypassBusinessLogicExecution (CustomSync,CustomAsync), which needs the prvBypassCustomBusinessLogic privilege. Power Automate flows are not covered; turn them off separately or use the flow bypass option your tool supports.
• Disable auditing and duplicate detection jobs on high-volume tables during the load if your governance policy allows it, and re-enable them before users log in.
• Run the final delta, then reconcile counts and lookups against the Phase 4 baseline.
• Re-enable plugins and flows, then run the business processes that would have fired on create (for example, assignment or SLA) as controlled batch jobs.
• Keep the legacy system read-only for an agreed period as the rollback source.

Gate: post-load audit signed off, hypercare rota live.

Where CRM Migrations Fail: Hidden Foreign Key and Throttling Traps

CRM migrations usually fail in four places: child records loaded before parent GUIDs resolve, Dataverse service protection throttling, custom plugins firing during bulk loads, and picklist values with no matching optionset entry.

1. Child records loaded before parent GUIDs resolve. A contact import runs before its accounts finish, or runs in parallel with them. Lookups fail or default to null, and the loader logs a warning nobody reads. Fix: enforce load order in the pipeline, key every lookup on an alternate key, and fail the batch if the parent is missing rather than writing a null.

2. Hitting Dataverse service protection limits. Defaults are 6,000 requests and 1,200 seconds of combined execution time per user, per web server, in a five-minute window, plus 52 concurrent requests. Exceed them and Dataverse returns HTTP 429 with a Retry-After value; concurrency breaches fail at once. Fix: ramp threads up gradually, honour Retry-After, spread load across several application users only where your licensing and governance allow, and move heavy loads out of business hours.

3. Custom plugins left enabled during import. A plugin on account create that updates related contacts, which triggers a contact plugin that touches the account again, turns one insert into a chain of writes. At volume this burns execution time, triggers timeouts and can loop until the depth limit stops it. Fix: pass BypassBusinessLogicExecution for custom sync and async logic, switch off Power Automate flows separately, and replay required logic as a controlled job after load. Microsoft’s own solution plugins still run, so test with them in place.

4. Unmapped picklist optionsets. The legacy system stores “Gold Partner” as text; Dataverse expects an integer such as 100000003. Rows with an unknown value are rejected or land blank, and segmentation reports break silently. Fix: build a value map for every picklist in Phase 2 and fail validation in staging for any value without a match.

3 Questions IT Directors Must Ask Before Approving a CRM Migration Plan

1. What were the measured run times and error rates from the last full-volume mock load, and do they fit inside the cutover window with margin?
2. How does the pipeline handle HTTP 429 throttling, and who holds the privilege to bypass custom business logic during the load?
3. What is the rollback decision point, who owns it, and how long does the legacy system stay read-only after go-live?

In-House Microsoft Dynamics Migration vs. Engaging an Integration Partner

Run the migration in-house when volumes stay under about 50,000 records, the schema is close to standard and you have Dataverse specialists. Engage a partner for multi-system consolidation, custom entities or regulated data.

Decision Factor	Handle In-House	Engage an Integration Partner
Record volume	Under about 50,000 records across all tables	Millions of rows, or activity and attachment history measured in GB
Source systems	One source, close to the standard Dynamics schema	Several CRMs, ERPs or databases consolidated into one Dataverse environment
Data model	Standard tables and a few custom columns	Custom tables, many-to-many relationships, multi-target lookups, polymorphic regarding records
Team skills	In-house Dataverse developers who know Web API limits, alternate keys and plugin bypass	Limited Dataverse depth, or the team is already committed to the wider implementation
Tooling	Import Wizard, Configuration Migration Tool, Dataflows	SSIS with KingswaySoft, Azure Data Factory, custom loaders using bulk messages and retry logic
Cutover constraint	Business can tolerate a multi-day freeze	Weekend or overnight window with a hard go / no-go and rollback plan
Compliance	No regulated or personal data beyond basic contact details	GDPR, DPDP Act, HIPAA or financial audit trails that must survive migration intact

If three or more rows land in the right-hand column, the cost of a failed cutover usually exceeds the cost of specialist help.

How Ekfrazo Delivers Secure Dynamics 365 Migrations

Ekfrazo treats a Dynamics 365 migration as an operating change, not a data copy: governed mapping, rehearsed mock loads and audited cutover protect customer experience, employee adoption and operational reporting from day one.

We map each technical stage to the outcome it protects across CX, EX and OX:

• Customer experience (CX): deduplicated accounts, intact case and email history, and correct ownership mean service agents see one customer record with its full context on day one.
• Employee experience (EX): sellers and agents trust lookups, optionset labels and dashboards from the first login, so adoption does not stall on data clean-up tickets.
• Operational experience (OX): reconciled pipelines, forecasts and SLA timers give leadership reporting they can act on, and integrations to ERP, marketing and support platforms read the same keys.

Governance runs through every stage. Mapping changes go through version control and sign-off, privileged bypass rights sit with named accounts for the load window only, and every mock load and cutover produces a reconciliation record your audit team can review. Read how this connects to Enterprise platform implementation and API integration, or explore more on CRM and enterprise data architecture integration.

Ready to De-Risk Your Dynamics 365 Data Migration?

Bring your source systems, record volumes and cutover window. Ekfrazo’s architects will review your mapping approach, throttling plan and rollback point, and show you where the risk sits before you commit to a go-live date.

Discuss a Dynamics 365 integration project →

Frequently Asked Questions

These answers cover the questions CTOs and CRM platform owners ask most often when scoping a dynamics 365 data migration, from timelines and tooling to throttling limits and rollback.