One Org or Two After the Acquisition
Northwind Components runs a single Salesforce Enterprise org: 350 users, USD only, 12 integrations pointed at its org ID, and no multi-currency. It acquires a German distributor with 60 users, 8 years of history, 400,000 accounts, EUR with dated exchange rates, and custom objects built for German warranty law. About 9,000 accounts already exist in both orgs under slightly different names. Group IT wants one org for a "single customer view" before the fiscal year closes in six months. Legal requires EU customer PII to stay hosted in the EU. The acquired team has no Salesforce administrator and 40 active reports.
1. Recommend an org strategy. Address the "single customer view" argument directly, and name the specific things that break in a merge.
Read the worked answer
The requirement is a single customer view, not a single org. Two orgs plus a shared master record (middleware/ESB, a small MDM hub, or Salesforce Connect cross-org) delivers the view at a fraction of the risk. Recommend: keep two orgs, merge later if the business case survives contact with the details.
What actually breaks in a merge:
- Multi-currency is one-way. Enabling it in the parent touches every currency field and cannot be disabled. Dated exchange rates (Advanced Currency Management) apply to opportunity amounts and opportunity products only - custom EUR currency fields on the warranty objects use the static corporate rate and will misreport.
- 9,000 overlapping accounts must be deduped before load, or you bake duplicate parents into 12 integrations that never had to reconcile them.
- History does not migrate through a standard data load: field history, approval history, and report/dashboard definitions. The 40 reports get rebuilt by hand.
- Integrations keyed on record IDs must be re-pointed and re-mapped; anything storing 15-character IDs will collide.
- Two different record type and process models must be reconciled into one - that is a business decision, not an admin task.
2. The CEO overrides you and demands one org within 12 months. Name your first three moves and the single biggest risk.
Read the worked answer
Move 1 - settle hosting in week one. A single org lives in one instance. Ask Legal whether hosting the merged org in an EU region satisfies the residency requirement, with the parent-side data included in that assessment. If the answer is no, the project is dead and you found out in week one instead of month nine.
Move 2 - data profiling and an external ID strategy before any load. Define survivorship rules per field for the 9,000 overlaps, choose the master record, and give every migrated record a durable external ID so future loads are idempotent.
Move 3 - a full rehearsal in a Full Copy sandbox with a measured cutover window, a dual-running period, and the legacy org left read-only for 90 days as the rollback plan.
Biggest risk: multi-currency. It is irreversible, it silently changes the meaning of existing amounts in every report and every integration that reads a currency field, and it surfaces in places people forget: hard-coded currency symbols in formulas, roll-up summaries over currency, and validation rules comparing amounts. Budget rework of the parent org's existing formulas and integrations, not just the acquired org's.