Merging multiple Salesforce orgs
Cohash consolidates multiple Salesforce orgs into one. We compare objects, record types, automation, packages and integrations across orgs, agree one data model and sharing design, map users and SSO, and migrate data with external IDs so relationships survive. Business units move in waves. A source org goes read-only, and gets archived, only once its users and integrations work in the target.
- 01Org comparison
- 02Target design
- 03Users and access
- 04Data migration
- 05Integrations and automation
- 06Waves and archive
The story
Told without the client's name or anything that could identify them.
A distribution company that had grown by acquisition ended up with several Salesforce orgs, each with its own admins, packages and integrations, and the same customers held as different accounts. Leadership couldn't get one pipeline report without exporting from each org. We compared metadata across the orgs first, chose the surviving org and agreed one data model and sharing design. Users moved to a single SSO setup, duplicate accounts were matched and merged with a data steward approving each one, and business units moved in waves until every source org was read-only and archived.
why it was urgentMost consolidations start with an acquisition or with years of regional builds. Two newer changes add pressure. Salesforce ended support for Workflow Rules and Process Builder on 31 December 2025, so the old automation in every org needs rebuilding anyway. And Winter '27 turns Agentforce on by default, which would mean setting up agents and permissions separately in each org.
- openLeadership can't get one pipeline report without exporting from several orgs.
- recurringThe same customer exists as different accounts in different orgs.
- blockedEach org has its own admins, release process and managed package licences.
- openIntegrations to ERP and marketing are built twice, once per org.
The estate, before and after
Before: several Salesforce orgs with duplicated plumbing
Each org had its own logins, automation and copies of the ERP and marketing integrations. Pipeline reporting meant exporting from every org and merging spreadsheets.
Read the diagram as text
- Sales teams → Salesforce org A: login
- Sales teams → Acquired org B: login
- Sales teams → Regional org: login
- Salesforce org A → ERP: integration A
- Acquired org B → ERP: integration B
- Regional org → Marketing platform: sync
- Salesforce org A → Pipeline reporting: export
- Acquired org B → Pipeline reporting: export
- Regional org → Pipeline reporting: export
After: one Salesforce org behind one SSO
One SSO setup, one org, one data model, with sharing set per business unit. MuleSoft runs each integration once, and nobody exports anything to build a report.
Read the diagram as text
- All sales teams → Okta SSO: sign in
- Okta SSO → Consolidated Salesforce org: SAML assertion
- Consolidated Salesforce org → Record-triggered flows: on save
- Consolidated Salesforce org → Pipeline dashboards: native reports
- Consolidated Salesforce org → MuleSoft: platform events
- MuleSoft → ERP: orders and accounts
- MuleSoft → Marketing platform: contacts
How we run it, phase by phase.
6 phases take you from Several Salesforce orgs to One consolidated Salesforce org. Each one ends with something you can check before the next starts. As you scroll, the blocks show the estate moving across.
- phase 01
Org comparison
Pull metadata from every org and compare objects, fields, record types, automation, Apex, packages, licences and integrations. Flag where names, picklists and sharing rules clash.
- phase 02
Target design
Pick the surviving org, design the shared data model and record types, and agree a sharing model that keeps business units apart where they need it.
- phase 03
Users and access
Map users to a single SSO setup in Okta or Entra ID and turn profiles into permission set groups. Set federation IDs early, so nobody's login changes between waves.
- phase 04
Data migration
Match and merge the duplicate accounts and contacts first. Then load records with external IDs so parent and child links hold, and bring owners and key dates across.
- phase 05
Integrations and automation
Repoint ERP, marketing and support integrations to the target org, and rebuild old Workflow Rules and Process Builder logic as flows once instead of per org.
- phase 06
Waves and archive
Move one business unit at a time, set the source org read-only, export what the target org can't hold, and retire licences after the last wave.
What the client got
What changed for the client once the work was done. Described, not scored: we don't publish client figures.
- result 01
One pipeline report from one org
Nobody stitches exports together for the pipeline report now. Sales data for every business unit sits in the surviving org.
- result 02
Each customer exists once
We merged duplicate accounts and contacts before the load, and external IDs on every record kept parent and child links together.
- result 03
People keep one login across waves
One SSO setup, federation IDs for everyone, and permission set groups where the old profiles used to be.
- result 04
Integrations and automation are built once
ERP, marketing and support integrations point at the surviving org, and old Workflow Rules and Process Builder logic was rebuilt once as flows.
- result 05
Retired orgs can't be written to
Every source org was locked to read-only after its wave, with integration users, agents and connected apps switched off. We retired the licences after the final wave.
Risks we plan for
-
New record IDs break links
Migrated records come out with new Salesforce IDs. Integrations, reports, email links and external systems holding old IDs break unless they get a lookup or an update.
-
Sharing conflicts
What works for one business unit's sharing can leak data to the next one. Real users from each unit test it before any data loads.
-
History doesn't come across natively
You can't load field history or audit trails as native history. So decide early which parts land in custom objects and which in an archive.
-
Package and contract overlap
Duplicate packages and org-bound licences need decisions before the first wave. Some of those decisions end up as vendor negotiations.
Where AI helps, and where it needs guardrails
Agentforce grounds its answers in org data, so duplicate accounts and clashing picklists make agents worse after a merge. We use LLM-assisted matching to suggest which accounts and contacts are the same, and a data steward approves every merge. In the retired orgs, agents and integration users are switched off with their connected apps, so no forgotten agent keeps writing to an org nobody watches.
forward deployed engineers →What you're left with
We write these for your setup, and they're working documents. Your team should be able to keep things running from them long after we've gone.
- report01
Org comparison report with conflicts per object and package
yours to keep - design02
Target data model and sharing design
yours to keep - inventory03
User, profile and permission set group mapping
yours to keep - code04
Data migration scripts with external IDs and reconciliation reports
yours to keep - runbook05
Wave plan with cut-over and rollback steps
yours to keep - plan06
Source org archive and licence retirement plan
yours to keep
Platforms and services on this move
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Onsite
Engineers at your sites in the US
Nearshore
Overlapping hours with US teams
Offshore
Overnight progress on your backlog
All time zones
Coverage handed over across time zones
01Should we merge orgs at all?
Sometimes it isn't worth it. Units that share few customers and processes get design conflicts and little else from a single org, and a shared warehouse can handle reporting. Where customers, products or sales teams overlap, merging pays off.
02Which org should survive?
Usually the one with the cleaner data model and more users, but licences, packages, data residency and the org's edition also matter. We score each candidate before anyone commits.
03What drives the cost?
How many orgs, how far apart their data models are, record volumes, duplicates, integrations and how many waves the business wants.
Often on the same roadmap
On-premises Active Directory to cloud-first Microsoft Entra ID
We shrink on-premises Active Directory one application at a time, moving groups, users and app authentication to Microsoft Entra ID as each app is ready.
read the case studyAD FS federation to Entra ID authentication
Converting federated domains from AD FS to Entra ID cloud authentication, moving relying parties app by app and retiring the AD FS farm.
read the case study
Apache Airflow 2 to Airflow 3
Upgrading self-managed Apache Airflow 2, now past end of life, to Airflow 3, and fixing removed features, auth and scheduling changes before DAGs move.
read the case study8e20dd60 - 01Salesforce Help: Workflow Rules and Process Builder end of supporthelp.salesforce.com ↗
- 02Salesforce: Winter '27 product release announcementsalesforce.com ↗
- 03Salesforce Ben: Agentforce auto-enabled in Winter '27salesforceben.com ↗
Planning this move?
A 30-minute working session with a senior engineer. No slides.
- The platform and the version you're on
- Where you need to get to, and by when
- What's custom: rules, plugins, integrations
- Any audit finding or deadline driving it