The short answer
Clean the CRM you have before you buy another one. A migration copies what is already there. Duplicates, blank owners, and fields nobody fills move with the records, and the new system starts out wrong.
Work in this order. Decide which records and fields a normal week uses. Name the system of record and one owner for each object. Audit duplicates and incomplete rows, write the merge rules, and archive what leaves the working views. Then fix the forms, imports, and integrations that made the mess. Skip that last step and the cleanup lasts until the next upload.
Sometimes that is the whole project. One account, one owner, and a date someone will stand behind will do more for a forecast meeting than a new platform. Replace the CRM only after the record is defined and the current system still cannot hold it. A revenue team, as an example and not a client story, often plans a replacement because the same account exists three times, the close date lives in a sheet, and the marketing list never matched. A new login page does not repair that.
Decide which records and fields actually matter
Sit with the people who use the CRM on an ordinary week: someone from sales, someone who inherits the customer, and the person who pulls the report leadership reads. Start from the jobs, not from the field list in the admin console.
For each job, write the object, the fields it needs, and what done looks like. A useful minimum for a customer is the company, the buyer, the person who uses the product, the contract start, and the outcome that was promised. An opportunity needs an owner, a stage the team can say in one sentence, an amount, and a date someone will stand behind. A contact needs a way to reach them.
Mark every other field keep, fix, or stop collecting. A campaign field from three years ago, a score nobody opens, and a required field people fill with a dash or "n/a" are the usual stops. If you cannot name who acts on a field, stop collecting it. The kept list fits on one page. That page is a complete record. Anything left off it does not get migrated, mapped, or made required.
Once the minimum customer is written down, the handoff between teams is a separate afternoon. Mapping a CRM handoff names the states and what the next person is allowed to assume. Do that on the fields you just kept, not on the full schema.
Name the system of record and one owner per object
A field in two places will disagree. For each object on the page, name the system allowed to be right, and the one person who may change that rule.
The CRM should own the customer, the open deal, and the handoff, unless you can say the exception out loud. Billing may own the invoice. Support may own the ticket. A marketing tool may own the campaign list. A spreadsheet can stay a view. It cannot stay the place a renewal is decided, a duplicate is merged, or a stage moves.
Ownership is a name. "Sales ops" and "the team" leave the record unowned. The account owner defines a duplicate and approves merges. The contact owner decides which email or phone number wins. The opportunity owner decides which stages are real. One person may own several objects. One object cannot have two owners. A fact re-keyed by hand every week has no system of record yet. An integration writes it on a schedule someone watches, or one person enters it and the other tool reads it.
That shared definition is where revenue operations enablement starts. Sales, marketing, and success use one customer record. Configuration comes after the definition, not before.
Audit duplicates and incomplete records
Audit the one-page definition, not every column in an export. Two questions cover it.
Is the record complete? List rows missing a field you kept: no owner, a contact with no company, a blank stage, a past close date on a deal someone still calls open. The owner fills the row, archives it, or drops the field because nobody can supply it.
Is it the same record as another? Duplicates hide in small differences. "Incorporated" on one row and not the other. A personal email beside a work email. A domain spelled two ways. An account a form created, and a second one a rep created because the first had no owner and never appeared in the working view. Choose the match keys before you trust a suggestion. Email for contacts. Domain for accounts. Account plus contact for open opportunities. When the domain already matches, look again at names that are close. A fuzzy match does not merge by itself.
Review a sample of groups with the owner before any bulk pass. Mark each group the same record, related but distinct, or not sure. "Not sure" means a rule is missing. Write it, then run the clear groups. Merging the unsure pile will combine two customers someone is about to call. Both rows in that form-and-rep pair can be real. Only one is the customer, and a person says which.
Write merge and survivorship rules
Survivorship is the written rule for which record survives a merge and which value wins each field. Put it on the same page as the definition, before anyone merges.
Prefer the account with the open opportunity, the recent activity, and an owner who answers for it. If both records have an open opportunity, stop. That is two deals, or one deal entered twice, and a person chooses before any merge.
Name a winner for each field you kept. A value a person set on purpose, such as the owner or the stage, stays with the surviving record. A value that goes stale, such as a phone number or a title, takes the latest update. A value another system is allowed to own, such as billing status, comes from that system. Notes keep the longer text only when someone will still read them. Do not paste every note from every duplicate into one field. Empty never wins, and neither does "Unknown," a dash, or "n/a." A blank must not overwrite a real email, a real owner, or a real close date.
Contacts, activities, and open opportunities on the losing record move to the survivor, unless the owner closes one on purpose. Do the first merges by hand, on the audit sample, with the owner watching. A tool may repeat those written rules on groups marked the same. It does not get a rule for "not sure." Log the losing name, the survivor, the date, and who approved it.
Archive instead of delete
Deleting a row is how a cleanup becomes an incident. A contract, an email thread, or a person may still point at it. Archive takes the record out of the working views and leaves the history findable.
Use a status, a record type, or a view you already have, and exclude it from the pipeline, the marketing sends, and the rep's default list. Rows that still appear in the forecast are not archived. Archive test records, vendors entered as customers, leads you cannot reach, opportunities closed in conversation and left open, and duplicates once the survivor is confirmed. The owner signs that list.
Keep the archive. If you hold personal data you no longer have a reason to keep, ask your counsel what retention applies. This guide is not that advice, and neither is a control labeled delete duplicates. What you archive, you do not migrate. The next system does not need every old workaround or every test account from the last implementation.
If the platform itself has to change, clean and archive first, then move a slice and have the person who does the job open the result. How to modernize a core system without stopping the work is the sequence around that move: the jobs, the owners, a cutover, and a way back. Loading the uncleaned CRM into the new one is how the new system starts out wrong.
Fix the paths that create the bad data
Leave intake alone and the next form, import, or sync rebuilds the mess. List every way a record is created, and write what that path may do.
Forms require the fields on the one-page list, not a longer set. Match a work-email domain to an existing account before creating a new one. No match means a lead a named person reviews, not a second account with no owner.
The object owner approves every import: the column map, the match key, and whether the file may create records or only update matches. Creating by default is a duplicate machine. Date a one-time file, and name who checks the result the same day.
Give each integration a direction. For the marketing tool, support, billing, and product signup, write what it may create, what it may only update, and which fields it must not touch. A sync that writes both ways, with no winner, undoes a merge overnight.
The screen a rep uses to create a record searches first, shows possible matches, and refuses a save that is missing a field you kept. If people type "n/a" to get past a rule, the rule is not doing the job. Change the field or the check.
Calls are one of those create paths. A phone system that makes a new contact for every number will grow a second set of people with no company and no owner. Connect your phone system to your CRM is the pass for which calls write a record and which fields they may fill. Point it at the match rules you just wrote, so a call updates the customer you already have.
Keep it clean after the project
Three things keep the record clean after the project: validation, the owners you named, and a review on the calendar. Without them, the audit ends and the data problem does not.
Validation is the one-page list, enforced where a record is created. Reject blanks and the placeholders you already named. Use a picklist where the team has the words: stage, reason, lead source. Keep email and phone checks loose enough that a real value still saves. A rule nobody can pass will be bypassed, and the bypass becomes the new way in.
New fields, integrations, and imports go through the object owner, who is allowed to say no. A field added for a report, with no job behind it, is how the schema grew the last time.
Review monthly, and more often until the audit is closed. Each owner looks at new duplicates on the match keys, new records missing a field you kept, and imports or syncs that ran. When the same source creates the same bad row every month, fix the source. Name who runs that review after the project meetings end. A training session does not own the record. If the forecast is still decided on a spreadsheet, the cleanup is not finished.
A short cleanup checklist
Use this as the CRM data cleanup and deduplication checklist. A line is done, or it is not.
The objects in this pass are listed, and every other object is explicitly out.
Each kept field is marked keep, fix, or stop collecting, and the complete record fits on one page.
Each object has one system of record and one named owner.
Duplicate match keys are written, and the owner reviewed a sample of groups before any merge.
Survivorship is written per field, empty and placeholder values cannot win, and child records have a destination.
The first merges were done by hand, and a log says what merged into what, when, and who approved it.
Archive is defined, excluded from the working views and the forecast, and used instead of delete.
Every create path is listed, including forms, imports, integrations, and manual entry, with what each may create or only update.
Validation rejects blanks and placeholder values on the fields you kept.
A named owner runs a recurring review, and the side spreadsheet is no longer where the decision is made.
Bring the one-page definition and the duplicate sample to a working session. Book a strategy assessment and we will use them as the agenda: whether the cleanup is the project, or whether the CRM still has to change once the record is one record.