← Back to blog

2026-06-08 · 9 min read

Why Change Sets Fail — and a Safer Way to Migrate

The real reasons change sets are painful: no dependencies, no rollback, slow validation. What to use instead.

Change Sets are Salesforce's built-in tool for moving customizations between orgs. They're also one of the most frustrating things a Salesforce admin does regularly. A deployment fails silently in validation. You have no idea why. You can't roll back. You have to recreate the outbound changeset. Days pass.

Here's why.

The Change Set Pain Points

No Dependency Detection

Change Sets don't understand dependencies. If Custom Object A has a lookup to Custom Object B, you can accidentally include A without B in your changeset — and validation will fail with a cryptic error halfway through. You have to manually track dependencies yourself, which is fine for five items and hell for fifty.

No Rollback

Once a Change Set deploys, it's done. If something breaks in production, you can't undo it with a button. You have to create a new changeset that reverses the changes, deploy that, and hope it fixes it. And hope nothing else is broken.

Painfully Slow Validation

Change Set validation is serial, synchronous, and gives you minimal feedback. You deploy, wait for the validation to churn, and get back an error that doesn't always point to the real problem. If validation fails, you edit the changeset, re-deploy, and wait again.

No Diff or Preview

You don't see what's actually going to change until validation runs. There's no way to see "this field is being modified, that custom object is being created." You're flying blind.

Can't Move Data

Change Sets move metadata only. If you're migrating a new org and need to copy master data (users, profiles, permission sets, accounts, products, price books), you have to use Data Loader or a separate process. It's a context switch.

Must Recreate Outbound Change Sets

If you deploy a changeset from Org A to Org B, then deploy the same components from Org A to Org C, you have to recreate the outbound changeset. There's no "reuse last deployment" button. You click through the UI again.

Easy to Miss Components

In large deployments, it's easy to forget that Custom Field X references Custom Object Y, or that a Validation Rule depends on a Formula Field. Change Sets don't enforce this discipline.

The Alternatives

Salesforce CLI and Source Format

The modern way to migrate metadata is via the Salesforce CLI (sf or sfdx), working with source code in Git. You pull metadata from an org into a repo, commit it, and push to another org.

It's powerful. It supports a wider range of metadata types than Change Sets. It has rollback (git revert). It gives you visibility into what's changing.

The learning curve is steep if you're not comfortable with Git and the command line. It requires a DevHub and scratch orgs to do full CI/CD. For a one-off deployment, it feels like overkill.

Unlocked Packages

Unlocked packages are a way to bundle and version metadata. You build a package in a dev org, upload it to a package org, and install it in other orgs. Installation is one-click.

Again, the setup is complex. You need a dedicated package org. You need to manage versions and dependencies. For admins who just need to move a few custom fields, it's machinery.

Both alternatives are gold-standard in mature DevOps shops. Both are painful for an admin with a weekend deployment window.

A Third Way: Data Migrator

SFDC Police's Data Migrator is built for the scenario Change Sets fail at: you need to move schema, data, and permissions together, with predictable deployment, visibility into what's happening, and the ability to roll back if something breaks.

Dependency-Ordered Migration

The Migrator ingests custom objects and fields from the source org, infers their dependencies (Custom Object A references B, Validation Rule X needs Field Y), and deploys them in the right order. No manual dependency tracking.

Schema + Data + Permissions

In one migration, you move custom objects, custom fields, validation rules, flows, permission sets, and their data. You don't have to coordinate multiple tools.

Dry-Run Preview

Before you deploy anything, you get a preview: these objects will be created, these fields will be added, these permission sets will be copied. You see exactly what's changing.

Rollback with Before-State Snapshots

If a deployment goes wrong, rollback is one click. The Migrator reverts every change to the original state before the migration started. This includes data — on rollback, records updated during migration are patched back to their original values, not deleted. You don't lose data on the way back.

Drift Detection

If you've deployed a field before and you're re-deploying with a different configuration (different field type, different default value, etc.), the Migrator detects it. It shows you three options: mirror the source (overwrite with new config), promote the target config as canonical, or repair the field to the source spec. You stay in control.

Composite-Key Matching

If you're migrating between orgs that aren't parent-child (both are prod orgs, or one is a legacy system), the Migrator uses natural keys to match records instead of relying on Salesforce IDs. Accounts match by name, products by SKU, users by email. You don't lose referential integrity.

Special Situation Handlers

For organizations like those using Salesforce's Consumer Goods Cloud, the Migrator knows about shared hierarchies, encrypted fields, assignment rules, duplicate rules, and territory management. It doesn't blindly copy them and break them.

When to Use Data Migrator vs. Alternatives

Use Data Migrator if:

  • You're migrating schema + data + permissions in one operation.
  • You need rollback if something breaks.
  • You want to see a preview before deploying.
  • You're migrating between unrelated orgs (both are prod).

Use Salesforce CLI if:

  • You're in a mature DevOps shop with Git and CI/CD.
  • You're deploying metadata from source control.
  • You need to version and audit every change.

Use Change Sets if:

  • You're moving a small number of components and comfort with the UI is your priority.

Getting Started

See the Data Migrator feature documentation for a step-by-step walkthrough. No setup required — the Migrator runs on your existing Salesforce session, reads metadata and data through the REST API, and streams dry-run previews and rollback logs back to your browser.

For more on alternatives and trade-offs, read How to Find Every God-Mode User in Your Org or explore the full features page.