Salesforce Org Consolidation: The Complete M&A Merger Playbook (2026)

Two orgs. One company. A deadline from the CFO. Salesforce org consolidation after a merger is one of the most complex technical projects an enterprise can undertake — and one of the most underestimated. The clock is already ticking on duplicate licensing costs, the data quality is decaying in both orgs simultaneously, and every week of delay is another week of divergence your migration team will have to reconcile. This is the playbook that gets it done.

The first decision — consolidate fully or federate?

Not every multi-org situation calls for a full consolidation. Before scoping work, choose the operating model:

• Full consolidation — one org, one data model, one truth. All users, records, automations, and integrations migrate to a single target org. The acquired company's org is decommissioned. Highest complexity, highest long-term value.
• Hub-and-spoke federation — a master org holds shared data (Accounts, Contacts, Products), while business-unit child orgs retain autonomy for their pipelines and service operations. Connected via Salesforce Connect or event-driven integration. Moderate complexity, preserves business unit independence.
• Loose integration — separate orgs remain separate but share data via API-level integration (MuleSoft, Zapier, custom middleware). Lowest migration effort, highest ongoing maintenance cost, and the most common "temporary solution" that becomes permanent.

Full consolidation is the right call when: both companies operate in the same market and share customers, the integration surface between orgs is high, and licensing cost reduction is a primary post-merger objective. It is NOT the right call when both companies are in fundamentally different industries with incompatible data models, or when one org's customization debt is so severe that a greenfield rebuild is faster than a migration.

Phase 1 — The org audit

Before moving a single record, you need a complete inventory of both orgs. Teams that skip this phase discover hidden complexity in production — at the worst possible time. The audit covers:

• Users and licenses — total user count, license types (Sales Cloud, Service Cloud, Community, Partner), active vs. deactivated users (see our guide on Salesforce user deprovisioning for how to handle departed employees from the acquired org), and named users on integration accounts
• Custom objects and fields — count and document every custom object, custom field, and custom relationship. Note which fields are required, have validation rules, or are referenced by Apex code. Data model divergence is the #1 driver of migration cost overruns
• Third-party integrations — enumerate every connected app, named credential, and external system. Include authentication method, integration owner, data direction, and volume
• Automation inventory — every active Flow, Process Builder, Workflow Rule, and Apex trigger in both orgs. Duplicates are common; this is also your first opportunity to retire technical debt rather than migrate it
• Custom code — Apex classes, triggers, Lightning Web Components, Visualforce pages. Code requires assessment, not just migration; what worked in one org's governor limit context may not work in another
• Storage and file volume — pull record counts for every major object and file storage totals (ContentDocument, ContentVersion, legacy Attachment records). File migration is the single longest-running phase and must be scoped separately. QuickBild's Salesforce file migration guide covers ContentDocument migration in detail

Skipping this phase is the #1 reason consolidation projects exceed budget. A proper org audit takes 2–4 weeks for a mid-sized org. That time is repaid within the first month of actual migration work.

Phase 2 — User, profile, and permission mapping

The user migration question is deceptively complex. Same email address across both orgs usually means the same person — but not always. Contractors, shared service accounts, and integration users require individual review.

The profile consolidation strategy matters more than most teams realize. Never copy profiles wholesale from the source org to the target. Profiles accumulate years of incremental permissions — granted, forgotten, never reviewed. The org consolidation is the natural forcing function to rebuild permissions from scratch using permission sets and permission set groups, following the principle of least privilege. The result is a cleaner permission model than either org started with.

License rationalization often surfaces significant cost savings. When both orgs are inventoried together, it is common to find that 15–25% of licenses can be downgraded or eliminated before consolidation completes — users with Sales Cloud Unlimited who only need Sales Cloud Standard, integration users with full Salesforce licenses that should be on API-only licenses, and deactivated users from the acquired company who are still consuming licenses.

The role hierarchy merge requires explicit design. Two separate hierarchies cannot be naively merged — you need an org design session to determine the combined reporting structure before any user migration begins. Deactivated users from the source org should not be migrated without review. Under GDPR, former employees' personal data requires careful handling; review your obligations before importing records.

Phase 3 — Data migration strategy

