.png){kind=small}
Most conversations about CRM data migration focus on the move: the tools used, the duration of the cutover window, the validation approach, the go-live moment. These are important. But they are not where the consequential decisions are made. The decisions that determine the cost, complexity, and long-term outcome of a CRM data migration are made weeks or months before the first record moves - in the profiling, planning, and optimisation work that most organisations either rush through or skip entirely.
This is where the hidden cost of data migration lives. And for organisations moving mature, large-scale CRM estates to the cloud - particularly to Microsoft Dataverse - getting this phase right can mean the difference between a migration that delivers ongoing cost savings and one that locks in expensive storage obligations for years.
The Problem With "Move Everything and Sort It Out Later"
The path of least resistance in any data migration is to move everything: replicate the full on-premises dataset to the cloud, validate the counts match, declare success, and address data quality and storage costs as a post-migration activity. It is an approach that minimises short-term planning effort and maximises long-term operational cost.
For organisations migrating to Microsoft Dataverse, the underlying data platform for Dynamics 365 Online, this is particularly consequential. Dataverse storage is priced at a premium compared to the on-premises SQL Server environment it replaces. An organisation with 900 GB of on-premises CRM data may find, after a direct lift-and-shift, that a disproportionate share of that volume consists of file attachments, historical activity records, and audit logs that could have been moved to significantly lower-cost storage with no loss of accessibility.
Three tables: attachments, activity history, and audit logs, routinely account for 50–60% of total CRM database volume in mature platforms. They are almost never the tables that matter most to daily operations. Yet without intervention, they travel to Dataverse at full Dataverse storage rates.
What Pre-Migration Data Optimisation Actually Involves
Effective pre-migration data work has three components, each of which requires time, access, and engagement with the organisation's data governance and legal teams.
Data Profiling
Before any decisions are made about what to move, what to archive, and what to delete, you need an accurate picture of what you actually have. Data profiling quantifies volume distribution by table, identifies records that fall outside retention policy, surfaces data quality issues that will affect migration integrity, and flags any data that carries specific regulatory handling requirements. Without this, all subsequent decisions are made on assumptions.
Retention Policy Alignment
Most organisations have a data retention policy. Far fewer have ever applied it systematically to their CRM data. A pre-migration programme is the natural moment to do this. Records that exceed the organisation's established retention periods - activity history older than five years, prospect records older than two years, expired case records, can be safely archived or deleted in compliance with Fair Processing Notices before migration, rather than carried to the cloud at premium storage rates.
Storage Tiering Strategy
Not all data belongs in Dataverse. File attachments - which in mature CRM platforms can represent 200 GB or more of storage volume - are a prime candidate for relocation to lower-cost alternatives such as SharePoint or Azure Blob Storage. Microsoft's virtual table capability in Dataverse means relocated files remain accessible from within the CRM interface without any change to the user experience. The saving is entirely in the storage billing.
The SSRS Reporting Problem: A Specific Data Architecture Challenge
For organisations migrating Dynamics CRM to the cloud, there is a specific reporting continuity challenge that deserves its own consideration. SQL Server Reporting Services - the reporting infrastructure used by the majority of mature on-premises Dynamics environments - is not natively supported in Dynamics 365 Online.
This creates an immediate problem at go-live: every SSRS report that the business depends on will cease to function unless a migration strategy is in place. For organisations with 100 or more active SSRS reports, recreating them all from scratch in the new environment is both expensive and highly disruptive - particularly when those reports are embedded in operational workflows that span multiple departments.
The practical solution is an Azure SQL replication architecture: a dedicated Azure SQL database that receives a continuously refreshed mirror of Dataverse data, with existing SSRS reports repointed to this new data source rather than recreated. This preserves reporting continuity from day one of go-live, protects the organisation's existing investment in report development, and allows the transition to modern Power BI-based reporting to happen at a controlled pace post-migration rather than under go-live pressure.
Validation: Why Exponential Beats Sequential
When the time comes to actually move the data, the validation approach matters as much as the tooling. The most common mistake in large-scale CRM data migration is attempting to validate integrity only at the end - running the full migration and then checking whether counts match and samples look correct.
A more robust approach is exponential staging: migrate 1% of the data and validate comprehensively, then 5%, then 25%, then 50%, then 100%. Issues discovered at 1% are trivial to resolve. The same issues discovered at 100% - after a full production cutover - are not.
This approach also requires multiple full mock migrations in a staging environment before the production cutover takes place. For a complex, highly customised CRM with multiple database dependencies, a minimum of three full mock migrations is the industry standard for responsible delivery. Each mock migration builds confidence, surfaces edge cases, and refines the cutover procedure - so that the production go-live is executing a proven, rehearsed process rather than attempting something for the first time under pressure.
The Multiple Database Challenge
Mature Dynamics CRM platforms typically do not consist of a single database. It is common to find a core CRM database, a master configuration database, one or more auxiliary databases supporting specific processes, and a legacy reporting database. Each has different technical characteristics and a different optimal destination in the cloud architecture: the core database to Dataverse, auxiliary databases with complex SQL logic to Azure SQL, and legacy reporting databases to the analytics layer.
Applying a single migration strategy to all databases is one of the most common root causes of programmes that run over schedule. Treating each database as a distinct engineering problem - with its own strategy, timeline, and validation criteria - is what keeps complex migrations on track.
The Cost of Getting This Wrong
The financial case for rigorous pre-migration data work is straightforward. For an organisation with a 900 GB CRM database migrating to Dataverse, the difference between a direct lift-and-shift and an optimised migration - with retention-based pruning and attachment tiering to lower-cost storage - can exceed £15,000 per month in ongoing storage costs. Over five years, that is a material budget variance that compounds from the first day of go-live.
But the cost of getting data migration wrong is not only financial. Data integrity failures discovered post-go-live - duplicate records, broken relational data, missing historical records - damage operational confidence in the new platform and require expensive remediation programmes that are far harder to execute in a live production environment than in a controlled migration context.
The organisations that look back on their CRM data migration as a success are those that treated data not as a migration constraint to be managed, but as a strategic asset to be optimised in transit.
VE3 brings deep expertise in CRM data migration strategy, pre-migration optimisation, and Dataverse architecture. If you are planning a Dynamics 365 cloud migration, speak to our team about how we approach the data workstream - and how to avoid the hidden costs that most programmes underestimate.
.png)
.png)
