Merging two Salesforce orgs into one against a contract-expiry deadline

The problem

The play

1. 1
   Scan both orgs before promising anything

   Deep metadata scans on both sides ran before scoping, and they immediately contradicted the client's own description of the target org. The complexity discovered in that scan is what moved the estimate from weeks to months. A cross-org dependency map followed, then a migration blueprint.

2. 2
   Put a permanent org-of-origin flag on every migrated record

   Every record carried across gets a legacy source-ID field, and a formula boolean derived from it answers 'did this come from the old org?' on Account, Contact, Lead, Opportunity and Case.

3. 3
   Resolve username and alias collisions as a deliberate step

   Every user in the legacy org was renamed with a suffix so the original username was free to be re-created in the surviving org, which meant users log in with their normal username afterwards and nobody has to relearn anything.

4. 4
   Reconcile the object model where the picklists actually collide

   The clearest example: both orgs had an account-type value whose underlying API name was identical, and API names must be unique. One value had to be renamed, which is why downstream filters started returning nothing.

5. 5
   Find the relabelled standard fields before the customer does

   An opportunity quoted at one value in the old org displayed that same value in the new org under a field label that had nothing to do with it. The cause: the surviving org had relabelled the standard Amount field. The retiring org did not use standard Amount at all and reported off its own recurring-revenue fields.

6. 6
   Rebuild the role hierarchy from the org chart, not from either org

   Rather than reconciling two legacy role trees, the unified hierarchy was built against the actual HR org chart, which is how it came out at roughly 50 unique roles instead of the ~95 in the combined legacy spec.

7. 7
   Accept what the platform will not let you migrate, and say so

   Standard history tables on Opportunity, Account and Contact cannot be moved; the platform blocks it. The replacement was a custom object holding the historical progression as flat records, and the customer was told plainly that it is a list, not a timeline view.

What it moved

From a LeanScale case studyRead the full case study →