Okay, so I’m deep in the weeds of a Salesforce-to-Salesforce migration for a client, and I’ve hit a wall that’s making me question my entire understanding of how metadata moves between orgs. We’re not just moving standard objects—we’ve got a whole ecosystem of custom objects with some pretty intricate relationships (master-details, lookups, even some junction objects for many-to-many).
The data migration itself? Planned like a military operation. We scripted everything with the Salesforce CLI and used a robust CI/CD pipeline (GitLab CI, in our case) to manage the deployment of all metadata—profiles, permission sets, the whole shebang. The deployments were green across the board! 🟢
But when we flipped the switch and started testing in the new org, things got weird. Specifically, a bunch of our custom object relationships seemed to… lose their references? Or point to the wrong thing? For example:
* A custom `Support_Ticket__c` object with a master-detail to a custom `Account_Extension__c` object. In the new org, the relationship field was there, but some records acted like the relationship was broken—triggers that relied on rolling up summaries failed silently.
* A lookup from a custom `Project__c` to a standard `Case` object that just… didn’t respect the same field-level security. The field was visible in layouts where it shouldn't be.
Here’s a sanitized snippet of the kind of metadata we were moving for one of the problem child objects:
```xml
Primary_Account_Extension__c
MasterDetail
Account_Extension__c
Support_Tickets
false
```
The deployment succeeded! No errors. But the *behavior* in the new org was off. It’s like the underlying relationship ID or the order of deployment created a subtle mismatch.
My theory is that this isn’t a data problem, but a metadata dependency graph problem. The deployment API says it handles dependencies, but did it *really* deploy the `Account_Extension__c` object *before* the `Support_Ticket__c` object that references it? Our pipeline ran a single `sf project deploy start`, but maybe we needed to break it into stages?
Has anyone else fought this dragon? I’m curious about:
* Did you solve it by manually re-creating relationships in the new org? (Please say no, that sounds awful.)
* Did you use a different toolchain (ANT Migration Tool, Salesforce DX with a specific order in your `sfdx-project.json`)?
* Is there a hidden "relationship integrity" check or a post-deployment script you had to run?
* More broadly, what’s your CI/CD strategy for ensuring *functional* parity, not just deployment success, when migrating complex Salesforce metadata?
I feel like my pipeline gave me a false sense of security. All green checkmarks, but the relationships were brittle. What am I missing in my deployment orchestration?
pipeline all the things
That green deployment status can be so misleading, can't it? It feels like a stamp of approval, but the metadata is only half the story. The references in master-detail and lookup fields are pointers, and if the data load doesn't perfectly respect the deployment order of those objects, you end up with orphaned records.
I've seen this exact thing happen when the junction object in a many-to-many gets deployed after the two objects it connects. The relationship field exists, but the underlying `__r` references in the data are null or mismatched. Are you using a change set or package.xml that could have scrambled the dependency order?
You're spot on about the deployment order being critical. That "green" status really is just checking if the metadata *can* deploy, not if it will work logically when data hits it.
I ran into a similar headache with a complex approval process object that referenced a half dozen custom objects. The deployment succeeded, but the first data load failed because the lookup fields were trying to point to parent records in objects that hadn't been created yet in the new org.
Are you validating with a post-deployment data script? I started adding a simple Python check to the pipeline that verifies relationships are intact before we even attempt the full data migration.
Dashboards or it didn't happen.
That's a classic and deeply frustrating scenario. The green deployment status creates a false sense of security because it only validates metadata syntax, not the integrity of the relationships once data is in play.
Your point about triggers failing silently on the master-detail roll-ups is a huge red flag. It often points to the child records being created before the parent records in the new org, or a mismatch in the underlying foreign key IDs during your data load. The relationship field is present, but it's referencing a phantom parent.
Have you audited the deployment order in your package.xml against the actual dependency tree? Sometimes the CLI will deploy objects alphabetically unless you explicitly structure it, which can break master-detail dependencies.
Read the guidelines before posting
Your reliance on the CLI's green status is understandable, but it's fundamentally a deployment-phase check, not a runtime integrity check. The broken roll-up triggers are a textbook symptom of a deployment order issue where child metadata references are validated syntactically, but the actual parent records or the underlying relationship IDs aren't populated in the correct sequence during your data load.
You mention using GitLab CI; did you explicitly define a dependency graph for your metadata components in the pipeline, or are you deploying everything in a single bulk operation? The CLI will often deploy objects based on the order in your `package.xml`, which can be alphabetical unless you manually structure it to respect parent-child dependencies. A master-detail field on `Support_Ticket__c` requires `Account_Extension__c` to exist first, not just as metadata but with its records created before the child records reference them.
Consider splitting your pipeline into stages: first deploy all standalone custom objects, then deploy relationship fields in a subsequent deployment where you can enforce order. For the data migration, you need to script your data loads to respect this same dependency tree. A post-deployment validation script is non-negotiable here - it should query a sample of records and assert that the `__r` relationships are non-null.
infrastructure is code