Folding an Acquired Book Into Yours: Accounts, Then Contacts

You acquired a company and now you own two customer books that overlap. This guide is for the RevOps or sales-ops person answerable for how the merge was done: it carries one consolidation start to finish, with the real order of operations, the match keys that hold, the verdict you record for every overlap, and the wrong turns that mint duplicates or orphan history. Follow along on your own case and you will finish with one deduplicated book and a defensible merge, link, or keep-separate decision recorded for every account and contact.

Most published teardowns resolve a single tangled person or one corporate family in isolation. A real acquisition is two full books colliding at once, where account merges and contact re-parenting fight each other for order. That collision is the whole problem, so that is what this document works through.

The one rule that dictates everything: load in dependency order

Merge accounts first, then contacts, then open deals, then activities. Anything else creates orphans you relink by hand.

The reason is not taste. Contacts, deals, and activities all carry a pointer to an account ID. If you merge a contact while its parent account is still duplicated, the surviving account ID does not exist yet, so the pointer has nowhere valid to land. Merge a contact before its account and the record count can look perfectly right while open deals and activity history silently detach. This is a foreign-key rule wearing a process costume.

Sources agree on this order. They differ only on one thing: whether "agree definitions and map objects" is its own gate before dedup, or folded into prep. I treat it as a hard gate. If the two teams disagree on what a "customer" record means or what "active" counts as, no merge downstream can be trusted, because you are deduplicating against a definition that is not shared.

The worked case: two books, and where the counts land

Here is the case I carry through the rest of the guide. I acquired a smaller company. My book has roughly 4,200 accounts; theirs has roughly 1,800. The overlap - shared customers appearing in both systems - is where the value and the danger both concentrate.

Post-acquisition duplicate rates of 10 to 30 percent are common without an active data-quality program, and up to 40 percent with no cleanup at all. Take the conservative end. If even 12 percent of the combined 6,000 accounts are overlaps or internal duplicates, that is around 720 account records needing a verdict, before I touch a single contact.

The reason overlaps are dangerous is counterintuitive: name matching fails hardest exactly where value concentrates. My largest shared customer appears in my book as one legal name and in theirs under a different billing entity. That account is the single most important record in the merge and the one exact-name matching gets wrong. So the accounts most worth getting right are precisely the ones a naive match mishandles.

Before any dedup, I cut history scope. I hold a 24-month window of closed activity and archive anything older that exists only for compliance. Every extension of that window adds reconciliation work with no reporting benefit, and history nobody reads still has to reattach cleanly.

Match keys that hold, and where name matching lies

Tie identity to a stable ID: account ID, billing customer ID, contract ID, or tenant ID. Domain and tax ID or DUNS are strong secondary checks. Company name is never a primary key.

Name fails on subsidiaries billed under different names. One system lists "Gorman Manufacturing Corp," another "Gorman Company, Inc.," and a third "Gorman Manufacturing Company, LTD." Two unrelated companies can also share a name, so name-based matching can pull separate accounts together and skew every downstream report. A domain is a good second check. DUNS encodes corporate family trees, but each legal entity gets its own number, so a parent and a subsidiary carry distinct DUNS - useful for structure, not for proving two records are the same entity.

Here is what each key proves, and what it looks like when it lies.

Pull billing addresses and tax identification numbers alongside company names before you decide anything. That gives you a mathematical basis for merging accounts instead of relying on a sales rep's intuition about whether two names are "the same."

The verdict every overlap needs: merge, link, or keep separate

Merge only when the legal entity and the contract stay the same. Link or keep records separate for acquisitions, spin-offs, or unclear-domain cases. Delay entirely when ownership of transactions is unclear.

The merge-versus-link distinction turns on motion. Ask: are these true duplicates for how I sell, or different parts of the same organization I want to manage separately? If they are duplicates for my motion, merge. If they represent meaningful structure, associate them. The keep-separate and delay cases are where discipline pays: preserve both records, restrict further duplicate creation, and get the right accounting or tax review before changing historical data when an audit is active, a dispute is open, or a prior tax filing could be affected.

In my case, that largest shared customer under two billing names turned out to be one legal entity on one master contract. Verdict: merge. A second pairing looked identical by name but resolved to a parent and a newly spun-out subsidiary with distinct tax IDs. Verdict: link, not merge. Recording both verdicts, with the key that decided them, is what makes the merge defensible later when finance asks why two records became one.

Run it: the eight-step procedure

