CRM Data Cleansing Checklist Before Migration - Relaticle [ Back to blog ](https://relaticle.com/blog) ![CRM data cleansing: a checklist before migration](https://relaticle.com/storage/ink/01M38HCR6VHYECX10S1TNTZN3P.png) CRM data cleansing before migration should resolve uncertain identity, missing ownership, and broken relationships before records enter the new system. Preserve the original export, group suspected duplicates for review, and record every keep, combine, or exclude decision. Then assign responsibility for unresolved records and test the cleaned data on a small import. Use this checklist in order: preserve the export, review duplicate candidates, choose surviving values, assign owners, translate relationships, and test a connected sample. Fewer rows alone do not prove better data. Combining different customers can cause more damage than leaving a duplicate for review. This guide produces a cleanup ledger and an exception queue. Use our [HubSpot and Attio migration guide](https://relaticle.com/blog/migrating-from-hubspot-or-attio-to-a-self-hosted-crm) for the export and import mechanics. Here, we focus on deciding what the data should say. [](#sort-the-problems-before-changing-records "Permalink")Sort the problems before changing records --------------------------------------------------------------------------------------------------- Start with a copy of the source export. Record its date, source workspace, filters, and row count. Keep the original available throughout the migration. Put problems into three groups: identity, responsibility, and completeness. | Group | Example | Decision required | |---|---|---| | Identity | Two companies share a domain | Decide whether they represent one organization | | Responsibility | An active company belongs to a former employee | Assign an accountable current owner | | Completeness | An opportunity lacks its company link | Find the relationship or record the uncertainty | This separates mechanical cleanup from business judgment. Trimming extra spaces is mechanical. Deciding which employee owns a renewal requires someone who understands the customer. The [Government Data Quality Framework](https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework) distinguishes completeness, uniqueness, consistency, timeliness, validity, and accuracy. Those dimensions provide useful vocabulary for your review. A value can pass format validation and still identify the wrong customer. Prioritize records involved in current work. Open opportunities, active customers, and outstanding tasks usually deserve review before dormant leads. That is a scheduling choice, not permission to discard the rest. [](#build-duplicate-candidates-without-declaring-winners "Permalink")Build duplicate candidates without declaring winners ------------------------------------------------------------------------------------------------------------------------- Create candidate groups using strong matching values. Company domains and people's email addresses can reveal likely overlaps. Names can help a reviewer find candidates, but names alone should not decide a merge. Consider two fictional records: "Northline Studio" and "Northline Studio Ltd." Both carry `northline.example`. One contains the current account owner. The other contains an open opportunity and the most recent person. Deleting either record immediately could lose useful information or detach related work. First compare their identifiers, relationships, timestamps, and business context. A candidate review should answer four questions: 1. Do these rows represent the same real organization or person? 2. Which row supplies the destination record's identity? 3. Which field values and related records must survive? 4. Which disagreements need a human decision? Be more cautious with shared domains, generic inboxes, and common names. A parent company and subsidiary may use one website. A shared purchasing address may belong to a department rather than an individual. Do not automatically remove email aliases or rewrite addresses to make them match. A rule that works for one provider can change a valid address elsewhere. [](#write-a-field-level-survival-rule "Permalink")Write a field-level survival rule ----------------------------------------------------------------------------------- "Keep the newest record" is rarely precise enough. A recent edit might only reflect a formatting change. An older record might carry the verified billing contact. Choose survival rules by field. For account ownership, ask the person responsible for the customer. For a company domain, use the domain your team has confirmed. For notes, preserve useful context and its provenance. Use one ledger entry per decision. This filled example follows two fictional company records that a reviewer confirmed represent the same business. ``` Decision ID: CLEAN-001 Source IDs: company-184, company-219 Surviving source ID: company-184 Candidate match: Both use northline.example Identity evidence: Account manager confirmed one organization Conflicting values: company-184 has the current owner; company-219 has the newer person Field decision: Keep the confirmed owner and current domain Relationship decision: Preserve people from both companies Excluded destination row: company-219 Reason: Its useful values and links move to company-184 Reviewer: Priya, account manager Decision date: [record the actual review date] Unresolved questions: None for this example Destination ID: [fill after creating the company] ``` The ledger records an approved transformation, not just a row to delete. It explains where useful information from the excluded record will go. For an unresolved candidate, leave the surviving ID blank and assign the identity question to a reviewer. Do not make a tentative merge look approved. Keep conflicting values visible until someone resolves them. Do not overwrite "Proposal" with "Discovery" merely because one CSV row appears later. When preparing a clean destination file, retain source IDs for every contributing record in the ledger. That lets you trace a destination record back to all source material. [](#reconcile-owners-before-assigning-work "Permalink")Reconcile owners before assigning work --------------------------------------------------------------------------------------------- Build a roster of current team members and the email each person will use in the destination workspace. Compare it with the owner values in the export. Names are weak identifiers here too. "Alex" may refer to more than one person. A former teammate's address may still appear on active customers. A distribution list may not represent an accountable owner. Classify every unresolved owner: 1. A current teammate using a different email address. 2. A former teammate whose companies need reassignment. 3. A shared queue that needs an agreed responsible person. 4. A blank value that requires review. Have the account manager or team lead approve reassignment. Do not assign every missing owner to the migration operator for convenience. That hides the workload and makes later reports misleading. Relaticle's company importer can resolve account owners by workspace-member email. Its task importer can resolve assignees by email. Invite the relevant teammates and confirm membership before testing those mappings. Use the [team invitation guide](https://relaticle.com/help/getting-started/invite-your-team) for that setup. Keep pending invitations separate from confirmed ownership decisions until the sample proves the expected assignment. [](#repair-relationships-after-identity-decisions "Permalink")Repair relationships after identity decisions ----------------------------------------------------------------------------------------------------------- Duplicate cleanup affects more than the duplicate records themselves. People, opportunities, tasks, and notes may still point at source records you excluded from the destination file. Build a relationship translation alongside the cleanup ledger. Every excluded duplicate ID should resolve to the surviving source identity. Later, connect that identity to the destination record ID. Suppose two source companies become one destination company. A person linked to the excluded source company still needs the surviving destination company. Deleting the duplicate row alone does not perform that translation. For CLEAN-001, suppose person-731 originally points to company-219. Your translation has two steps: 1. Translate company-219 to the surviving source identity, company-184. 2. Translate company-184 to the actual destination ID returned after company creation. Keep both source IDs in the mapping. People attached to either original company must reach the same destination company. ``` Source company: company-184 Surviving source identity: company-184 Destination company: [actual destination ID] Source company: company-219 Surviving source identity: company-184 Destination company: [same actual destination ID] Source person: person-731 Original company: company-219 Resolved destination company: [same actual destination ID] ``` These placeholders describe your migration ledger. Replace them with actual destination IDs before using an import mapping. For Relaticle imports, use a company domain or Relaticle Record ID when linking an existing company. Matching a related company by Name can create another company. The [record-type import reference](https://relaticle.com/help/import/what-each-record-type-needs) explains the available matches. Check relationships in both directions. Open a person and confirm the company. Then open that company and confirm the person appears where expected. Repeat the exercise for an opportunity and its point of contact. For tasks or notes linked to opportunities, preserve the opportunity mapping explicitly. A matching title is not a substitute for the required destination ID. [](#decide-what-to-do-with-stale-records "Permalink")Decide what to do with stale records ----------------------------------------------------------------------------------------- Age alone does not prove a record is useless. A quiet customer might still have a live contract. An old entry for a person might explain a current buying relationship. Ask whether the record supports current work, historical analysis, or a specific retention requirement your team has already established. Separate those reasons in your inventory. Use three outcomes: import now, retain in an accessible archive, or review before deciding. Assign an owner and deadline to the review queue. If you choose an archive, document its location and who can access it. Preserve enough source identifiers to find the relevant record later. Test a retrieval before closing the old CRM. Do not present exclusion from the first import as deletion from the source. Those are different actions with different consequences. Your migration plan should state when either action will happen. Avoid a vague "miscellaneous" file that nobody owns. An exception queue needs the source ID, problem, reviewer, and required decision. Otherwise, the migration simply moves uncertainty into another spreadsheet. [](#keep-cleanup-edits-narrow-and-reviewable "Permalink")Keep cleanup edits narrow and reviewable ------------------------------------------------------------------------------------------------- Separate identity decisions from formatting corrections. First decide which records should exist and how they connect. Then standardize the values you will import. Keep edits scoped to the intended fields. A file meant to correct owners should not also rewrite stages and contact details unless those changes received review. Relaticle supports updates through import when rows match existing records. Its multi-value fields merge imported values with existing values. That can preserve useful email addresses, but it does not express every replacement you might want. Test how your update handles an empty cell, an additional value, and a value you intend to remove. Inspect the saved record after each case. Do not infer removal behavior from a successful addition. Stop if the preview shows Create for a record you expect to exist. Check its email or domain before you continue. Use verified Relaticle Record IDs for the retry. For relationship corrections, fix the CSV and upload it again, then inspect the saved links. Rela, the built-in AI assistant, can also propose batches of record changes. Review the specific records and differences before approval. A plausible explanation does not establish that two similarly named records represent the same customer. If you use an external assistant, our [Claude and MCP connection guide](https://relaticle.com/blog/how-to-connect-claude-to-your-crm-with-mcp) explains the connection path. Tool access does not replace the duplicate-review decisions in your ledger. [](#test-a-cleaned-relationship-group "Permalink")Test a cleaned relationship group ----------------------------------------------------------------------------------- Choose a small connected set: a company, two people, one opportunity, a task, and a note. Include a record affected by duplicate cleanup and one affected by owner reassignment. Write the expected relationships and values before importing. Then compare both the import preview and the saved records with those expectations. Count the records, but also inspect meaning. A correct total can conceal a task assigned to the wrong person. A person can appear in the destination with the wrong company. Test a second import only when your workflow depends on repeated updates. Notes require particular care because Relaticle's note importer always creates new notes. Do not replay successful note rows as a routine retry. Record unresolved differences and stop the larger batch until they have owners. The [import error guide](https://relaticle.com/help/import/fix-import-errors) helps distinguish upload, mapping, and validation problems. [](#hand-over-the-decisions-with-the-data "Permalink")Hand over the decisions with the data ------------------------------------------------------------------------------------------- Give the destination administrator more than a cleaned CSV. Include the original export, cleanup ledger, owner roster, relationship mapping, and remaining exception queue. The acceptance check is concrete: another teammate should be able to explain a changed owner, a combined company, and an excluded record. They should also know who handles the unresolved cases. Keep the ledger available during the first operating week. When someone asks where a familiar record went, it should answer without guesswork. After that, assign a recurring owner for the same three checks: uncertain identity, missing responsibility, and broken relationships. Teams call this routine CRM data hygiene. The migration is a useful moment to start it, but it does not maintain data quality by itself. Tagged: [ #migration ](https://relaticle.com/blog/tag/migration) Related posts ------------- [ Guides Oct 30, 2026 How to design CRM custom fields your team will use ---------------------------------------------------- Design CRM custom fields with a field dictionary, clear empty values, and worked examples you can test across forms, imports, and APIs. ![How to design CRM custom fields your team will use](https://relaticle.com/storage/ink/01M34D9JFP41HRBX4Z79ZZRBT7.png) ](https://relaticle.com/blog/design-crm-custom-fields-your-team-will-use) [ Guides Oct 27, 2026 Sales pipeline stages for small B2B teams ------------------------------------------- Sales pipeline stages for small B2B teams, with a six-stage template, three worked decisions, and clear rules for stalled proposals and verbal agreements. ![Sales pipeline stages for small B2B teams](https://relaticle.com/storage/ink/01M34D3CNENN8NAZ9B0DY4AP2K.png) ](https://relaticle.com/blog/sales-pipeline-stages-for-small-b2b-teams) [ Guides Oct 23, 2026 AI CRM evaluation: tests to run before moving data ---------------------------------------------------- An AI CRM evaluation kit with fictional records, three prompts, an answer key, and separate approval checks for built-in chat and external MCP clients. ![AI CRM evaluation: tests to run before moving data](https://relaticle.com/storage/ink/01M38HXRE27ZBW8HW6D0VPVRFP.png) ](https://relaticle.com/blog/how-to-evaluate-an-ai-crm) ### On this page