Post-acquisition CRM consolidation merges the acquired company’s CRM, marketing automation and GTM data into one system of record. Pick the surviving platform with a decision tree (customer overlap, platform fit, org health, contract dates), then dedupe accounts and contacts, set ownership rules for shared customers, and cut over in 60–120 days.
Illustrative map, not a client
Consolidate when the sales teams, customers or reporting are merging. If the companies will keep selling separately, roll up the reporting and leave the CRMs alone for now.
| Pattern | What it means | Typical timeline | Choose it if | Trade-off |
|---|---|---|---|---|
| Keep separate, roll up reporting | Both CRMs stay. Standard definitions and a warehouse or BI layer produce combined reporting. | 4–8 weeks | Different buyers, separate sales teams, or the add-on may be sold again. | Two stacks to pay for and maintain; no shared customer view. |
| Merge into the platform’s CRM | The add-on’s data, users and processes move into the platform org or portal. | 8–14 weeks | Same platform, platform org is healthy, teams or customers overlap. | The add-on adopts the platform’s process; expect rep pushback. |
| Merge onto the better platform | The companies run different CRMs; both move to whichever fits the combined business. | 10–16 weeks | Salesforce and HubSpot on either side and one clearly fits the combined company better. | One team learns a new tool. Plan training and adoption tracking. |
| Fresh org for both | A new CRM is designed for the combined company; both datasets migrate in. | 14–24 weeks | Both orgs carry heavy technical debt, or this is the platform for many more add-ons. | Longest path; needs an interim roll-up for board reporting. |
Four questions decide most cases: will the go-to-market merge, are both on the same platform, which org is healthier, and does the combined company need Salesforce-level complexity.
Then check timing: if the retiring CRM renews within 90 days, negotiate a short-term renewal or plan an interim sync rather than rushing the cutover.
Match on stable identifiers first, fuzzy logic last. Write the survivorship rule for every field before the first test load, not after reps find duplicates.
| Object | Primary match | Secondary match | Survivorship rule | Manual review when |
|---|---|---|---|---|
| Accounts | Billing customer ID, then normalized website domain | Normalized name + country, D-U-N-S or registry number if present | Surviving record is the one with the active contract; other fields fill only where the survivor is blank | Same domain but different billing entities (subsidiaries, regions) |
| Contacts | Email address (lower-cased, trimmed) | First + last name + account domain | Most recently active record wins for title and phone; consent status takes the most restrictive value | Personal email domains, shared inboxes |
| Leads | Email address | Matches an existing contact by email | Convert to the matching contact; keep the earliest original source | Lead belongs to an open opp on the other side |
| Opportunities | Never merged automatically | Same account + product + close month | Both kept; flag possible duplicates for the owners to resolve | Always, for overlapping open opps |
| Activities & history | Migrated with parent record ID | n/a | Kept on the surviving record after merge | Email bodies with retention limits |
| Subscriptions & consent | Email address | n/a | Unsubscribed or no-consent on either side wins | Never overridden manually |
Ownership rules are a commercial decision, not a data task. Get them signed by the CRO before migration, and make the comp treatment explicit so reps don’t fight over records.
| Scenario | Rule | Comp and crediting |
|---|---|---|
| Customer of both companies | Account owner is the rep with the larger ARR on the account; the other becomes a named account team member for their product. | Each rep keeps renewal credit on their existing product for the current plan year. |
| Customer of one, prospect of the other | Existing customer owner keeps the account. Cross-sell opps are created by the other team with the owner looped in. | Cross-sell credit to the rep who sources and closes it; owner gets an overlay or SPIF if the plan allows. |
| Open opportunities on both sides | Both opps stay open. Sales leadership resolves within 10 business days; losing opp closes as “Merged”. | Decided case by case and logged on the opp. |
| Prospect worked by both | Owner is the rep with the most recent meaningful activity (meeting held or opp created) in the last 90 days. | Standard new-logo credit to the owner. |
| Named or strategic accounts | Named account lists from both companies are reconciled first and take priority over all other rules. | Per the named account plan. |
| No activity in 12 months | Returns to the unassigned pool and is routed by the combined territory rules. | None until re-engaged. |
Twelve weeks is a realistic target for merging an add-on into a healthy platform org. Different platforms or a fresh org push it to 16–24.
| Weeks | Phase | Work | Owner | Deliverable |
|---|---|---|---|---|
| 0–2 | Audit | Audit both CRMs and marketing automation: objects, fields, automation, integrations, data quality, contracts and renewal dates. Stand up interim roll-up reporting. | RevOps / pod | Dual audit and surviving-platform decision |
| 3–5 | Design | Harmonize lifecycle stages, pipeline stages, picklists and naming. Write dedupe, survivorship and ownership rules. Map every field. | RevOps + sales and marketing leaders | Field map, rules document, target process |
| 6–9 | Build and test | Configure the surviving org, rebuild or retire automation, reconnect integrations. Run two or more test loads with reconciliation. | Pod | Reconciliation report within 0.5% |
| 10–11 | Cutover | Final load, permissions and roles for the unified team, record ownership reassigned, forms and tracking switched on both websites. | Pod + RevOps | One system live for both teams |
| 12+ | Hypercare and enablement | Training, SOPs, daily triage, retire the old CRM and cancel its contract. | RevOps + enablement | Old system decommissioned; adoption tracked |
The data load is rarely what fails. What fails is everything that depended on the old system and nobody wrote down.
Two merging companies each ran Salesforce and HubSpot. JayOh audited all four environments and consolidated them into one Salesforce org and one HubSpot portal.
More stories in the case study library.
The first add-on is a project. Every one after it should be a playbook. Platforms that document the first integration cut the second one’s timeline sharply.
| Playbook component | What it contains | Why it matters at add-on #2 and #3 |
|---|---|---|
| Metric dictionary | Platform definitions for ARR, pipeline, stages, MQL/SQL, churn and NRR | Add-on reporting maps to the standard instead of being debated again |
| Field and stage map template | Target fields, picklists and stage exit criteria with mapping columns | Design phase drops from weeks to days |
| Dedupe and ownership rules | Match keys, survivorship and shared-customer rules signed once | No re-litigating ownership with every deal |
| Integration checklist | Standard list of connected systems and how each is re-pointed | Fewer silent failures at cutover |
| Day-1 roll-up reporting | A BI or warehouse view that accepts any add-on’s export | Board sees combined numbers before the CRM merge finishes |
| Enablement kit | Recorded training, SOPs and a rep FAQ for the platform CRM | Acquired reps are productive in the first week |
We engineer growth systems. JayOh builds the RevOps architecture, GTM execution and data infrastructure that turn messy revenue operations into predictable pipeline for B2B SaaS and PE-backed teams.
