Merging Acquired Salesforce Orgs: 7 Gotchas

Every acquisition sponsor eventually asks the same question: “Can we just import their contacts and opportunities into our Salesforce next weekend?”

The honest answer is no, and the reason isn’t record count. Two production Salesforce orgs that have each been in service for five years carry hundreds of custom fields, dozens of RecordTypes, live automations that fire on write, third-party AppExchange packages talking to external systems on both sides, and — most damaging — two different definitions of what a qualified opportunity actually is. Merge them naively and the CFO’s first consolidated pipeline report will misstate the number by a quarter or more, in either direction. We’ve seen it lie by 40%.

This post is the seven ways that merge silently breaks, in the order the pain arrives after cutover. It’s built from the postmortems on the M&A data integration engagements we’ve run through consolidations across financial services, industrial services, and B2B SaaS. Each gotcha ends with the fix we now build in from day one.

1. Record IDs aren’t the merge key. External IDs are — and both orgs rarely have them.

The instinct is to key on the 18-character Salesforce Record ID. That doesn’t work because those IDs are org-local — the same customer exists at 0011200001ABc in your org and at 0013e00002xYz in theirs, and the strings tell you nothing about whether they’re the same company.

What you actually need is a stable external identifier on both sides — a DUNS number, a corporate domain, a tax ID, a canonical registry ID — that lets you deterministically match records before deduping. Almost no CRM shop has consistently populated these across their entire history. They have them for enterprise accounts and nothing for the mid-market long tail.

The fix is to run identity resolution before you touch the target org: a matching pass that combines exact keys where present, fuzzy on company name plus normalized domain plus address, and a manual review queue for anything below a confidence threshold. It’s not glamorous work but it decides whether the merged pipeline report is trustworthy for the next three years. This is where the master data management foundation the S.C.A.L.E. pattern deploys does its heaviest lifting in an M&A context — the identity layer gets installed before any downstream consolidation touches the CRM. Do the identity pass first, or do the whole merge twice.

2. “Same field name, different meaning” — semantic drift in shared fields

Both orgs have an Account field called Segment. In yours the picklist values are SMB / Mid-Market / Enterprise / Strategic. In theirs they’re Tier 1 / Tier 2 / Tier 3 / Tier 4. The field names match; the meanings don’t.

The trap is that a mapping script that copies Segment → Segment runs without error and lands garbage. A tier-2 account (mid-market equivalent) shows up in the merged org tagged Tier 2 — which doesn’t map to any of your reps’ territory rules — so it sits unowned for a quarter until someone notices revenue leaking.

Every shared field name needs a semantic reconciliation pass: value-by-value alignment before schema-level mapping. Do this on Segment, Industry, Region, Lead Source, Product, Status, and every custom picklist that carries meaning downstream. It’s slow. It’s also the difference between a merge that produces one book of business and a merge that produces two books wearing the same name.

3. RecordType, page layout, and validation rule collisions

Both orgs use Account — but yours has three RecordTypes (Customer, Prospect, Partner) and theirs has five (Direct, Reseller, Distributor, Government, Nonprofit). Neither set is wrong; they encode legitimate business distinctions. In the merged org, every account has to end up on exactly one RecordType, and every RecordType has its own page layout, its own required fields, and its own validation rules.

Two failure modes surface here:

• Required-field mismatch. Your Customer RecordType requires Contract Number. Their Reseller RecordType doesn’t. When you map their resellers into your Customer RecordType (because there’s no Reseller in yours), the bulk load fails on the required field — silently, one batch at a time, so you don’t notice until day two of the cutover window.
• Validation-rule collision. Your Prospect RecordType blocks writing to Contract Value unless Stage = Closed Won. Their process wrote to that field during discovery. Their historical records fail validation on import.

The fix is a target-side RecordType design that’s deliberately the superset of both orgs, with validation rules relaxed to what the loosest source enforced during the write period. Tighten them after the historical load lands. Not before.

4. Opportunity stages don’t line up — pipeline reports lie for a quarter

This is the one that gets escalated to the CFO fastest, and it’s structural, not technical. Your Opportunity.StageName picklist is Discovery / Qualified / Proposal / Negotiation / Closed Won / Closed Lost — six stages. Theirs is a ten-stage MEDDIC-derived model. The forecast categories underneath these stages (Pipeline, Best Case, Commit) are set on a per-stage basis and each org has calibrated them differently. “Stage 4” in your world is 40% weighted; in theirs it’s 60%.

Naively concatenate the two pipelines and every forecast roll-up is wrong. The bookings number the CEO shows the board on the first post-close quarterly call is a fiction — sometimes 40% off in either direction, depending on which side has healthier discipline about updating stage.

