Salesforce to Salesforce
Merging two Salesforce orgs after an acquisition — reconciling schemas that diverged, deduplicating accounts that exist in both, and proving what landed.
- Moving from
- Salesforce
- Moving to
- Salesforce
- What you get
- A per-record account of what landed, and what did not
- Agreed up front
- 5 known exclusions, before any work starts
How we get the data out of Salesforce
Both ends are Salesforce, so the mechanics are symmetric. The difficulty is that the two organizations number their records independently, have configured them differently over years, and both hold records for some of the same real companies.
What we need from you before we start
- Accounts on both organizations — read access on the source, write access on everything being loaded into the destination
- One new field per object in the destination, holding each record’s identifier from the source organization
- A decision on whose schema wins where the two orgs have diverged — field by field, not object by object
- A list of the destination’s validation rules, duplicate rules and automation, and agreement on what is suspended while loading runs
What comes across
The defining M&A migration, and the one where the reconciliation artifact matters most, because two finance organizations will be comparing pipeline numbers against it. Independent ID spaces, diverged schemas and genuinely duplicated customers mean most of the engagement is mapping and adjudication rather than transfer.
Comes across
- Accounts, contacts, opportunities and the relationships between them
- Record ownership, mapped across the two organizations
- Custom fields, reconciled where the two setups have diverged
- Record types and their permitted values, re-resolved in the destination
- The original record identifiers from the source organization
Doesn’t come across
- The two organizations number their records independently, so every relationship between them has to be rebuilt at the destination rather than carried across as-is.
- Where both orgs sold to the same company, the account exists twice with different IDs, different field values and different histories. Deciding which record survives, and what happens to the other’s child records, is a business decision we surface rather than resolve on your behalf.
- Schemas diverge over years. Fields with the same label may hold different data, picklists accumulate different values, and one org may have automation the other does not. This mapping is the bulk of the engagement.
- Record ownership drives sharing, forecasting and territory assignment. Loading with the wrong owner is expensive to unpick, so ownership mapping is resolved and reviewed before any load.
- Master-detail relationships cannot be freely reparented after creation, so parentage has to be right the first time.
Every one of these is identified during scoping and agreed with you before the migration runs. The field-by-field detail sits in your scoping document, where it can be discussed rather than skimmed.
Questions people ask about this migration
Moving from Salesforce?
Send us a rough record count and we’ll come back with a scope, a timeline, and the exclusions we’d expect — before you commit to anything.