Hi everyone,
For a Salesforce org-to-org migration, what approach do you recommend for handling metadata dependencies and data relationships?
For example, if we migrate Accounts → Contacts → Opportunities, how do you efficiently maintain the relationships when Salesforce generates new Record IDs in the target org?
Would you recommend using External IDs, Data Loader, Salesforce CLI, or another approach?
I’d be interested in hearing how others handle this in real-world migrations, especially for large data volumes.
#Case Migration #Lightning Migrations #Migration To SalesforceDX #Salesforce Admin
Hi @Rohit .
Great question. For an org-to-org migration, I would approach it in three layers: metadata dependencies, data dependencies, and relationship mapping.
1. Identify dependencies first
Before moving data, I would create a dependency matrix for objects, fields, Record Types, Profiles/Permission Sets, Flows, Apex, and other metadata. Metadata should be deployed to the target org first so that the required schema and automation are available before loading data.
2. Use External IDs for data relationships
I would add a dedicated External ID (Text) field to the required objects and populate it with the source-org record ID or another stable business key. For example:
Account.External_ID__c → Contact.Account_External_ID__c
This avoids relying on Salesforce Record IDs because the target org generates completely new IDs.
3. Load data in dependency order
Typically, I would follow:
Account → Contact → Opportunity → Opportunity Product → other dependent records
While loading child records, the relationship should be resolved using the parent's External ID rather than the old Salesforce ID.
4. Choose the migration tool based on volume and complexity
For smaller or controlled migrations, Data Loader is often sufficient. For large-volume migrations, I would consider Bulk API 2.0 or a migration utility such as SFDX Data Move Utility (SFDMU). The important part is not just the tool, but having a repeatable and restartable migration process.
5. Handle circular/self-referencing relationships separately
For relationships such as Account hierarchies or other circular dependencies, I would use a two-step approach: load the records first, then update the relationship fields after the required parent records exist in the target org.
6. Validate after migration
I would reconcile source vs. target record counts, validate key relationships, check failed records, and run business-level validation before considering the migration complete.
So, in my experience, the safest approach is External IDs + dependency-based sequencing + appropriate migration tooling + post-migration reconciliation, rather than relying on a manually maintained Salesforce ID mapping sheet.
This approach is especially useful when dealing with large data volumes and repeatable migration runs.
Hope This Helps!!