The only fix is to define a single unified stage model before cutover, decide the forecast weighting rules on that model, and then remap both source pipelines into it — with a diff report showing every opportunity whose weighted value changed by more than 10%. Sales leadership reviews that diff before any pipeline report goes to finance. Skip this step and you own the CFO’s first-quarter surprise.

5. Automation collisions: Flow, Apex, and Process Builder firing on the same records

Both orgs have automations layered over their objects — some declarative (Flow, Process Builder, the last of the Workflow Rules), some code (Apex triggers, batch classes). When a record from the acquired company lands in the target org, your automation fires. Your assignment-rule reassigns the owner. Your lead-conversion Flow creates a new Account when one already exists. Your Apex trigger stamps CreatedDate = today and destroys the historical age of the opportunity.

Most damaging: dueling triggers that write to the same field with different logic. One trigger writes AccountOwner based on ZIP code; another writes it based on Segment. On a merged account both fire, one wins, and the ownership assignments across the merged book are non-deterministic depending on load order.

The fix is a quiet-mode load — a bulk-load context that suppresses non-essential triggers and Flows during the historical import (Salesforce supports this through custom settings or context flags in your Apex classes), then a controlled second pass that runs the automations you do want (owner assignment, sharing calculation) after the data has landed. Not doing this is how “we imported yesterday” turns into “we’re spending Thursday sorting out why 400 opportunities got reassigned overnight.”

6. The integration inventory nobody has — outbound webhooks that shouldn’t fire on the load

Every mature Salesforce org has grown a web of integrations that fire on record events: an outbound message to the ERP when a Closed Won opportunity is created, a webhook to the marketing automation platform when a Lead is created, an AppExchange package that syncs contacts to a support system, a middleware job that pulls quotes into the accounting ledger. Half of these were built by an admin who left two years ago and are documented in nobody’s runbook.

Merge day is when you find out they exist. A bulk import fires 40,000 outbound messages and blows the rate limit on your ERP. A Marketo webhook creates 40,000 duplicate contacts. The accounting system takes a stray batch of 8,000 quotes into its production ledger and finance spends a week backing them out.

Before touching the target org, you need an integration inventory — every outbound integration, every AppExchange package with a trigger, every scheduled Apex, every workflow-rule-based outbound message. For each: what does it fire on, where does it go, what happens if it fires 40,000 times in a batch. You disable, throttle, or route-to-null the ones that shouldn’t run during the load, then re-enable them in a controlled sequence. The disabled/re-enabled decision matrix is the deliverable, not a checklist item.

7. Permission set, profile, and license explosion

You inherit their profile matrix. They had 47 profiles because eleven years of “just clone that profile and change one thing” produced eleven years of debt. You had 22 profiles. The merged org, if you’re not deliberate, will end up with 69 profiles, of which about 45 are near-duplicates that differ only in the visibility of two fields.

The knock-on effect is licensing. Salesforce license counts are enforced at the user-license level, and every profile is bound to one. Merging without a rationalization pass usually adds 15–30% to the license bill in year one — some real (people you now genuinely support), most artificial (two nearly-identical user personas now hold two nearly-identical licenses).

The fix is a profile consolidation pass as its own workstream, running in parallel with data migration — target a permission-set-driven model where profiles are minimal and everything variable is a permission set. Salesforce has been pushing this direction for years and the reason becomes obvious the first time you merge two orgs. Done well, this is usually the single biggest recoverable cost in the first year post-close.

How to actually run this

Three sequencing principles that keep the seven gotchas from surprising you.

Identity resolution runs before anything else. No mapping, no schema decisions, no automation review until you have a verified cross-org identity map. If you don’t have external IDs, spend the time building one. Every downstream decision depends on it being trustworthy.

Sandbox validation is non-negotiable, and it needs to be a full-copy sandbox with real automation enabled — not a partial sandbox with triggers muted. Every gotcha above will surface in a full-copy sandbox load if you look for it; none of them will surface in a partial with muted automation, which is exactly why teams keep getting surprised on cutover.

Cutover is a controlled sequence, not a weekend. Historical load with automations suppressed. Ownership assignment pass. Integration re-enable in dependency order. Reporting cutover. First-week reconciliation window with a named diff-review owner. The number-one predictor of a clean cutover is how boring the cutover runbook is.

The 180-day post-acquisition playbook we run puts the CRM merge in Phase 3 — deliberately, because getting the first two phases right (Day-1 consolidated reporting off both live systems, then identity resolution) is what makes the CRM merge itself boring. If you’re heading into a CRM consolidation and the sponsor is asking for a weekend cutover, we should probably talk before you commit to that date. Our data integration practice has a running library of these postmortems, and it rarely ends at seven.