How multinationals end up with many orgs
Few companies choose to run five Salesforce orgs. They inherit them: an acquisition here, a regional team that spun up its own instance there, a country that needed something live before IT could standardise. Each one made sense at the time. Together they mean five reports, five definitions of an account, and no single view of the customer.
The real work is reconciling versions of the truth
Moving records between orgs is the easy part of a migration. The hard part is that the same customer exists in three orgs with three different IDs, the data models diverged years ago, and each region named things its own way. Consolidation is mostly reconciliation: matching duplicates across orgs, mapping mismatched fields and record types, and agreeing one model everyone can live with.
Compliance and residency cannot be an afterthought
When the regions include the EU, consolidation is also a data-protection exercise. Where the unified org is hosted, how personal data moves during the merge, and what a sandbox refresh copies all matter. We plan data residency and lawful basis into the migration from the start, not after go-live.
The playbook we run
Our sequence is consistent: map every source org, reconcile the model and the duplicates, stage the migration with full relationship preservation using iSyncSF, validate record counts and lookups, then cut over with a rollback ready the whole way. Local nuance survives: currencies, languages, record types, and the workflows a region genuinely needs stay intact.
Key takeaways
- Consolidation is reconciliation, not just data movement: one model, deduped across orgs.
- Plan data residency and lawful basis in from the start when the EU is involved.
- Map, reconcile, stage, validate, cut over with rollback, and keep local nuance intact.