DEV Community

Samcorp
Samcorp

Posted on

Merging Two Salesforce Orgs After an Acquisition

#salesforce

Merging Two Salesforce Orgs After an Acquisition
The acquisition was complete.

The Salesforce architecture wasn't.

Company A had its own Accounts, Opportunities, automation, integrations, security model, and years of customer history.

Company B had the same categories of data—but modeled differently.

The business request sounded straightforward:

"Can we put everyone into one Salesforce org?"

Technically, yes.

But a Salesforce org merge isn't really a one-click merge. It is an org-consolidation program involving:

Data
Metadata
Identity
Security
Automation
Integrations
Users
Reporting
Historical records
Cutover
Enter fullscreen mode Exit fullscreen mode

The difficult part wasn't simply moving records.

It was deciding what the new combined company should look like inside Salesforce.

1. First, Decide Which Org Should Survive

Before thinking about Data Loader or migration scripts, we had to make the architectural decision:

Option A
Org A survives
Org B moves into A
Enter fullscreen mode Exit fullscreen mode 
Option B
Org B survives
Org A moves into B
Enter fullscreen mode Exit fullscreen mode

or:

Option C
Build a clean target org
Migrate both organizations
Enter fullscreen mode Exit fullscreen mode

The older org isn't automatically the correct destination.

Neither is the org with more users.

We compared:

  • Data quality
  • Technical debt
  • Custom objects
  • Automation complexity
  • Security architecture
  • Integrations
  • Managed packages
  • Reporting
  • Release processes
  • Future business requirements

The target Salesforce environment should represent the future operating model, not simply preserve whichever company had the larger CRM before the acquisition.

2. Same Salesforce Object Didn't Mean Same Business Model

Both organizations had Accounts.

That sounded promising until we compared how they were actually used.

Org A:

Account
├── Customer
├── Prospect
├── Distributor
└── Partner
Enter fullscreen mode Exit fullscreen mode

Org B:

Account
├── Client
├── Reseller
├── Vendor
└── Strategic Account
Enter fullscreen mode Exit fullscreen mode

Both had fields such as:

Industry
Segment
Region
Status
Owner
Enter fullscreen mode Exit fullscreen mode

But their meanings differed.

For example:

Org A
Enterprise = revenue classification
Enter fullscreen mode Exit fullscreen mode

while:

Org B
Enterprise = sales-team classification
Enter fullscreen mode Exit fullscreen mode

Copying those values directly would produce technically valid Salesforce records with incorrect business meaning.

So we created explicit transformations:

SOURCE ORG B
Client_Type__c = "Strategic"

          ↓

TARGET
Customer_Tier__c = "Strategic"
Account_Type__c = "Customer"
Enter fullscreen mode Exit fullscreen mode

That became one of our core migration principles:

Map business meaning before mapping Salesforce fields.

3. We Designed the Target Before Loading Data

A common temptation is:

Export source data
      ↓
Import data
      ↓
Fix Salesforce afterward
Enter fullscreen mode Exit fullscreen mode

We reversed that.

Target architecture
        ↓
Objects and fields
        ↓
Record types
        ↓
Security
        ↓
Automation
        ↓
Reference data
        ↓
Business records
Enter fullscreen mode Exit fullscreen mode

For a project of this size, structured Salesforce migration and modernization is broader than moving CSV files. It includes profiling source data, defining field and lookup mappings, removing duplicates, using external IDs, testing loads in sandbox environments, reconciling owners and record counts, and planning the final freeze and rollback strategy.

That preparation dramatically reduced the number of "we'll fix it after import" problems.

4. Duplicate Accounts Became a Business Problem

Acquisitions naturally create overlapping customer bases.

We might have:

Org A
Acme Corporation
acme.com
New York
Enter fullscreen mode Exit fullscreen mode

and:

Org B
ACME Corp.
www.acme.com
NY
Enter fullscreen mode Exit fullscreen mode

Probably the same company.

Then we might find:

Acme Holdings
Acme Europe GmbH
Acme Manufacturing
Enter fullscreen mode Exit fullscreen mode

Those may belong to one corporate hierarchy without being duplicate records.

A rule like:

