What is data quality in a migration?

Data quality describes whether the information being migrated is accurate, complete, consistent and suitable for use in the destination system. It also includes the relationships between records and whether the migration criteria will preserve the information the organisation needs.

What does DQR stand for?

DQR stands for Data Quality Review. It is the process of assessing source data, identifying potential issues and agreeing how those issues should be handled before the final migration.

Does a Data Quality Review only look for incorrect data?

No. A Data Quality Review may identify incorrect or incomplete information, but it also examines duplicates, formatting, obsolete records, record relationships and conflicts within the proposed migration criteria. Some records may be accurate in isolation but cause problems because they depend on other data that has not been included.

Can poor data quality cause a migration to fail?

Yes. Poor data quality can result in records being rejected, information being missed, relationships breaking and totals failing to reconcile. Even when the technical transfer completes successfully, the migration can still fail in practical terms if users cannot trust or work with the data in the new system.

Should all historical data be migrated?

Not necessarily. Some historical data may no longer provide enough value to justify moving it into the new platform. However, older records should not be excluded based on age alone. They may still be connected to active payments, current contacts, important documents or reporting requirements.

Who should be involved in a Data Quality Review?

The review should involve migration specialists and people within the client organisation who understand how the data is used. The migration team can identify technical issues and unexpected patterns, while the client provides the operational context needed to make informed decisions about what should be migrated.

Can data quality issues be corrected after go-live?

They can, but correcting data in a live system is usually slower, riskier and more disruptive. Users may already be working with the affected records, while automated processes may depend on them. It is safer to identify and resolve as many issues as possible during preparation and test migrations.

Planning a Microsoft Dynamics 365 CRM data migration

Key points

Start data profiling, mapping and test loads alongside the design of your new CRM. Leaving migration until the end can expose problems too late to resolve comfortably.
Review custom fields, duplicate customer records and disconnected notes or activities before importing them.
Map source values to the fields and relationships configured in Dynamics 365 Sales, including agreed choices and record ownership.
Plan the loading sequence around record dependencies, and allow for API throttling when estimating the migration window.
Decide which historical information belongs in the live CRM and which should remain accessible in an archive.
Use test loads to check customer history, access permissions and reporting, as well as whether the import completes.

George Tye

CEO & Founder

What needs to happen before you move your CRM data into Dynamics 365?

Moving to Microsoft Dynamics 365 Sales gives your team an opportunity to review how customer information is organised. It also brings old data problems into view.

Duplicate companies, inconsistent custom fields and notes with no clear link to a customer all need attention before staff can rely on the new CRM.

At Migrate Data, clients regularly come to us from Zoho CRM, Salesforce, HubSpot, legacy SQL databases and older on-premise systems. T

he preparation depends on how each organisation has used its database, including the workarounds and customisations that have accumulated over time.

This guide focuses on Dynamics 365 Sales and its underlying Dataverse platform. Other Dynamics applications can require different migration approaches.

Our Microsoft Dynamics data migration service starts by establishing the source, destination and information your team needs to use.

What problems commonly appear in the source data?

An export can show you which fields contain information without explaining whether that information is consistent or useful. We regularly encounter three areas that need closer investigation.

Custom fields that have become difficult to interpret

Free-text fields let people record useful detail, but they can become unreliable for reporting when teams use them inconsistently. This can happen in Zoho or any CRM configuration that relies on text entry for information that would benefit from agreed categories.

For example, one person might enter “Manufacturing”, another “Manufacturer” and a third a sentence describing the company.

If the destination uses a defined industry choice, the migration needs a rule for translating those entries. Ambiguous values need review by someone who understands the customers; guessing can create misleading reports.

Duplicate contacts and companies

Years of day-to-day entry can leave several records for the same customer. Those records may each contain different contact details, activities or sales history.

Agree how potential duplicates will be identified and which information should survive a merge. A shared company name alone may not be enough to establish a match. Where records are consolidated, their related information needs to follow the agreed surviving record.

Our data cleansing services can help address duplication and inaccurate contact details as part of this preparation.

Notes and activities with missing links

An old note, email or task may still exist even though its connection to an account or contact has been lost. These disconnected records are often described as orphaned data.

Investigate whether source identifiers or other reliable evidence can restore the relationship. Where a link cannot be established confidently, agree an exception process.

Attaching a note to the wrong customer can be more damaging than leaving it unresolved for review.

How should you map data into Dynamics 365 Sales?

Mapping needs to reflect the target configuration. A source field that looks similar to a Dynamics field may use different values or have a different purpose.

Dataverse supports text, choices, dates and lookups, among other field types. The migration must respect the destination field’s type and limits. Free text only needs converting to a defined choice where that is the agreed destination design. Relevant validation rules and custom logic also need to be tested through the chosen import route.

Mapping area	Question to resolve	Practical check
Choice fields	Which source values correspond to each approved destination value?	Review unmapped and ambiguous values before loading
Text fields	Will the destination accommodate the content that needs to be retained?	Identify values that exceed field limits rather than silently shortening them
Dates	What does each source date represent, and how should it be interpreted?	Test ambiguous formats and time-sensitive examples
Related records	Which account, contact or other record should each item link to?	Keep a traceable mapping between source and destination identifiers
Required information	Which values does the destination or migration route require?	Resolve missing values using agreed rules, without inventing customer information
Ownership and access	Who should own and be able to use the migrated records?	Test with representative users and their normal permissions

Keep the mapping decisions documented. If the new CRM’s configuration changes, review the affected mappings and repeat the relevant tests before the final migration.