Migrate in dependency order, not in order of business importance. Starting with the objects that feel most urgent — open Opportunities, active Cases — creates orphaned records because their parent Accounts and Contacts haven't been migrated yet. The correct sequence:

1. Reference data: picklist values, record types, custom metadata, custom settings
2. Parent objects: Account, Contact, Lead (these are the anchors everything else references)
3. Child objects: Opportunity, Case, custom objects that reference Accounts or Contacts
4. Junction and related records: OpportunityContactRole, CaseTeamMember, custom junction objects
5. Files and attachments: ContentDocument / ContentVersion (this is a parallel workstream — run it alongside record migration, not after)

Field mapping is the technical core of the migration. When schemas diverge — a custom field exists in the source but not the target, or two fields serve the same purpose with different names — every discrepancy needs an explicit mapping decision: transform, skip, or create a new field. Undocumented divergences cause silent data loss.

Migration complexity	Object types	Primary challenge
Straightforward	Standard objects with clean data, matched schemas	Volume and validation rules
Moderate	Custom objects, child records, lookup references	ID remapping across orgs
Complex	Files/attachments, Chatter, history fields	Volume, special APIs, metadata loss

History fields — CreatedDate, LastModifiedDate, CreatedBy — cannot be migrated to match originals. Salesforce sets them at the time of record creation in the target org. Preserve the original values in custom fields if historical accuracy matters for reporting or compliance.

Phase 4 — Integration re-pointing and decommission

Every integration that pointed at the source org must be updated to point at the target org before decommission. This is not just a URL change — connected app credentials, OAuth tokens, IP allowlists, and named credentials all require updates in both Salesforce and the downstream system.

Common integration types to address: middleware platforms (MuleSoft, Workato, Boomi, Zapier), ERP connections (SAP, NetSuite, Oracle), marketing automation (Pardot, Marketo, HubSpot), and customer-facing web portals using the API. Each must be tested in the target org before the source org is decommissioned.

Plan for a 90-day parallel run period before decommissioning the source org. During this period, the source org remains accessible read-only for reference. Users who accidentally save data to the source org (old bookmarks, cached app credentials) can be identified and corrected before the decommission date. Going cold turkey — decommissioning immediately at cutover — creates significant support burden and is the most common cause of data scatter post-merger.

Post-merge validation — the go-no-go checklist

Before declaring go-live, run a structured validation pass:

• Data integrity — record counts in the target org match the source (or exceed it for delta migrations). Run a SOQL count across every migrated object
• User login verification — sample 10% of users across each profile type and confirm they can log in, see their records, and execute their primary workflow
• Automation smoke tests — create test records that trigger each critical Flow and confirm the expected outcome. Pay particular attention to Flows that send emails or update financial fields
• Integration endpoint tests — confirm each re-pointed integration is sending and receiving data correctly in the target org. Run one full transaction through each integration before go-live
• Report and dashboard verification — key executive reports should return comparable figures. Significant discrepancies indicate field mapping gaps or missing records
• 30-day hypercare window — staff an admin war room for 30 days post-cutover. Issues will surface in the first two weeks that testing didn't catch; fast response prevents them from becoming incidents

The 4 mistakes that kill consolidation projects

After running consolidation projects across financial services, healthcare, and manufacturing enterprises, the same four failure patterns appear:

1. Skipping the audit and discovering hidden integrations in production. An undocumented MuleSoft connection to a critical ERP, discovered the morning of cutover, has delayed more go-lives than any technical migration challenge. Every integration must be documented before a migration line is written.
2. Copying profiles instead of rebuilding with permission sets. Copying a bloated profile from the source org into the target org imports years of permission creep. Use the merger as an opportunity to rebuild clean. Your future admins will thank you.
3. Migrating files last — or not at all. ContentDocument migration is volume-intensive, requires special API handling, and takes substantially longer per record than standard object migration. Scoping it as "Phase 2 after go-live" is how it never gets done. File migration must run in parallel with record migration from day one. For a detailed guide on this phase, see Salesforce file migration with ContentDocument.
4. No parallel run period before decommissioning the source org. The parallel run exists to catch the integrations you missed, the users who have old bookmarks, and the batch jobs that are still pointing at the old org. It is not optional risk mitigation — it is the safety net that makes go-live survivable.