After an acquisition, merge two Salesforce orgs only when the combined company will sell to the same customers, share a pipeline or run the same service process. If the businesses will stay operationally separate, keep both orgs and connect the data leadership needs. When you do consolidate, pick one surviving org, reconcile the data model before moving any records, rebuild security and automation in the target, and move one business unit or process at a time.
Keep separate or consolidate: decide on operating model, not org size
The instinct after a deal closes is to get everyone onto one system quickly. That is right when the two companies will share accounts, cross-sell, route cases through one team or report pipeline as one number. It is wrong when the acquired business keeps its own brand, sales team and processes, because a forced merge spends months reconciling differences nobody needs reconciled.
Salesforce's own architecture guidance frames this as a question of how much the businesses share processes and data. Companies that standardize and integrate heavily belong in as few orgs as possible; companies that run similar but independent operations can live with several orgs, provided someone governs how they connect. Answer these questions with the integration leaders, not only the IT team:
- Will the same customer be sold to, or supported by, people from both companies?
- Does leadership need one pipeline, one forecast or one service backlog?
- Will the sales processes, stages and approval rules converge, or stay different on purpose?
- Are there contractual, regulatory or divestiture reasons to keep data apart?
- Which org has the cleaner data model, the better-documented automation and the longer contract term?
| Option | When it fits | Main trade-off |
|---|---|---|
| Keep both orgs, report centrally | Separate brands and teams; leadership only needs combined numbers | Two sets of licenses, admins and release cycles to maintain |
| Keep both orgs, share selected data | Some shared accounts or referrals, but different processes | Cross-org data access and sync must be designed and governed |
| Consolidate into the acquirer's org | Acquirer's org is healthier and its processes will become the standard | Acquired team changes tools and habits at the same time as its employer |
| Consolidate into the acquired org | Acquired org is better built or already fits the target process | Politically harder; the acquirer's users move instead |
| Build a fresh org for both | Both orgs carry heavy technical debt | Longest timeline; everything is rebuilt and retested |
If you keep both orgs, Salesforce offers ways to link them without a full merge. The Salesforce Connect cross-org adapter lets users in one org see records from another as external objects, read through the REST API at the time they are viewed. Data Cloud One lets a single Data 360 home org share unified profiles with companion orgs. Either can carry you through a transition, or become the permanent answer.
Reconcile the data model before you move records
Consolidation is a migration project with a twist: the target org already has live data and users. Start by laying the two schemas side by side, object by object. Expect the same concept to be modeled differently, such as one company using opportunity products and the other a custom object for line items, or one tracking industry in a picklist and the other in free text.
For each object, record which fields map directly, which need a transformation, which should be retired and which must be added to the target. Pay close attention to picklist values, record types, currencies and stage names, because reports and automation depend on them. Then decide how to handle customers that exist in both orgs. Shared accounts are common after an acquisition, and loading both copies creates duplicates that damage trust in the combined org from its first day. Agree on matching criteria and a surviving-record rule before any load, and keep each source system's record ID in an external ID field so you can trace and reload records.
Users, licenses and security
Incoming users need a role in the target hierarchy, a profile, permission sets and a place in the sharing model. The target org's sharing rules were written for one company. If the acquired sales team should not see the acquirer's accounts yet, or should see only shared customers, design that visibility explicitly rather than inheriting whatever the defaults allow.
- Map every incoming user to a role, profile and permission set group before cutover.
- Check that record ownership after migration matches an active user in the target org.
- Review organization-wide defaults and sharing rules for objects the new team will use.
- Confirm single sign-on, multi-factor authentication and login policies for the new users.
- Count licenses by type in both contracts and plan which to retire, and when.
Automation conflicts
Automation causes more surprises in a consolidation than data does. The target org's Flows, validation rules and Apex triggers were built for its own records, and they will fire on every record you load and every record the new users create. A validation rule that requires a field the acquired company never captured will block the load. A Flow that assigns owners by territory may reassign accounts the incoming team has worked for years.
Inventory the automation in both orgs on every object in scope, then decide per process whether the target's version, the source's version or a new design wins. Rebuild what survives in the target org as Flow, and plan to bypass automation during data loads with a custom permission or setting that your Flows and triggers check. Test with real records from the acquired org in a full-copy sandbox, not with a handful of sample rows.
Integrations and connected systems
List every system that reads from or writes to each org: ERP, marketing automation, billing, telephony, data enrichment, e-signature and anything built on the API. For each, decide whether it will point at the target org, be replaced by the acquirer's equivalent or be retired. Integration endpoints, credentials, field mappings and record IDs all change when an org does, so each connection is a small project with its own testing.
Watch API usage too. The target org's daily API allowance is shared by every integration, and adding the acquired company's connections, plus migration loads, can push it toward its limit. Review marketing consent and email preferences with care, because merging contacts can join a record that opted out with one that did not.
A phased approach
| Phase | What happens | Exit criteria |
|---|---|---|
| 1. Decide | Choose keep, connect or consolidate; pick the surviving org | Signed-off decision with an executive owner |
| 2. Connect | Give leadership combined reporting while both orgs run | One view of combined pipeline or accounts |
| 3. Design | Map objects, fields, users, sharing, automation and integrations | Approved mapping and a frozen source org |
| 4. Build and rehearse | Build in a sandbox; run full trial loads with real data | Clean rehearsal with reconciled record counts |
| 5. Move by unit | Cut over one team, region or process at a time | Users working in the target; source read-only |
| 6. Retire | Archive source data, cancel licenses, decommission integrations | Source org closed with an export retained |
Moving by business unit keeps each cutover small enough to support properly, and lessons from the first wave improve the next. Keep the source org read-only for a defined period after each wave so people can check history, then export and archive its data and files before the contract ends. Budget time for training: the incoming team is learning new page layouts, stages and reports while adjusting to a new employer.