Same company name
→ Merge
Enter fullscreen mode Exit fullscreen mode

would be dangerous.

We created categories:

EXACT DUPLICATE

LIKELY DUPLICATE

RELATED ENTITY

KEEP SEPARATE

MANUAL REVIEW
Enter fullscreen mode Exit fullscreen mode

The goal wasn't to maximize the number of merged Accounts.

It was to build the correct customer hierarchy.

5. We Built a Cross-Org Identity Map

This became one of the most important technical pieces.

Suppose:

Org A Account
001AAA...
Enter fullscreen mode Exit fullscreen mode

and:

Org B Account
001BBB...
Enter fullscreen mode Exit fullscreen mode

represent the same customer.

The consolidated target might create:

Target Account
001CCC...
Enter fullscreen mode Exit fullscreen mode

We needed something durable like:

source_org
source_object
source_id
target_id
migration_status
Enter fullscreen mode Exit fullscreen mode

For example:

ORG_A | Account | 001AAA | 001CCC
ORG_B | Account | 001BBB | 001CCC
Enter fullscreen mode Exit fullscreen mode

That map wasn't useful only for Accounts.

It was required for:

Contacts
Opportunities
Cases
Orders
Activities
Custom objects
Files
External systems
Enter fullscreen mode Exit fullscreen mode

The old Salesforce IDs were part of the source history.

The target IDs became the new operational identity.

6. External IDs Made Test Runs Repeatable

A serious Salesforce consolidation rarely has one migration run.

You perform:

Migration Test 1
      ↓
Fix mappings
      ↓
Migration Test 2
      ↓
Fix duplicates
      ↓
Migration Test 3
      ↓
Validate cutover
Enter fullscreen mode Exit fullscreen mode

Without stable identity, every run risks creating duplicate records.

We used a deliberate external-ID strategy so the migration could behave more like:

Source identity found?
      ↓
YES → update/map
NO  → create
Enter fullscreen mode Exit fullscreen mode

rather than:

Run migration
      ↓
Insert everything again
Enter fullscreen mode Exit fullscreen mode

Repeatability made testing much safer.

7. Contact Matching Was Harder Than Account Matching

Accounts often have stronger matching signals:

Website
Company name
Address
Phone
External customer ID
Enter fullscreen mode Exit fullscreen mode

Contacts are more ambiguous.

For example:

John Smith
john@acme.com
Enter fullscreen mode Exit fullscreen mode

versus:

Jonathan Smith
jsmith@acme.com
Enter fullscreen mode Exit fullscreen mode

Maybe the same person.

Maybe not.

So we avoided relying on one convenient identifier.

Matching considered combinations such as:

Name
Email
Company
Phone
Address
Source-system identifier
Enter fullscreen mode Exit fullscreen mode

Low-confidence matches went into review.

The worst thing we could do was silently merge two real people because the names happened to look similar.

8. Ownership Had to Reflect the New Company

Before the acquisition:

Company A sales team
owns Company A opportunities
Enter fullscreen mode Exit fullscreen mode

and:

Company B sales team
owns Company B opportunities
Enter fullscreen mode Exit fullscreen mode

After consolidation, the business needed answers to:

Who owns shared customers?

Who owns open opportunities?

What if both companies sold to the same Account?

Should historical ownership remain visible?

Which manager owns the combined pipeline?
Enter fullscreen mode Exit fullscreen mode

We sometimes preserved both:

Historical Owner
Enter fullscreen mode Exit fullscreen mode

and:

Current Operational Owner
Enter fullscreen mode Exit fullscreen mode

That kept reporting context without forcing the new organization to operate according to the old ownership model.

9. Security Could Not Simply Be Combined

The two orgs also had different:

Roles
Profiles
Permission Sets
Queues
Public Groups
Sharing Rules
Enter fullscreen mode Exit fullscreen mode

We did not want this result:

Org A security
+
Org B security
=
Target security
Enter fullscreen mode Exit fullscreen mode

The acquisition created a new organizational structure.

So the security architecture needed to reflect questions such as:

Can both sales teams see all Accounts?

Can Service see both companies' Cases?

Does Finance need company-wide access?

Are certain records restricted?