Run these in order. The order is the point; skipping the definition gate or reversing accounts and contacts is how the whole thing unwinds.

Two passes inside step 4 deserve detail. Pass 1 is mechanical: exact matches on identity keys - same email across contacts, same normalized domain across companies, same account plus normalized name across open deals. These are high-confidence and usually the bulk of the problem. Do not move to Pass 2 until every Pass 1 match is queued. Pass 2 is constrained fuzzy matching, run only inside a shared hard key so a fuzzy name match can never join two records that lack a common domain, billing ID, or tax ID.

For contacts in step 5, set field-level survivorship first: decide, per field, which source wins - most-recent-wins for activity dates, but authoritative-source-wins for anything tied to a contract. Never let recency auto-merge overwrite an enterprise account's contract record.

Where native tooling runs out, and who should own this

Native Salesforce dedup has hard ceilings that a post-acquisition duplicate load will trip. Know them before you plan build-versus-buy, because hitting them mid-cutover is how a plan slips.

An org can hold only 5 active duplicate rules per object and just 1 active matching rule per object (up to 5 across rules). Native merge caps at 3 records at once and cannot be automated. A matching rule refuses to activate if it flags roughly more than 2 percent of records, raisable to about 5 percent via Support but not removable. Carry a 10 to 30 percent duplicate rate into that and the platform's own guardrails block you - which is the documented reason teams reach for third-party dedup tooling.

Standard duplicate rules also do not retroactively find existing duplicates; you need Duplicate Jobs for the backlog a merge creates, and those stop accepting new jobs once completed items reach one million.

Who runs this matters as much as which tool. Migration-ready operators are scarce. In Refolk's index of professional profiles, only 114 of 1,082 US Revenue Operations Managers pair Salesforce with data-migration skill - roughly a tenth of the pool. That is why a two-book merge usually needs a named internal owner or an external specialist rather than whoever happens to run the CRM.

Where you have to find that person, describing the skill in plain English beats keyword filtering. Refolk lets you ask for exactly this profile - a RevOps operator who has run a post-acquisition consolidation - and get named people back across LinkedIn and the open web, instead of guessing from titles alone.

If your merge sits in the UK, the pool is roughly a fifth the size of the US market, which is worth knowing before you assume you can staff the role internally on short notice.

How this goes wrong: the failure modes to check for

Most merges fail on a small set of repeatable errors. Each has a false positive that looks like success and a specific check that catches it. This is the section to keep open during the work.

Two of these deserve extra weight because they masquerade as success.

The sample-versus-full fight is a survivorship-bias fight, not a matter of opinion. A pilot that moves 5 to 10 percent of records into a sandbox validates the common case, which is exactly what you want for debugging your field mapping fast. But acquisition cutovers fail on rare exceptions that a random sample structurally misses. Testing a sample gives a false sense of security. So sample to debug, then validate 100 percent against target rules before go-live, and run a full-volume test because a sample also hides scale problems.

The counts-reconcile-but-relationships-do-not failure is the quiet killer. Do not stop at row counts. After every merge, verify that ticket links, account ownership, case history, stages, and consent flags all reattached to the master record. Totals can match perfectly while the relationships underneath are wrong, and that is the version of "done" that ships broken reporting to leadership.

Before you call it done: the acceptance checklist

Before cutover, one owner holds a single go/no-go decision against this list. If any item fails, the load is not ready, regardless of how clean the row counts look.

Keeping it clean after cutover

Freeze the source, load in dependency order, re-enable integrations, then watch closely. The strongest published estimate for a clean two-company merger with moderate integration complexity is 90 days to a foundational consolidation: unified stage definitions, deduplicated data, a stable sync, and basic pipeline reporting. Do not trust the numbers before then.

Keep a monitoring window of 4 to 6 weeks post-go-live. That is when re-parenting errors and broken integration syncs surface, and catching them inside the window is far cheaper than after the book has been sold against for a quarter. Watch for new duplicate creation specifically: a merge cleans the past, but without a duplicate-prevention rule in place, the same overlap regrows.

To keep the work current, re-check three things on a cadence. First, your platform's dedup limits, since vendor thresholds and sync-matching behavior change - confirm the current ceiling rather than trusting a remembered number. Second, your duplicate rate, which tells you whether prevention is holding. Third, the standing keep-separate and delayed records: revisit any that were parked pending an audit, dispute, or tax review, because those verdicts were deferrals, not decisions, and each one still owes you a final call.