What to Clean Up Before Migrating Data Into a New CRM

A new customer relationship management system is often presented as a route to cleaner data, better reporting and more consistent service. Those benefits are possible, but the software cannot decide which of three contact records is correct, whether an old sales opportunity is still live, or who should own an account after two departments have been reorganised.

If unresolved data is simply copied into the new platform, the migration preserves the same uncertainty behind a more modern interface. Staff still keep private spreadsheets, reports still disagree, integrations still fail on unexpected values and confidence in the new system falls quickly. The project then spends its early months repairing problems that existed before launch.

Data preparation is therefore not a final technical exercise. It is part of defining how the organisation will manage customers, cases, opportunities and communications after the change. The strongest migrations use the move to settle ownership, remove avoidable duplication, document important meanings and prove that the new records support real work.

Start with the decisions the CRM must support

A data inventory can become very large before the team has agreed what the new system is for. Begin with the business decisions and transactions that the CRM must support. That might include assigning an enquiry, progressing an opportunity, managing consent, recording a service interaction, forecasting income or giving an account manager a complete view of a relationship.

For each important journey, identify the information needed to complete it and the evidence required afterwards. A sales forecast may depend on agreed opportunity stages, expected values, probability rules and close dates. A support process may depend on the customer organisation, contact details, service entitlement, case priority and a reliable history of previous actions.

This creates a useful boundary. Not every field in the old system deserves to be migrated simply because it exists. Some data is obsolete, some duplicates information held elsewhere, and some was created for a process the organisation no longer follows. A field should have a clear purpose in the future service, a defined owner and an agreed rule for keeping it current.

Give each data area an accountable owner

Technical teams can extract, profile and transform records, but they should not be expected to decide what an inactive customer means or which department has authority to change a service classification. Those are operational decisions.

Assign an accountable owner for each important data area, such as organisations, contacts, opportunities, cases, products and consent. The owner does not need to correct every record personally. They need to approve definitions, resolve disputed rules, nominate knowledgeable reviewers and accept the migrated result.

Be explicit about decisions that cross teams. Marketing may use a contact status differently from sales. Finance may recognise a customer at legal-entity level while account managers think in brands or sites. Service teams may need a household or case relationship that does not fit a conventional business account. These differences should be designed into the new model rather than forced into one field during import.

Inventory every source, including unofficial ones

The existing CRM is rarely the only source. Important records may also sit in finance software, mailing platforms, support tools, shared spreadsheets, website forms, event systems, personal contact lists and archived databases. If these sources are discovered after the target structure has been built, the team may need to redesign mappings or repeat work.

For each source, record:

• the system or file owner;
• the record types and approximate volumes;
• the unique identifiers available;
• how frequently the data changes;
• which other systems receive or update it;
• known quality, access or retention issues;
• whether the source will remain live after migration.

Profile the data rather than relying on field names. Measure missing values, unexpected formats, duplicate rates, date ranges and the number of distinct values in coded fields. A column called Status may contain several spellings, blank values and notes that were entered when the available options did not fit. Those patterns reveal the real work required.

Decide which source is authoritative

When the same fact appears in several systems, the migration needs a rule for choosing the trusted value. The newest timestamp is not always the answer. A recently edited mailing record may have a better email address, while the finance platform may be authoritative for the legal name and billing status.

Define the source of truth by attribute where necessary. Document whether the value should be copied once, synchronised after launch or maintained only in the authoritative system and displayed elsewhere. Without that decision, the new CRM can begin with clean data and then drift as connected systems overwrite one another.

Keep these rules readable by operational staff. A complicated transformation may still be required behind the scenes, but the business rule should be understandable: for example, finance owns the registered organisation name, the customer portal owns the user’s current communication preference, and the CRM owns the assigned account manager.

Resolve identity and duplicates before import

Duplicates are rarely solved safely by matching one field. Two people can share a name, one person can use several email addresses, and a group of companies can share a domain. Equally, spelling differences and old addresses can hide records that belong together.

Create matching rules appropriate to each record type. An organisation might be compared using company number, billing identifier, normalised name, postcode and website domain. A person might be compared using email, phone, name and their relationship to an organisation. Use exact matches for strong identifiers and route uncertain matches to review.

Decide what merging means. One record may have the best contact details while another carries the important activity history, consent evidence or open opportunities. The process must retain the useful relationships and record why the surviving identity was chosen. It should not quietly delete the less complete row and everything linked to it.

Also define how duplicates will be prevented after launch. Search-before-create behaviour, integration keys, validation rules and stewardship reports are more valuable than a one-off clean-up that allows the same problem to return.

Map meanings, not just columns

A field-to-field spreadsheet is necessary, but it is not enough. Two fields can have similar names and different meanings. An old Customer Type value may combine sector, contract status and service level, while the new CRM holds those concepts separately. Copying the text into the nearest field would make the import look successful while damaging later reporting and automation.

For every mapped field, document:

• the business definition;
• the source and target format;
• allowed values and how old values translate;
• whether the field is required;
• the treatment of blanks, invalid values and exceptions;
• the owner and future update route;
• any effect on permissions, workflows or reports.