What access do integration users require?
Enter fullscreen mode Exit fullscreen mode

Security was redesigned around the target company.

Not copied from both legacy environments.

10. Automation Collisions Appeared Quickly

Both organizations had valid business automation.

For example:

Org A:

Opportunity Closed Won
        ↓
Create onboarding tasks
Enter fullscreen mode Exit fullscreen mode

Org B:

Opportunity Closed Won
        ↓
Create implementation project
Enter fullscreen mode Exit fullscreen mode

Should the target do both?

Maybe.

Or maybe those were two implementations of the same underlying process.

We inventoried:

Flows
Apex Triggers
Validation Rules
Approval Processes
Scheduled Apex
Scheduled Flows
Email Alerts
Platform Events
Legacy automation
Enter fullscreen mode Exit fullscreen mode

Then classified each:

KEEP

MERGE

REPLACE

REDESIGN

REMOVE
Enter fullscreen mode Exit fullscreen mode

Two functioning Salesforce orgs do not automatically become one functioning org when their automation is combined.

11. Custom Fields Were an Opportunity to Reduce Debt

Both orgs had fields such as:

Customer_Status__c
Client_Status__c
Relationship_Status__c
Account_Status__c
Enter fullscreen mode Exit fullscreen mode

The easy approach would have been:

Keep all four
Enter fullscreen mode Exit fullscreen mode

That would make the migration faster.

It would also leave the target org carrying both companies' technical debt.

Instead, every overlapping field needed a decision:

Keep target field

Map source field

Transform source values

Archive historic value

Retire duplicate field
Enter fullscreen mode Exit fullscreen mode

The migration took more planning.

The resulting Salesforce org became much easier to understand.

12. Integrations Became a Major Cutover Track

Before consolidation, the architecture might look like:

ERP A ─────────→ Org A

ERP B ─────────→ Org B

Marketing ─────→ Both

Support ───────→ Org B

Finance ───────→ Org A
Enter fullscreen mode Exit fullscreen mode

Afterward, we wanted:

ERP ────────────┐
Marketing ──────┤
Support ────────┼──→ Target Salesforce Org
Finance ────────┤
Other Apps ─────┘
Enter fullscreen mode Exit fullscreen mode

This is where Salesforce integration services become directly relevant to an org consolidation: ERP, marketing, finance, support, data platforms, and middleware all need to understand the new Salesforce system of record, new record identifiers, authentication model, API endpoints, and integration ownership.

For every integration we asked:

Which Salesforce org is authoritative now?

Which Salesforce ID should the external system store?

Are old org URLs hard-coded?

Do Connected Apps change?

Which integration user should own access?

Do middleware mappings reference legacy IDs?
Enter fullscreen mode Exit fullscreen mode

The Salesforce migration was not finished simply because users could log into the target org.

The surrounding technology stack had to move too.

13. Old Salesforce IDs Existed Outside Salesforce

This surprised more people than it should have.

Salesforce IDs appeared in:

ERP mappings

Data warehouse

Middleware

Data lake

Support platform

Custom applications

Analytics exports

Spreadsheets
Enter fullscreen mode Exit fullscreen mode

Those references also needed translation.

Conceptually:

OLD ORG ID
     ↓
ID CROSSWALK
     ↓
TARGET ORG ID
Enter fullscreen mode Exit fullscreen mode

Without that step, the Salesforce database could be correct while external systems still referenced records in an org scheduled for retirement.

14. Historical Data Needed Scope

Users naturally asked:

"Can we migrate everything?"

But "everything" included:

Tasks

Events

Cases

Emails

Files

Attachments

Notes

Chatter

Opportunity history

Field history

Custom audit records
Enter fullscreen mode Exit fullscreen mode

Not every historical record had the same value.

We classified history as:

Operationally required

Compliance required

Useful for daily users

Archive only

Not worth migrating
Enter fullscreen mode Exit fullscreen mode

This kept the active Salesforce org cleaner while still preserving information the company actually needed.

15. Migration Order Followed Relationships

Relationships controlled the sequence.

For example:

Users / Reference Data
        ↓
Accounts
        ↓
Contacts
        ↓
Opportunities
        ↓
