The 90-day reality of a merged CRM
The deal closed on a Tuesday. By Thursday, someone in finance has pasted both CRM exports into one spreadsheet, sorted by company name, and discovered that the acquired company has been selling to eleven of your top fifty accounts. Two of those accounts are in renewal this quarter. Nobody can say who owns them.
Then it gets worse. Your team logs deals in Salesforce with a seven-stage process. Theirs lives in HubSpot with four stages and a habit of marking things "Closed Won" at verbal agreement. Their "Industry" picklist has 340 values because it was a free-text field until 2022. Your CFO needs a combined forecast number for the board deck, and the board meeting does not move.
This is the part of CRM consolidation after an acquisition that nobody budgets for. The platform decision gets all the attention: which system we keep, which licenses we cancel, who runs admin. Those are real questions, but they are downstream. The thing that actually determines whether the first 90 days go well is whether you can produce one trustworthy customer list out of two partial ones.
Before you touch either platform, name the five fault lines. They show up in every consolidation, in roughly this order:
- Overlapping accounts: the same company exists in both systems under slightly different names.
- Shared customers: both companies legitimately sell to the same account, often to different buyers inside it.
- Owner conflicts: two reps, two comp plans, one logo.
- Picklist collisions: two sets of stages, industries, lead sources, and statuses that mean different things.
- Definition drift: "Closed Won" and "Qualified" do not mean the same thing in both systems, which makes any combined number fiction until you fix it.
Deciding the system of record, fast and on evidence
The system of record decision turns political within about a week, so make it in the first one. And make it per object, not per company. It is completely normal to keep Company A's CRM for accounts and opportunities while Company B's support platform stays the record for ticket history. What you cannot have is two records both claiming to be authoritative for the same object.
Pick based on data quality and process maturity, not headcount, license cost, or who got acquired. The acquired company is frequently the one with the cleaner database, because they are smaller and newer and have not accumulated a decade of field debt. Decide with evidence.
The cheapest evidence is a baseline. Run both databases through a cleaning pass and compare them on the same scale. CleanSmart's Clarity Score weights four dimensions, Completeness, Consistency, Uniqueness, and Validity, along with contact verification results, into a single number per dataset. It recalculates after each cleaning run, and a run takes a few minutes, so you can have a side-by-side comparison of both CRMs the same afternoon you ask for it.
Write the decision down in one page: which system holds which object, which fields survive from the other side, what the cutover date is, and who signs off. Circulate it. Half the chaos in a merged CRM comes from people operating on different assumptions about a decision they think was never made.
Reconciling overlapping accounts and shared customers
Here's the mess you are actually walking into. Your database has "Northwind Logistics". Theirs has "Northwind Logistics, LLC", "Northwind Logistics Inc", and a stray "NW Logistics (Midwest)". One has the domain northwind.com, one has a rep's personal note in the website field, and one has no domain at all. Name matching alone will not get you there, and name matching plus human review will take three weeks you do not have.
Match on signal strength instead. Domain is the strongest single identifier, then billing address plus normalized company name, then contact email overlap, then phone. SmartMatch works through those signals across both imports and groups the candidates, so your team reviews clusters and makes calls instead of scrolling two sorted lists side by side.
Shared customers need a different decision than duplicates. If both companies genuinely sold to the same organization, you do not have a data error. You have a parent account with two relationships underneath it. Decide early whether you are rolling those into one account record with multiple contracts, or keeping child records by division. Finance usually wants the roll-up. Reps usually want the division detail. You can have both if you set the hierarchy before the load, and neither if you decide after.
Set survivorship rules before anyone starts merging, and apply them the same way every time:
- Most recently verified contact data wins over most recently edited.
- The system of record wins on name, domain, and hierarchy.
- The system with the active contract wins on billing address, terms, and renewal date.
- Never delete the losing record's values. Keep them in a change log so you can reverse a bad merge.
- Anything with a live opportunity or an open renewal goes to human review, no matter how confident the match is.
Owner conflicts and territory reassignment
Two reps will claim the same logo. One of them sold a $40k deal there eighteen months ago. The other has a meeting scheduled for next week. Both have it in their number. If you resolve this quietly inside the data, you will find out at the end of the quarter, from a compensation dispute.
Use a tiebreak order and publish it. The sequence that holds up in practice: the rep with the active contract or open renewal, then the rep with meaningful activity in the last 90 days (a meeting, not an auto-logged email), then the rep whose territory the account's headquarters falls in. Equal claims go to a named person for a decision, not to a committee.
Protect the history while you reassign. Keep the incoming record's original owner in a Legacy Owner field rather than overwriting it. Comp retros, quota relief, and commission claw-backs all depend on knowing who owned what on the day the deal closed, and that information is worth almost nothing once it is overwritten.
Then reassign in one batch on one date. Rolling reassignment over six weeks produces a CRM where nobody trusts the owner field, which produces reps working accounts off private spreadsheets, which is how you lose the consolidation entirely. One date, one announcement, one escalation path for disputes that stays open for two weeks.
Merging incompatible picklists and stage definitions
Picklists are where consolidation projects quietly go to die. You have "Technology". They have "SaaS", "Software", "Software/Technology", and "Tech". You have seven deal stages. They have four, and their Stage 3 covers roughly your Stage 4 through 6. Their Lead Source has 212 values, most of them typed by hand at a trade show.
Build the mapping table first, on paper, before any records move. One row per source value, one column for the target value, one column for who approved it. Dump every distinct value with its record count so you can see that 90% of those 212 lead sources cover eleven real ones and the rest are noise. AutoFormat handles the mechanical part, standardizing casing, spacing, legal suffixes, country codes, phone formats, and the dozen variations of the same picklist value, so your team spends its time on the judgment calls.
Stages deserve their own session, and it should be about exit criteria, not names. "Qualified" is meaningless. "Budget confirmed, decision date identified, and we have met someone with signing authority" is testable. Agree on the criteria, then map each incoming deal to the stage its evidence supports, not the stage its old label matched. Expect a meaningful number of acquired deals to move backwards. That is the project working, not failing.
One technical warning: stage entry timestamps rarely survive a consolidation intact. If your velocity and conversion reporting depends on days-in-stage, capture the historical values as static fields on the way in. You cannot reconstruct them later.
Producing a combined forecast number you can defend
The board wants one number. The temptation is to add the two forecast totals and send the deck. Do not. Added totals double count every deal that exists in both systems, which in a merger of two companies serving adjacent markets is not a rounding error. It is routinely five to fifteen percent of open value.
Build the number in this order. Deduplicate accounts and opportunities first. Normalize stages against the new exit criteria second. Normalize currency and amount fields third. Apply one probability model fourth. Any other order produces a number that changes every time someone recalculates it, which is the worst possible outcome in front of a board.
Then screen for the obvious nonsense before the number leaves the building. LogicGuard flags the anomalies that survive every consolidation: close dates in the past, amounts of zero on late-stage deals, a single opportunity sitting at 400x the median value, renewals that appear twice under two account records, deals owned by someone who left during the transition. These are a handful of records with outsized effect, and the five minutes it takes to flag them is the difference between a confident answer and a correction email on Monday.
Present it as a reconciliation bridge, not a total. Company A open value, plus Company B open value, minus duplicate opportunities, minus deals reclassified to earlier stages, plus or minus currency normalization, equals combined forecast. Four lines. Every line defensible. When a board member asks why the combined number is lower than the sum of the parts, you have the answer on the slide instead of in your head.
The 90-day sequence
Timing matters more than thoroughness here. You are not trying to reach a perfect database. You are trying to reach a trustworthy one before comp plans, renewals, and board reporting force decisions for you.
Here is the sequence that works, assuming day one is the close date:
- Days 1 to 15: Pull a read-only extract from both CRMs. Baseline both with a cleaning run and compare Clarity Scores. Decide the system of record per object and publish the one-page decision. Freeze new custom fields in both systems.
- Days 16 to 30: Run account and contact matching across both datasets. Review the clusters. Resolve overlapping accounts, set parent and child hierarchy for shared customers, and lock survivorship rules. Produce a first duplicate count for finance so they know the size of the double counting problem.
- Days 31 to 45: Build the picklist mapping table and agree stage exit criteria in one working session with sales leadership from both sides. Standardize formats. Fill the gaps you can fill from existing records and verified sources rather than asking reps to retype them.
- Days 46 to 60: Resolve owner conflicts with the published tiebreak order. Reassign in one batch on one announced date. Keep Legacy Owner intact. Open a two-week dispute window with a named decision maker.
- Days 61 to 75: Load the reconciled records into the system of record. Run the anomaly screen. Build the reconciliation bridge and walk finance through each line before the deck exists.
- Days 76 to 90: Run a second cleaning pass to catch what the consolidation itself introduced, decommission the retiring system in read-only mode rather than deleting it, and write the governance rules that keep the merged database from drifting apart again: required fields, picklist ownership, and who can create an account.
Reconcile both databases before you move them
The single most expensive mistake in a post-merger consolidation is loading dirty data into the surviving system and cleaning it there. Once both datasets are in one place, you lose the ability to tell which record came from where, your audit trail is gone, and every duplicate you create is now a duplicate inside your system of record, where it will quietly contaminate reporting, routing, and comp for years.
Clean them separately, reconcile them against each other, then move one consolidated dataset in once. That is the whole trick, and it is why the sequence above puts matching at day 16 and loading at day 61.
CleanSmart is built for exactly this shape of work. DataBridge connects to Salesforce, HubSpot, Mailchimp, Klaviyo, and Shopify and reads records out of each one, so you can pull both sides into a single workspace without touching the source systems. SmartMatch groups the overlapping accounts. SmartFill closes the gaps. AutoFormat standardizes the picklist chaos. LogicGuard flags the records that would have embarrassed you in the board meeting. You review the proposed changes, then export the reconciled dataset as CSV or JSON with a full change log, and you import it into the surviving CRM on your own schedule, with your own approvals. Nothing moves into a connected platform without you doing it deliberately.
You already know the week this has to happen. Try the self-serve product demo, run both extracts through it, and see the duplicate count for yourself before the forecast number is due.
Frequently Asked Questions
Should we keep the acquirer's CRM by default?
No. Choose per object, based on data quality and process maturity rather than org chart, and the acquired company's database is often the cleaner one. Baseline both with a cleaning run, compare the Clarity Scores, and document the decision in one page before anyone starts moving records.
How do we avoid double counting deals in the combined forecast?
Deduplicate accounts and opportunities before you total anything, since the same customer frequently appears in both systems under different names. Then normalize stages against shared exit criteria and present the result as a reconciliation bridge so every adjustment between the sum of the parts and the combined number is visible.
What happens to historical data in the CRM we retire?
Keep it in read-only mode rather than deleting it, and carry forward the fields you cannot rebuild later, especially original owner and stage entry dates. Export a change log alongside the consolidated dataset so any merge decision can be traced and reversed if a dispute comes up at quarter end.