Do not turn every source value into an option in the new system. A list containing Current, current client, Live and Yes may represent one intended status. Agree the target vocabulary, transform valid equivalents and isolate records whose meaning cannot be determined.

Separate correction, transformation and exclusion

Not every poor-quality record needs the same response. It helps to classify issues into three groups.

Correction is appropriate when the right value can be established, such as a malformed postcode checked against a trusted address. Transformation changes a valid old representation into the agreed target format, such as splitting a combined name or translating a status code. Exclusion applies when data has no future purpose, should no longer be retained or is too uncertain to import safely.

Keep an exception list rather than forcing questionable records through the main import. Each exception should have a reason, owner and resolution. Some can be fixed before cutover, some can be loaded into a controlled review queue, and some should remain in a restricted archive for an agreed period.

This is also the point to apply retention and data-protection decisions. A migration should not become a reason to keep every historic contact indefinitely. Confirm the lawful purpose, retention period, consent or preference evidence, and access requirements for the data being moved. Remove or archive records according to the organisation’s policy, with an audit trail of the decision.

Protect relationships and activity history

A CRM is valuable because records are connected. Contacts belong to organisations, opportunities refer to products, cases have owners, emails relate to interactions and activities form a timeline. Importing the main tables while losing these relationships can produce a technically complete record count and an operationally unusable system.

Preserve stable source identifiers during the migration, even if the new platform creates its own identifiers. Use them to rebuild relationships, reconcile results and trace a target record back to its origin. Define the order of loading so that parent records exist before dependent records are connected.

Be selective with activity history. Staff may need recent communications and important decisions in the live timeline, but importing years of low-value automated messages can make the new CRM slow and difficult to use. Agree which history needs to be searchable in the live platform and which can remain in a secure, accessible archive.

Rehearse with real data more than once

The first realistic import should not happen during the final cutover. Run repeated migrations into a non-production environment using representative data volumes and the same transformation process intended for launch.

Each rehearsal should produce evidence:

• source, transformed and target record counts;
• records rejected, merged, excluded or changed;
• relationship and attachment success rates;
• timings for extraction, transformation, loading and validation;
• sample results accepted by data owners;
• performance of important searches, reports and workflows.

Make the process repeatable. Manual corrections made only in the test CRM will disappear when the final import runs. Put approved transformations into scripts or controlled source files, version the mapping rules and record the input snapshot used for each rehearsal.

Test integrations against the cleaned model

A CRM migration often changes more than the user interface. Website forms create leads, finance platforms supply account information, marketing tools consume preferences, reporting systems extract measures and identity platforms control access. Each connection may depend on old identifiers, status values or assumptions about required fields.

Test integrations with the transformed data, including awkward cases. Confirm how they handle merged records, missing optional details, deactivated users, new option values and records awaiting review. Prove that retries do not create duplicates and that failures are visible to a support team rather than disappearing into a background queue.

Decide which system is allowed to update each shared attribute after launch. A technically successful migration can still unravel if two integrations continue to compete over the same field.

Plan the final change window

Data continues to change while the migration is being prepared. The cutover plan needs to explain what happens between the final source extract and the point at which staff begin using the new CRM.

Choose whether the old system will become read-only, whether a final incremental load is required and how urgent work will be handled during the change window. Define the rollback decision, not only the rollback technology. The team needs to know which validation failures would prevent launch, who can make that decision and how work recorded during the window would be recovered.

Communicate the freeze and responsibility clearly. Staff should know when to stop updating personal trackers, where new enquiries should go and when the new system becomes authoritative. Otherwise, a technically correct final extract can still miss records entered through an unofficial route.

Validate business outcomes after loading

Record counts are useful, but equal counts do not prove that the data works. Validation should combine automated reconciliation with named operational checks.

Data owners should be able to find known customers, see the expected contacts and history, open active opportunities, follow current cases and produce key reports. Totals should reconcile by meaningful groups, such as opportunity stage, region, service or owner, rather than only at whole-table level. Permissions should be tested to confirm that users can see what they need without gaining access to inappropriate records.

Agree acceptance thresholds before the final run. Zero unresolved errors may be necessary for financial identifiers or consent evidence, while a small, controlled review queue may be acceptable for optional historic classifications. What matters is that the exception is understood, owned and does not prevent safe operation.

Keep data quality as an operating responsibility

A clean launch is temporary unless the organisation changes how data is maintained. Build proportionate controls into the service: clear required fields, useful validation, duplicate detection, integration monitoring and reports that identify ageing or incomplete records.

Give people a route to correct data without creating workarounds. Review whether fields are actually used and remove those that collect noise. Track a small set of quality measures, such as duplicate rate, completeness of critical fields, records without an owner and integration failures awaiting action.

Most importantly, keep named ownership in place after the project team leaves. The definitions and matching rules created for migration should become part of normal governance, training and support.

Conclusion

A CRM migration succeeds when the new platform supports clearer decisions and more dependable work, not when every old row has been copied. That requires the organisation to agree what data is needed, who owns it, which source is trusted and how duplicates, history, exceptions and integrations will be handled.

Start the clean-up early, rehearse with realistic data and validate real customer and staff journeys. The result is more than a smoother import: it is a CRM that people can trust from the first day and a practical model for keeping its data useful afterwards.