Cases
        ↓
Orders
        ↓
Activities
        ↓
Child Custom Objects
Enter fullscreen mode Exit fullscreen mode

Why?

Because a Contact cannot reliably reference a new target Account until that Account exists.

The actual dependency graph was more complicated, but the principle remained:

Migration order follows the data model, not the order of files in an export folder.

16. We Separated Metadata and Data Workstreams

Thinking about everything as one migration was too messy.

So we separated two tracks.

Metadata 

Objects
Fields
Record Types
Flows
Apex
Validation Rules
LWCs
Permission Sets
Layouts
Reports
Integration configuration
Enter fullscreen mode Exit fullscreen mode

Data 

Accounts
Contacts
Leads
Opportunities
Cases
Orders
Activities
Files
Custom records
Enter fullscreen mode Exit fullscreen mode

The two tracks met during integrated testing.

That made failures easier to classify.

A record rejected because a picklist value doesn't exist is different from a problem in the source dataset.

17. A Staging Layer Made the Migration Safer

We avoided:

Source Org
    ↓
Target Org
Enter fullscreen mode Exit fullscreen mode

as the primary transformation architecture.

Instead:

Org A Export ─┐
              │
              ├──→ Staging
              │       ↓
Org B Export ─┘    Normalize
                      ↓
                    Match
                      ↓
                  Transform
                      ↓
                   Validate
                      ↓
                 Target Org
Enter fullscreen mode Exit fullscreen mode

The staging layer allowed us to detect issues before Salesforce imports started.

For example:

Duplicate account candidates

Missing owner mappings

Unknown picklist values

Invalid relationships

Unmapped record types

Conflicting external IDs
Enter fullscreen mode Exit fullscreen mode

This turned migration errors into something measurable and reviewable.

18. We Maintained an Exception Queue

Not every ambiguous record should stop the entire project.

But every ambiguous record should be visible.

An exception might be:

Potential duplicate Account
Enter fullscreen mode Exit fullscreen mode

or:

Contact maps to two possible Accounts
Enter fullscreen mode Exit fullscreen mode

or:

No valid target owner
Enter fullscreen mode Exit fullscreen mode

Each exception received:

Source record
Reason
Suggested resolution
Responsible owner
Status
Final resolution
Enter fullscreen mode Exit fullscreen mode

Migration progress could now be measured:

1,420 exceptions
      ↓
640
      ↓
123
      ↓
8
      ↓
0 blockers
Enter fullscreen mode Exit fullscreen mode

That's much more meaningful than saying:

"Data cleanup is almost finished."

19. Test Migrations Exposed Problems Faster Than Meetings

We could discuss migration rules for weeks.

A realistic migration test usually exposed the real gaps much faster.

Our representative test set included:

Duplicate Accounts
Complex Contact relationships
Open Opportunities
Closed Opportunities
Cases
Files
Custom objects
Multiple owners
Integration-linked records
Enter fullscreen mode Exit fullscreen mode

Then we tested:

Did relationships survive?

Were duplicates handled correctly?

Did unexpected automation fire?

Were owners correct?

Did security work?

Did reports reconcile?

Did integrations still work?
Enter fullscreen mode Exit fullscreen mode

Every test run refined the migration design.

20. Automation During Data Loads Needed Explicit Control

Bulk migration can trigger:

Flows
Triggers
Validation Rules
Duplicate Rules
Emails
External integrations
Enter fullscreen mode Exit fullscreen mode

Imagine importing historic records and accidentally triggering customer notifications.

So every significant automation needed a migration-state decision:

Remain active

Bypass during migration

Temporarily deactivate

Replace with migration-specific behavior
Enter fullscreen mode Exit fullscreen mode

And just as importantly:

How does it return to normal after cutover?

Migration bypass logic should have an expiration plan.

21. Cutover Required a Data Freeze

Eventually, source systems had to stop changing.

Otherwise:

Monday
Export data

Tuesday
Source user updates Account

Wednesday
Migrate Monday's data

Result
Target is already stale
Enter fullscreen mode Exit fullscreen mode

A simplified cutover looked like:

Full migration rehearsal
        ↓
Pre-load production data
        ↓
