Running Destructive Changes Before Deploying Replacements
“Delete the old stuff AFTER the new stuff is live. Not before.”
What Happened
Client wanted to rename a custom object. I ran destructive-changes.xml to remove the old object first, planning to deploy the new one right after. But the old object had lookup relationships, validation rules, and Flows pointing to it. The destructive deploy cascaded. Fields vanished. Flows broke. Validation rules errored. It took three days and a partial data recovery to fix what should have been a 20-minute rename.
The Wrong Way
<!-- destructive-changes.xml - DON'T RUN THIS FIRST -->
<?xml version="1.0" encoding="UTF-8"?>
<Package xmlns="http://soap.sforce.com/2006/04/metadata">
<types>
<members>Legacy_Application__c</members>
<name>CustomObject</name>
</types>
<version>59.0</version>
</Package>
# Destroy first, ask questions later
sf project deploy start -d empty-dir --post-destructive-changes destructive-changes.xml -o productionThe Right Way
# Step 1: Deploy the NEW object and all references first sf project deploy start -x manifest/package-new-object.xml -o production --test-level RunLocalTests # Step 2: Migrate data from old to new sf apex run -o production -f scripts/migrate-legacy-to-new.apex # Step 3: Update all Flows, validation rules, lookups to point to new object sf project deploy start -x manifest/package-updated-refs.xml -o production # Step 4: Verify everything works for a week # Step 5: NOW destroy the old object sf project deploy start -d empty-dir \ --post-destructive-changes destructive-changes.xml \ -o production
The Lesson
Destructive changes are irreversible. Deploy replacements first, migrate data, verify everything, then delete. Never the other way around.
Enjoyed this? Get more like it.
Glen's Musings — AI, investing, and building things. Occasional. Free.
More Deployment Mistakes
Deploying to Production on Friday Afternoon
Friday deploys turn weekends into war rooms.
Read moreAnnoyingDeploying Apex Without Including the Test Class
Your deploy will fail at 75% code coverage if you forget the test class.
Read morePainfulSkipping Sandbox and Deploying Straight to Production
If you didn't test it in a sandbox, you're testing it on your users.
Read more