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

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

Option B
Org B survives
Org A moves into B

or:

Option C
Build a clean target org
Migrate both organizations

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

Org B:

Account
├── Client
├── Reseller
├── Vendor
└── Strategic Account

Both had fields such as:

Industry
Segment
Region
Status
Owner

But their meanings differed.

For example:

Org A
Enterprise = revenue classification

while:

Org B
Enterprise = sales-team classification

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"

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

We reversed that.

Target architecture
        ↓
Objects and fields
        ↓
Record types
        ↓
Security
        ↓
Automation
        ↓
Reference data
        ↓
Business records

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

and:

Org B
ACME Corp.
www.acme.com
NY

Probably the same company.

Then we might find:

Acme Holdings
Acme Europe GmbH
Acme Manufacturing

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

A rule like:

Same company name
→ Merge

would be dangerous.

We created categories:

EXACT DUPLICATE

LIKELY DUPLICATE

RELATED ENTITY

KEEP SEPARATE

MANUAL REVIEW

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...

and:

Org B Account
001BBB...

represent the same customer.

The consolidated target might create:

Target Account
001CCC...

We needed something durable like:

source_org
source_object
source_id
target_id
migration_status

For example:

ORG_A | Account | 001AAA | 001CCC
ORG_B | Account | 001BBB | 001CCC

That map wasn't useful only for Accounts.

It was required for:

Contacts
Opportunities
Cases
Orders
Activities
Custom objects
Files
External systems

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

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

rather than:

Run migration
      ↓
Insert everything again

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

Contacts are more ambiguous.

For example:

John Smith
john@acme.com

versus:

Jonathan Smith
jsmith@acme.com

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

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

and:

Company B sales team
owns Company B opportunities

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?

We sometimes preserved both:

Historical Owner

and:

Current Operational Owner

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

We did not want this result:

Org A security
+
Org B security
=
Target security

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?

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

Org B:

Opportunity Closed Won
        ↓
Create implementation project

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

Then classified each:

KEEP

MERGE

REPLACE

REDESIGN

REMOVE

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

The easy approach would have been:

Keep all four

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

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

Afterward, we wanted:

ERP ────────────┐
Marketing ──────┤
Support ────────┼──→ Target Salesforce Org
Finance ────────┤
Other Apps ─────┘

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?

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

Those references also needed translation.

Conceptually:

OLD ORG ID
     ↓
ID CROSSWALK
     ↓
TARGET ORG ID

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

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

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

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

Data

Accounts
Contacts
Leads
Opportunities
Cases
Orders
Activities
Files
Custom records

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

as the primary transformation architecture.

Instead:

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

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

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

or:

Contact maps to two possible Accounts

or:

No valid target owner

Each exception received:

Source record
Reason
Suggested resolution
Responsible owner
Status
Final resolution

Migration progress could now be measured:

1,420 exceptions
      ↓
640
      ↓
123
      ↓
8
      ↓
0 blockers

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

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?

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

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

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

A simplified cutover looked like:

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

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

For example:

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

Expected after duplicate handling: 6,011

Target: 6,011

Then:

Expected open pipeline:
$187.42M

Target:
$187.42M

And migration exceptions:

Broken relationships: 0

Missing owners: 0

Blocking duplicates: 0

Unknown statuses: 0

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

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

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

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

Cutover

[ ] Freeze window defined

[ ] Delta process tested

[ ] Automation bypass documented

[ ] Integration switch sequenced

[ ] Rollback approach defined

[ ] Final reconciliation prepared

[ ] Business sign-off obtained

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

But the final org could not remain:

Company A Salesforce
+
Company B Salesforce

forever.

Eventually, it had to become:

The new company's Salesforce

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

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.