Source freeze
        ↓
Extract final delta
        ↓
Apply delta
        ↓
Reconcile
        ↓
Switch integrations
        ↓
Release users
Enter fullscreen mode Exit fullscreen mode

The exact downtime depends on the architecture.

But there must be a clearly defined moment when the target Salesforce org becomes the system of record.

22. Reconciliation Needed Business Metrics

A Data Loader success screen isn't enough.

We reconciled:

Accounts
Contacts
Open Opportunities
Pipeline value
Open Cases
Orders
Files
Activities
Custom objects
Enter fullscreen mode Exit fullscreen mode

For example:

Source A open opportunities: 4,203
Source B open opportunities: 1,814

Expected after duplicate handling: 6,011

Target: 6,011
Enter fullscreen mode Exit fullscreen mode

Then:

Expected open pipeline:
$187.42M

Target:
$187.42M
Enter fullscreen mode Exit fullscreen mode

And migration exceptions:

Broken relationships: 0

Missing owners: 0

Blocking duplicates: 0

Unknown statuses: 0
Enter fullscreen mode Exit fullscreen mode

That's the point where we could say the migration was actually correct.

The Architecture That Worked Better

Our final Salesforce org merge was really a controlled consolidation pipeline:

             Source Org A
                  │
                  ▼
               Extract
                  │
                  ▼
Source Org B → Staging
                  │
                  ▼
              Normalize
                  │
                  ▼
              Deduplicate
                  │
                  ▼
              Transform
                  │
                  ▼
               Validate
                  │
                  ▼
              Target Org
                  │
                  ▼
              Reconcile
Enter fullscreen mode Exit fullscreen mode

That gave us checkpoints.

And checkpoints made the migration testable.

Practical Salesforce Org Merge Checklist

Architecture 

[ ] Target org selected intentionally

[ ] Future operating model agreed

[ ] Metadata differences documented

[ ] Security architecture designed

[ ] Automation conflicts resolved

[ ] Integration ownership decided
Enter fullscreen mode Exit fullscreen mode

Data 

[ ] Source objects inventoried

[ ] Field mappings approved

[ ] Value transformations approved

[ ] Duplicate strategy agreed

[ ] External IDs defined

[ ] Source-to-target ID crosswalk designed

[ ] User/owner mappings complete

[ ] Historical-data scope approved
Enter fullscreen mode Exit fullscreen mode

Testing 

[ ] Representative migration completed

[ ] Relationships validated

[ ] Duplicate outcomes reviewed

[ ] Role-based security tested

[ ] Automation regression-tested

[ ] Integrations validated

[ ] Reports and dashboards checked

[ ] Business totals reconciled
Enter fullscreen mode Exit fullscreen mode

Cutover 

[ ] Freeze window defined

[ ] Delta process tested

[ ] Automation bypass documented

[ ] Integration switch sequenced

[ ] Rollback approach defined

[ ] Final reconciliation prepared

[ ] Business sign-off obtained
Enter fullscreen mode Exit fullscreen mode

The Biggest Lesson

The hardest part of merging two Salesforce orgs after an acquisition wasn't moving Salesforce records.

It was deciding which business reality should survive.

Both companies had valid:

Customer definitions
Sales processes
Security models
Automation
Integrations
Reporting
Historical data
Enter fullscreen mode Exit fullscreen mode

But the final org could not remain:

Company A Salesforce
+
Company B Salesforce
Enter fullscreen mode Exit fullscreen mode

forever.

Eventually, it had to become:

The new company's Salesforce
Enter fullscreen mode Exit fullscreen mode

That's why a successful Salesforce org merge is fundamentally an architecture, data, and operating-model project.

The migration should preserve the information the business needs.

But it should also:

Remove duplicates
Clarify ownership
Simplify automation
Unify integrations
Reduce redundant metadata
Create one trusted CRM
Enter fullscreen mode Exit fullscreen mode

If you simply move every field, Flow, Apex trigger, Account, Contact, report, and integration from one org into another, you may successfully retire one Salesforce instance.

You haven't necessarily consolidated the business.

The best outcome is a target org that feels intentionally designed for the company that exists after the acquisition.

Top comments (0)