Plan record ownership before loading

Historical records may refer to employees who have left or teams that no longer exist. Decide how those references should be handled in the new environment.

Dataverse supports user or team ownership for some tables and organisation ownership for others. There is no universal requirement to assign every record to an active individual user.

For records with an owner, agree valid destination assignments with the implementation team and check the associated access permissions.

Keep current responsibility distinct from historical attribution. Reassigning an account should not casually rewrite the retained history of who worked with that customer. Review how the chosen migration method will preserve the historical information you need.

“Data mapping, cleaning, and test runs should happen early alongside system design.”

Migrate Data Tweet

Allow for loading order and API limits

Records need to arrive in an order that allows their relationships to be established. For example, loading accounts before the notes that reference them can make it possible to attach those notes correctly. The exact sequence depends on the relationships and migration method.

Separately, Dataverse applies service protection limits to demanding API traffic. A bulk migration tool needs to handle throttling responses and retry after the indicated wait. Dividing data into batches alone does not remove those limits.

Use realistic test loads to estimate elapsed time, including validation and retries. The loading sequence addresses dependencies; throughput testing establishes whether the work fits the planned window.

Decide how much history belongs in the new CRM

Some organisations assume they need to move every record and attachment accumulated over the past 15 years. Before committing to that scope, ask how the information will be used.

Sales staff may need recent conversations, open opportunities and relevant customer history at their fingertips. Older material may still need to be retained, but accessed less frequently.

Moving it all into the live CRM can add migration work and storage requirements without helping everyday tasks.

Treatment	When it may be appropriate	What to agree
Migrate into Dynamics	Information supports current work, reporting or necessary customer context	Which records and relationships must be available at go-live
Retain in an archive	Information needs to remain accessible but is rarely used operationally	Search, access, retention and the link back to the customer
Exclude from migration	Information is outside the agreed scope or duplicates retained content	The reason for exclusion and what happens to the source copy

Excluding data from the migration is a separate decision from deleting it. Confirm retention needs and ownership of the archive, including how staff will retrieve information once the old CRM is no longer available. Our data storage services can help you explore that option.

A Zoho CRM to Dynamics 365 Sales migration in practice

In one client project, years of customer notes, activities and custom picklist values were spread across unlinked modules in Zoho CRM. Initial import attempts failed because required values were missing or incorrectly formatted.

Automated scripts were used to remove duplicates, standardise date formats and restore links between disconnected notes and the main customer accounts. A series of test loads followed, allowing the prepared data to be checked in Dynamics 365 Sales before the final move.

The migration was completed with minimal downtime, giving the team clean, reliable records from the first day of use. The preparation addressed both import failures and the relationships staff needed to understand each customer’s history.

This is why we recommend beginning the data work while the new system is being designed. The findings can influence decisions about fields, relationships and scope while there is still time to change them.

What should you test before the final migration?

A completed import does not demonstrate that every customer record is ready to use. Agree acceptance criteria with the people responsible for the data, then include representative and difficult cases in testing.

Reconcile record counts, allowing for documented merges and exclusions.
Inspect customer records to check that notes, activities and other related information are attached correctly.
Review mapped choices, dates and records that were flagged as exceptions.
Ask staff to find and use their records with normal permissions, rather than relying on an administrator’s view.
Compare agreed reports or totals and investigate differences before sign-off.

Plan how changes made in the old CRM after a test extract will be captured for the final move. Agree any pause in data entry, the final checks and who authorises go-live.

The transition plan should also state what happens if those checks fail, so the team has an agreed recovery approach.

If you are planning a move from Zoho, Salesforce, HubSpot or a legacy database, speak to Migrate Data about your Dynamics migration. Share the source systems, approximate data volumes, known issues and intended go-live date so the preparation can be scoped realistically.

Frequently Asked Questions

Can you migrate from Zoho CRM, Salesforce or HubSpot to Dynamics 365?

Yes. Migrate Data works with clients moving from these platforms, as well as legacy SQL databases and older on-premise systems. The extraction method and mapping depend on the source configuration, available access and destination application. Custom fields and related records need to be included in the review.

Is a Dynamics migration just an export and import?

Exporting and importing are parts of the process. The work also involves agreeing scope, resolving quality issues, transforming values, mapping relationships and testing the result. A straightforward import may be sufficient for a small, well-prepared dataset, but that should be established through review.

How long does a Dynamics 365 data migration take?

The timescale depends on the sources, data condition, relationships, history in scope and availability of staff to make decisions. An early review helps estimate preparation effort, while representative test loads help estimate the final migration window. Record count alone is not enough to give a reliable answer.

Can historical notes and activities be migrated?

They can be included where the source information is accessible and the destination supports the agreed representation. Check their links to customers, any relevant attachments and the context staff need to understand them. Disconnected records need investigation; recovering every missing relationship cannot be assumed.

Will migrating to Dynamics 365 require downtime?

Some projects need a controlled pause in updates while the final data is transferred and checked. The required window depends on the method, volume and handling of changes since the earlier extracts. Test the process before agreeing the window. The Zoho project described above achieved minimal downtime, but that is not a guarantee for every migration.

Do we have to migrate all our old data?

No. Agree which information supports live operations and which needs separate retention. An archive can keep older material accessible without including it in everyday CRM use. Decide how it will be searched, protected and maintained before retiring access to the original system.

Let Migrate Ensure Your Data Quality With a Full Review

Speak with a Migration Expert

Migrate Data can review a sample of your source data, identify the main migration risks and provide a clearer basis for the project scope, budget and timeline.