Moving CRM data is easy. Moving it correctly is the real project. Records land in the wrong place, lookups break, duplicates multiply, and the sales team’s first view on day one is a customer list they no longer trust.
That’s why the method matters more than the tool. Azure Data Factory (ADF) is Microsoft’s cloud service for building data pipelines, and it includes a built-in connector for Dynamics CRM and Dynamics 365 (Dataverse).
This guide explains what ADF does well for Dynamics CRM data migration, how the pieces fit together, the order in which to load data, and what to settle before you move a single record.
Why Use Azure Data Factory for a CRM Migration
You can migrate CRM data using spreadsheets and import wizards, and for a few thousand records that’s fine. Beyond that, the manual route becomes a pile of files, a pile of mistakes, and no clean way to repeat the process.
ADF gives you a repeatable pipeline instead. You define the source, destination and mapping once, test it as often as you like, and run it again for the final cutover.
It also runs on a schedule, handles large volumes in batches, and logs what happened, which is what you want when someone asks why 214 contacts are missing.
We looked at the wider case for structured pipelines in our guide to building modern pipelines in Microsoft Fabric, and the thinking is similar here.
What the Dynamics Connector Supports
According to Microsoft’s connector documentation, the same connector covers Dynamics 365 (Dataverse) and Dynamics CRM, online and on-premises.
It supports copy activity, mapping data flows, and the lookup activity, and it works with Dynamics versions 7 to 9, ranging from Dynamics CRM 2015 through current Dynamics 365.
Two limits are worth noting early. The connector supports Dynamics 365 applications such as Sales, Customer Service, Field Service and Marketing, but not Finance and Operations. For that, Microsoft points to the Dynamics AX connector instead.
Mapping data flows run on the Azure integration runtime, while copy activity can also use a self-hosted one, which matters if your source system sits behind a firewall.
How the Pieces Fit Together
ADF has a handful of building blocks, and they’re easier to remember side by side.
| Building block | What it does in a CRM migration |
| Linked service | Holds the connection details for your source and for Dynamics |
| Dataset | Points to the specific table or entity you’re reading or writing |
| Copy activity | Moves the data from source to destination |
| Mapping data flow | Cleans and reshapes data in between, without writing code |
| Integration runtime | The compute that does the work, cloud-based or self-hosted |
| Pipeline | The sequence that ties it all together and runs it |
For simple one-to-one moves, a copy activity is usually sufficient. When the data needs reshaping en route, such as splitting a name field or standardising country values, a mapping data flow handles it in the middle.
Setting Up the Connection to Dynamics
Authentication is where most first attempts stall, so it’s worth getting right. Microsoft’s documentation explains that to use Microsoft Entra service principal authentication, you set up server-to-server authentication in Dataverse or Dynamics.
In practice, this means registering an application in Microsoft Entra ID, creating a matching application user in Dynamics, and granting it the required permissions.
Store the secret or certificate in Azure Key Vault rather than pasting it in. The principle is the same one we cover in our guide to securing AI agents with Microsoft Entra ID: give each process its own identity and only the access it needs.
Writing Data Into Dynamics
When Dynamics is the destination, there’s one rule that surprises people. The write behaviour must be set to upsert, which means each record is either inserted or updated depending on whether it already exists.
That’s useful for repeat runs, because you can rerun a load without creating duplicates.
To make upsert work, you tell ADF how to recognise an existing record, usually through an alternate key defined on the table in Dynamics.
Microsoft’s docs list the alternate key as optional, though community answers show that, in practice, you may need one, or a mapped primary key. Two other settings are worth a look.
Reading Data Out of Dynamics
If Dynamics is the source, for example, when you’re moving data out of an old CRM or a sandbox, you can read entire tables or use a query.
Microsoft documents FetchXML as the query language for reading data from Dynamics online and on-premises. This lets you retrieve only what you need, such as active accounts or records changed since a certain date, rather than copying everything.
The Order to Load Things In
Relationships are what make CRM data awkward. A contact points to an account, an opportunity points to both, and an activity points to all of them. If you load them in the wrong order, the lookups have nothing to link to.
A sensible sequence looks like this:
- Reference data first, such as users, teams, business units and option sets
- Accounts, then contacts
- Leads and opportunities
- Products, price lists and quotes
- Activities, notes and attachments last
Run it in a test environment first, check that the relationships landed correctly and only then repeat it in production. If your CRM feeds into finance, our guide to Business Central and Dynamics 365 CE integration covers the points where the two systems meet.
Testing, Cutover and Reconciliation
A migration isn’t finished when the pipeline turns green. It’s finished when the numbers have been verified to match.
Count the records in the source and the destination for each table. Spot-check real customers end to end, including their contacts, opportunities and history. Let a few real users try the new system with real scenarios before cutover day.
Then plan the cutover itself: a freeze on changes, a final delta load and a reconciliation that confirms nothing was lost. We describe the same pattern in our guide to migrating from Dynamics NAV to Business Central, and it applies to CRM just as well.
What Has to Be Right First
Most of the work sits in the basics, as with any migration.
- Clean data. Duplicate accounts and contacts travel across happily unless you stop them, so de-duplicate before you move, not after
- A field mapping. A written map of every source field to its destination field, with the owner of each decision named
- Alternate keys. Keys defined in Dynamics so upserts match existing records reliably
- A service principal with the right access. Its own identity, its own permissions, and its secret stored in Key Vault
- A history decision. Agree how much history to carry, because years of closed activity can be dead weight
- A narrow start. One table, one pipeline and a test environment before anything touches production
A single customer view helps here too. If you’re consolidating several systems into one CRM, our piece on a single customer view explains how to stop the same customer living in half a dozen places.
And if your data is scattered across teams, our guide to solving data silos in local government covers a pattern that repeats everywhere.
Cost and Governance
ADF is billed by usage, such as the number of pipeline runs and the volume of data moved, so a large one-off migration costs differently from a nightly sync. We haven’t included figures here because rates and terms change, so confirm current pricing with your Microsoft partner.
Governance matters just as much. A pipeline with full access to your CRM can read, modify and overwrite customer data, so decide who can edit it, who can run it and who reviews the logs.
Our guide to responsible AI in practice sets out the principles that apply here too, and you’ll find more guides on our blog.
Final Thoughts
Azure Data Factory makes Dynamics CRM data migration repeatable, testable, and far less painful than moving files by hand. The technology is well documented.
Success depends on the groundwork, including clean data, a clear field map, the right load order, honest testing, and reconciliation that proves the numbers match before anyone relies on the new system.
If you’d like help planning and running the move, our D365 migration and D365 integration team can design the pipelines and manage cutover, and our AI Enablement Programme helps you get that data ready for AI afterwards.
As an ISO 27001 certified Microsoft partner, we treat data protection as part of the plan, not an afterthought. Book a free assessment, and we’ll look at your CRM setup and tell you honestly where to begin, no hard sell.
Frequently Asked Questions
Can Azure Data Factory migrate data to Dynamics CRM?
Yes. ADF has a Dynamics 365 (Dataverse) and Dynamics CRM connector that works as both a source and a destination. You can use copy activity for straightforward moves and mapping data flows when the data needs reshaping.
Which Dynamics versions does the connector support?
It supports Dynamics versions 7 to 9, online and on-premises, covering Dynamics CRM 2015 and 2016 through to current Dynamics 365. It doesn’t support Finance and Operations, which uses the Dynamics AX connector.
How does ADF authenticate to Dynamics?
The recommended route is Microsoft Entra service principal authentication, which needs server-to-server authentication set up in Dataverse or Dynamics. Store the secret or certificate in Azure Key Vault.
Why does ADF need upsert when writing to Dynamics?
Microsoft’s documentation says the write behaviour for a Dynamics destination must be upsert. It inserts new records and updates existing ones, which lets you rerun a load without creating duplicates.
In what order should I load CRM records?
Load reference data first, then accounts and contacts, then leads and opportunities, then products and quotes, and finally activities and notes. This keeps lookups from breaking.
