Skip to content

Migration guide · Salesforce Modernization

Salesforce Org Consolidation (M&A) migration

Two or more Salesforce orgsOne consolidated Salesforce org

Short answer

Salesforce org consolidation merges data, users and configuration from two or more Salesforce orgs into one, usually after a merger, acquisition or reorganization. It gives the combined firm one client view, one set of processes and one reporting model.

Why firms make this move

After an acquisition, running separate orgs doubles license, admin and integration costs and makes combined reporting hard. Consolidation requires deciding which org's design wins, how to merge overlapping clients, and how to keep regulated data separated where it must be.

What moves

  • Accounts, households and contacts, deduplicated across orgs
  • Opportunities, cases and activity history
  • Custom objects and configuration from the source org
  • Users, roles and sharing
  • Integrations re-pointed to the target org

See the field-by-field map ↓

What to watch out for

  • Overlapping clients and conflicting data
  • Different data models for the same concepts
  • Information barriers between business units
  • Integrations and reports in both orgs

How Vantage Point runs the migration

  1. Assess both orgs and choose the target design
  2. Plan deduplication and survivorship rules
  3. Map and transform data
  4. Migrate configuration and automation
  5. Test loads and UAT
  6. Cutover by business unit
  7. Hypercare

Typical timeline

Typically 10 to 20 weeks, depending on org complexity.

Frequently asked questions

Should we merge orgs or keep them separate?

Merge when teams share clients, processes and reporting. Keep separate when regulatory or business separation requires it, and connect the orgs instead.

How are duplicate clients handled?

With matching rules and survivorship policies agreed with the business, so the best data from each org is kept.

Last reviewed October 2, 2026 by the Vantage Point team. Browse all migration paths →

Field-level map

Salesforce Org Consolidation (M&A): field by field

8 mappings we start from on this migration, 7 of which need a transform, a lookup or a decision. Every project gets its own signed-off version; this is the baseline.

FromToHowNotes
Any recordSource org Id Any recordLegacy_Org_Id__c + Source_Org__c req direct Composite external ID keeps every record traceable to its org.
AccountDuplicates across orgs AccountSurviving record req manual review Agree match rules and a survivorship rule for each field.
UserUsers UserUser req lookup Map users by email; inactive owners go to a holding user.
Record typeRecord types Record typeMerged set picklist map
PicklistValues PicklistUnion or mapped values picklist map
ProfilePermissions Permission sets / groups— rebuild
AutomationFlows, triggers, rules FlowRationalized set rebuild Duplicate automation is the most common cause of post-merge bugs.
Report / dashboardReports ReportsRebuilt on merged model rebuild

Field names are the platforms' standard API names; your org's custom fields are mapped during discovery. What the "How" labels mean

How labels
direct
Value copies across unchanged.
picklist map
Each source value is mapped to a target value.
lookup
Matched to an existing record, such as a user by email.
association
Becomes a relationship between records, loaded in a later pass.
derive
Calculated or cleaned during the load.
split / concat
One field becomes several, or several become one.
rebuild
Configuration or automation that is rebuilt rather than moved.
drop
Not migrated, deliberately.
manual review
Needs a decision with your team before the load.