Read the screenplay: FANNIEGATE — $7 trillion. 17 years. The biggest fraud in American capital markets.
#33🚀 DeploymentCareer-Ending

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 production

The 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.

Don't make this mistake.

Hire someone who already did.

View Consulting →

Enjoyed this? Get more like it.

Glen's Musings — AI, investing, and building things. Occasional. Free.

More Deployment Mistakes