Service — Migrations

Move your CRM to Dynamics 365 in the cloud, without losing what works.

Most organisations on an older CRM are not staying put by choice. They are waiting on a migration that feels too big to start. I move customer engagement systems to Dynamics 365 in the cloud: from Dynamics CRM 4.0 and 2011, from on-premises Dynamics CRM and Dynamics 365, and from Salesforce and other platforms. Small teams to enterprise. A clean landing in the cloud, with the data and the processes that matter, and as little disruption as the source allows.

Discuss a migration

The starting points

Where you are starting from

Migrations come from a few common places. Each one shapes the route.

Dynamics CRM 4.0 and 2011. Long-serving systems, usually heavily customised, well past mainstream support.
On-premises Dynamics CRM 2013 to 2016, and Dynamics 365 Customer Engagement on-premises. Closer to the cloud. Sometimes one lift away.
Salesforce and other CRMs. A different platform, so always a rebuild and a data migration, never a lift.
Several Dynamics 365 tenants. Often the result of a merger, an acquisition, or business units that each bought their own. The goal is one tenant and one view of the customer.

The big decision

Two routes to the cloud

Every migration is one of two things. An upgrade that lifts your whole system forward, or a rebuild that takes your data into a fresh environment. Knowing which one fits is the first decision, and it sets the budget, the timeline, and the risk.

Upgrade: lift the system forward. Microsoft’s on-premises to online migration takes your entire CRM organisation, the schema, the customisations, the data and the history, and brings it into Dynamics 365 in the cloud. It is the fastest way to keep exactly what you have. It is available for Dynamics 365 Customer Engagement 9.0 on-premises and later, and it runs as a Microsoft-assisted request through FastTrack rather than a one-click lift. The source has to be on a supported version, within the database size limits, with any unsupported customisations remediated first and qualifying cloud licences in place. When the system is healthy and meets those conditions, this is usually the route.

Data migration: rebuild and move. When the source is an old version, heavily customised, or carrying years of technical debt, lifting it forward carries the debt with it. The better route is to rebuild the solution on Dataverse with modern, supported patterns, then migrate the data that earns its place. This is also the only route from Salesforce and other non-Microsoft CRMs, because there is no Dynamics database to lift.

Mapping it out

Migration paths

Here is how the common starting points map to a route.

Dynamics 365 CE 9.0 on-premises. A cloud lift through Microsoft’s on-premises to online migration process, run as a FastTrack request. The organisation moves across, customisations and history included, once it clears the version and size checks.
CRM 4.0, 2011, 2013, 2015, 2016. Two options. A staged upgrade to 9.0 first, then the lift. The older the start, the longer that chain: 4.0 and 2011 cannot jump straight to 9.0, they have to climb through every release in between. So for very old or heavily customised systems the cleaner route is a rebuild on Dataverse with a data migration, usually cheaper and lower-risk than chaining upgrades across a decade.
Salesforce and other CRMs. A rebuild on Dataverse, then a mapped data migration. Schema, picklists, relationships and record ownership all need translating.
Several tenants. Consolidate into one. Covered below.

Shrinking the cutover

Delta migrations

The hardest part of any migration is the cutover: the moment you switch users from the old system to the new one. A delta migration shrinks that window to almost nothing.

It works like this. You load the bulk of the history into Dynamics 365 days or weeks ahead of go-live, while everyone keeps working in the old system. Then, at cutover, you run a second load that brings across only the records that changed since the first one. Users move to a system that is fully up to date, and the business never stops to wait for a migration to finish.

It takes more engineering. Change tracking on the source, a staging database, and careful reconciliation. For any system that cannot afford a long freeze, it earns its keep.

Multiple tenants

Consolidating several tenants into one

Some organisations end up with Dynamics 365 spread across several Microsoft tenants. A merger brings two CRMs together. An acquisition arrives with its own. Business units each bought their own years ago. The result is duplicated data, no single view of the customer, and licensing and administration spread thin.

Consolidation brings these into a single tenant, and usually a single environment or a clean set of them. There is no button in Microsoft 365 that merges two tenants, so this is a cross-tenant data migration, done one environment at a time. Extract from each source tenant, map identities into the target tenant’s Entra ID directory, reconcile duplicate accounts and contacts, and merge into one model. Record ownership is reassigned to users in the target tenant. Record GUIDs are preserved on import so lookups and relationships survive the move. The duplicate systems are retired once the data is reconciled and signed off.

Done well, the business comes out with one source of truth, one security model, one administration surface, and a simpler licensing position.

Method

How I run a migration

Every migration starts with an assessment. What is in the source, what is actually used, what must come across, and what can be left behind or archived. In a long-running CRM it is normal to retire a third of the columns and a fifth of the tables before a single record moves. Less data means a faster migration with less to go wrong.

From there it is the unglamorous discipline that makes migrations land. A staging area that mirrors the target. Field and picklist mapping done explicitly, not guessed. Lookups and relationships sequenced so nothing breaks on load. Success and error logging, so failed records are caught and retried rather than lost. Test runs, repeated, until the cutover is boring.

I work to Microsoft’s own guidance and tooling throughout. The AIM (Accelerate, Innovate, Move) programme to frame and assess the move. The on-premises to online migration process for eligible systems. The Configuration Migration tool for reference data. Azure Data Factory or SSIS, through the Dataverse connector, for the heavy lifting and the delta loads. Where Microsoft offers a migration incentive or a licensing bridge that fits, I bring it into the plan rather than leaving it on the table.

Track record

Across the full range of customers

I have run these migrations across the full range of customers. Small teams moving off CRM 4.0. Mid-market organisations consolidating after a few years of growth. Enterprises moving heavily customised on-premises systems into the cloud. The version history runs all the way back: I have migrated customers from CRM 4.0, through every release since, to Dynamics 365 in the cloud.