TL;DR
- Look at an inherited CRM before you merge, delete or change anything.
- Listing every tool that writes to the CRM shows where duplicates come from.
- Ask each team what a duplicate means to them, since definitions differ.
- Past merges, scripts and record owners can explain much of what looks wrong.
- Dedupely shows how many duplicates an inherited CRM holds without changing any data.
You've just taken over a CRM. Maybe you're a new admin, a sales manager or the first RevOps hire. In your first week, you find the same company three times, contacts with no owner and reports nobody trusts.
The urge is to start fixing. But every record you merge or delete in week one is a decision made without context, and many merges can't be undone. The person who built the CRM made choices you can't see yet.
In this post, you'll see what to look at before touching anything. That means sources, your team's definition of a duplicate, past cleanups and owners. You'll also see how to turn those findings into a first, safe step.
Why to look before you fix
Start an inventory with the source, object, identifying field, owner and last import date. For example, compare contacts from one event import with the existing customer segment before changing either. That gives the first cleanup a defined scope.
A messy CRM looks like one problem. It's usually several, each with its own cause, owner and history.
Some of what looks wrong was done on purpose. Two records for one company may be two branches that different reps own. A field full of odd values may feed a report someone in finance depends on.
A short diagnosis protects you, too. When someone asks why you merged their accounts, you'll have an answer, and you'll know what the CRM looked like before you changed it.
Check what writes to the CRM
Duplicates keep coming back while their sources keep running. Before you clean, find out where records come from.
Integrations and syncs
List every connected app: marketing tools, phone systems, helpdesks, billing, enrichment and other CRMs. Note which ones create records and which only update them.
Forms and imports
Find the forms that create contacts and the lists that get imported. Event lists and purchased lists often arrive without a check against what's already there.
Migrations and acquisitions
Ask whether the CRM was ever migrated from another system or merged with another company's. Records from those moves often share a creation date or an import batch, which helps you find them.
Our post on deduplication across imports, migrations and syncs covers how each source creates duplicates.
Check how your team defines a duplicate
What counts as a duplicate is case by case. What one team considers a duplicate, another may not, and you've just joined a company with its own answer.
Ask sales, marketing and support separately. Sales may want one record per company, including branches, while marketing may want every email kept as its own contact. Support may care most about one person per inbox.
Write the answers down for each object: contacts, companies, leads and deals. Where teams disagree, that's a decision to make before any merge, and it's often the most useful finding of your first week.
Check what past cleanups did
Merges and their rules
Find out whether anyone merged records before, with which tool and with what rules for which value wins. A past merge may explain why some records have odd owners or missing history.
Scripts and automations
Look for workflows, scripts or scheduled jobs that edit, merge or delete records. One that's still running can undo your work or create new problems.
Matches someone already rejected
If a previous admin decided two records weren't duplicates, that decision may still hold. Ask before you merge records someone deliberately kept apart.
Check who owns what
Ownership is where many duplicate disputes start, because a merge decides which rep keeps the customer. Before merging, look at:
- Owners who left: records still owned by former employees.
- Placeholder owners: integration users or shared users that own thousands of records.
- Split ownership: the same company owned by two reps under two records.
Our post on duplicate records from a sales manager's point of view covers why ownership disputes start here.
Check what depends on the records
Merging can change record IDs and field values. Before changing anything, list what relies on them: reports leadership reads, workflows, sequences and integrations that store record IDs.
That list tells you which merges need extra care and who to tell before you start. Keep a backup of the records you plan to merge, as described in how to back up your CRM before a large merge.
| Check | What to look for | Why it matters |
|---|---|---|
| What writes to the CRM | Integrations, forms, imports, past migrations | Shows where duplicates come from and which will come back |
| How the team defines a duplicate | Each team's answer, per object | Prevents merging records someone needs apart |
| Past cleanups | Merges, rules, scripts, rejected matches | Explains odd data and avoids repeating mistakes |
| Owners | Former employees, placeholder owners, split ownership | A merge decides who keeps the customer |
| What depends on records | Reports, workflows, integrations storing IDs | Shows which merges need extra care |
| How many duplicates | Counts per object and per source | Sizes the work and sets a baseline |
Measure how many duplicates there are
Once you know the sources and the definition, count. Measure each object on its own and note where the duplicates came from. Our post on how to find out how many duplicates your CRM has walks through it.
That number is your baseline. It shows leadership the size of the problem and, later, how much the cleanup changed.
Then take a first, safe step
With the diagnosis done, start with the obvious duplicates: exact matches on the field that identifies each record, like email or domain. They're the least likely to be wrong, and they show your team that the cleanup is careful.
Send unclear matches to review, and reject a match only when you're certain it isn't a duplicate. Our post on where to start CRM deduplication covers the first merge in more detail.
If the CRM you inherited is Salesforce, our post on how to clean up an inherited Salesforce org covers that side.
How Dedupely helps you diagnose an inherited CRM
Connecting your CRM to Dedupely never merges, edits or deletes anything, so you can look before you touch. Preset duplicate searches are ready the first time you log in. Every search shows the number of matches and the number of records in them.
Understand the CRM before you change it
An inherited CRM carries the decisions of everyone who used it before you. Some of the mess is accidental, and some is on purpose, and from the outside they look the same.
Sources, definitions, past cleanups and owners turn a vague mess into a list of decisions. Then the first merge is one you can explain.
Frequently asked questions
What should I check first in an inherited CRM?
Start with what writes to it: integrations, forms, imports and past migrations. Then ask each team how they define a duplicate, find out what past cleanups and scripts did, and check record owners. Only then measure duplicates and plan the first merge, starting with the obvious ones.
How do I document an inherited CRM?
Keep one short document with the CRM's sources, each team's definition of a duplicate and past cleanups. Add ownership issues, duplicate counts per object and what depends on the records, like reports. It becomes the documentation the next owner will need too.
Should I clean up an inherited CRM right away?
Not before a short diagnosis. Some of what looks wrong was done on purpose, like separate records for branches, and many merges can't be undone. Spend the first days learning sources, definitions and owners, then start with exact matches you're certain of.
How do I find out how messy my CRM is?
Measure duplicates for each object on its own, starting with exact matches on email for contacts and domain for companies. Note which source each set came from. Also check owners, records missing the field that identifies them, and which reports leadership relies on.
Who should I talk to when I inherit a CRM?
Talk to sales, marketing and support separately, since each defines a duplicate differently. If you can, also talk to the previous admin or whoever ran past cleanups. Finance or leadership can tell you which reports they rely on before you change anything.
Or sign up with Google
Pipedrive Marketplace 
