There is no shortage of content on the internet about migrating to Microsoft Dynamics 365 Customer Engagement Online. Most of it follows the same arc: outline the benefits of the cloud, describe the broad migration phases, recommend engaging a trusted partner. What most of it skips is the hard part.

The hard part is not the cloud itself. Microsoft has made the general migration path reasonably well-supported. The hard part is what happens when the system you are migrating has been in active development for a decade, customised by multiple teams across dozens of projects, and is now so deeply embedded in your operations that a failed go-live is not just an IT problem, it is a business crisis.

If your CRM estate has significant depth and age, this article is for you.

The Customisation Problem Nobody Warns You About

Standard Dynamics migration guidance is written for systems that are relatively clean. Upgrade, run the assessment tool, validate, migrate to Dataverse. That guidance is entirely correct - for the right kind of system.

But what happens when your Dynamics environment has accumulated 800 server-side plugins, many written against APIs that Microsoft has since deprecated? Or 200+ unmanaged solutions with no source control and no documentation of ownership? Or business-critical processes running on Microsoft Dialogs - a feature that simply does not exist in the cloud version of the platform?

In these environments, the standard migration playbook hits a wall almost immediately. You cannot run the upgrade tool and expect a clean output. You cannot migrate the data and expect the platform to function. Every component needs individual assessment, remediation, and cloud compatibility validation before a single record can move.

This is not a niche edge case. It describes the operational reality of most organisations that have been running Dynamics CRM on premises for five or more years with active development throughout that period.

What "Brownfield" Migration Actually Means in Practice

The term brownfield migration gets used often and explained rarely. At its core, it means migrating a real, working system to the cloud rather than building a new one - preserving the functionality, data, and integrations the business depends on, while updating everything incompatible with the new environment.

In a complex Dynamics estate, that means working through every layer of the platform. Every plugin assessed and refactored for sandbox isolation mode, which prohibits the kind of direct server access that many legacy plugins assume. Every JavaScript resource validated against modern CE client API standards, with deprecated usage rewritten. Every deprecated component - Silverlight controls, Microsoft Dialogs - replaced with cloud-native equivalents that match the original functionality without inheriting its architecture.

On top of this, the solution management problem. 200+ unmanaged solutions represent a significant operational risk in any cloud environment. They need to be rationalised, documented, and repackaged as managed solutions within a proper Application Lifecycle Management framework - introducing source control and automated deployment pipelines for the first time in many cases.

None of this is glamorous work. But it is the difference between a cloud platform that launches cleanly and one that breaks in a dozen ways on day one.

The Integration Workstream That Gets Underestimated Every Time

Most CRM migration planning focuses heavily on the platform - data model, customisations, reports. What gets underestimated almost every time is the integration estate.

In a mature Dynamics environment, the CRM is rarely an island. It is connected to a finance system, a customer portal, a marketing platform, assessment or qualification systems, third-party data feeds. Each connection is a dependency that needs to be either preserved or re-engineered as part of the migration.

For organisations running Microsoft BizTalk Server as their integration middleware, this is particularly acute - because BizTalk is itself approaching end-of-life. The migration programme becomes not just a CRM cloud migration but a simultaneous decommissioning and replacement of the entire integration layer, while every connected system remains operational throughout.

The organisations that manage this well do so by decoupling the two workstreams. They develop new cloud-native integrations in parallel with the platform migration, using a synchronised cloud environment as a development target from the earliest sprints, rather than waiting for the platform migration to complete before starting integration work. This is a specific technical and delivery model decision, and it has a significant impact on programme timeline and risk.

Why Storage Cost is a Migration Design Decision

One of the most consistently underestimated aspects of a Dynamics cloud migration is the ongoing storage cost. Microsoft Dataverse prices on consumption, and if you migrate a large, mature dataset without addressing its composition, your monthly bill can be significantly higher than it needs to be from day one.

In most large membership or professional services CRMs, a handful of tables account for most of the database volume - typically file attachments, historical activity records, and audit logs. Much of this data is beyond its active retention value. Migrating it wholesale to premium Dataverse storage is expensive and avoidable.

A pre-migration data strategy - profiling the dataset, pruning records against retention policies, and relocating high-volume binary data like file attachments to lower-cost SharePoint or Azure Blob storage, can reduce ongoing monthly storage costs by meaningful amounts. Treating this as a post-migration concern means paying the overage from go-live day until the remediation is eventually completed.

What a Well-Executed Migration Actually Looks Like

A well-executed Dynamics 365 cloud migration in a complex environment does not look like a shortcut. It looks like a programme - multiple parallel workstreams, each with its own engineering discipline and quality gates. Platform remediation. Integration re-engineering. Data migration with exponential validation. Reporting continuity. Security implementation. Change management. UAT.

Critically, it ends with a platform that is clean. Not just functional - genuinely clean. Managed solutions. Source control. Automated deployment pipelines. Documented architecture. A platform where the next development team does not inherit twelve years of accumulated technical debt on day one.

That is what the cloud migration is actually for. Not just to move the system from one hosting environment to another. But to arrive at the other end with something materially better than what you started with.

VE3 specialises in complex brownfield Dynamics 365 cloud migrations for organisations in professional services, membership, education, and the public sector. If your CRM estate has significant customisation depth and you are planning a migration, we welcome the conversation. ‍

‍Get in touch now.

‍