Why Change Sets Are Holding Your Salesforce Team Back

The short version: change sets are not still around because DevOps tooling is too expensive. They are still around because the release process was built around them, and that process is what nobody has budget to change. The cost shows up as rework, not as a line item, which is exactly why it never gets challenged.

Why do change sets still survive in most orgs?

Not because teams have not heard of the alternatives. Because the change set is load bearing in the process around it. Someone owns the spreadsheet of components. Someone else has the profile that lets them upload. UAT sign-off is a screenshot in a ticket. Release night is a calendar invite, and the invite is the plan.

Swap the tool and every one of those habits breaks at once. That is a much larger ask than a licence, and it is the real reason a team that agrees change sets are painful still ships with them next quarter.

What do change sets actually cost?

Not the twenty minutes of clicking. The cost is rework, and it accumulates in five places.

• Rebuilding the list. A change set is a manual inventory of what you think you changed. Anything you forget fails the deploy or, worse, half-succeeds.
• No rollback. There is no reverse button, so the disciplined version of the practice is building a second, mirrored change set for every release, which doubles the work in exchange for a partial safety net.
• Metadata you cannot move. Some component types simply are not supported, and each one becomes a manual post-deployment step that lives in someone's head (documented limitations).
• Profiles. Deploying a profile overwrites the target, so permissions that only existed downstream quietly disappear.
• No parallel work. Two people editing the same object in two sandboxes discover it at deployment time, because nothing is comparing anything.

None of that appears in a budget line. It appears as releases that slip, as the same admin staying late every month, and as the unspoken rule that you do not deploy on a Friday.

Isn't DevOps Center the answer?

It is a real answer to part of the problem, and it is free. Salesforce shipped DevOps Center to general availability in December 2022 (release notes), replacing manual component picking with change tracking and a work-item pipeline over Git.

Where teams hit the ceiling is what it does not do: there is no automatic rollback, no backup and restore, and version control support is limited to a small set of hosted Git providers. In July 2026 Salesforce Ben covered DX Inspector, described as a Salesforce deployment tool that moves both metadata and record data and can integrate with DevOps Center (write-up). The direction of travel is clear enough: even Salesforce is not investing in change sets.

Why doesn't the budget argument hold anymore?

It used to be a fair objection. A five-person admin team could not justify per-seat pricing that scales with headcount, and DIY pipelines need a person who knows Git, which is the one thing that team does not have.

That gap has closed from both ends. DevOps Center is free. Serpent's Essentials plan is free too, with unlimited users, one-click rollback, AI code review and full package workflows, and Serpent installs nothing in your org. Gearset, Copado, Flosum and AutoRABIT all publish their own long lists of change set limitations, which is a useful signal in itself: the pain is not disputed by anyone selling into this market.

So the question stopped being what does a tool cost. It is now whether your team is willing to change how a release gets approved.

What actually changes when you drop the habit?

The mechanics matter less than the shift in who can ship. When work items carry their own changes, an admin can deploy without asking a developer for a merge, and the release manager stops being a bottleneck holding a spreadsheet.

Most Salesforce teams are admins and consultants who have never touched a terminal. A process that requires Git fluency to be safe will simply not be adopted, and the team will keep clicking.

This is the part that decides adoption. Any tool that turns your admins into reluctant Git users has moved the bottleneck rather than removed it.

How do you move off change sets without stopping delivery?

1. Pick one pipeline, usually a single production org and its sandboxes, and leave the rest alone.
2. Get the current state of that org into source control before changing any process, so you have a baseline to compare against.
3. Run the next release both ways for one cycle. The new pipeline builds the package, the old process stays as the fallback.
4. Move approvals into the work item, not a spreadsheet. This is the habit that actually has to break.
5. Only then turn on automation: validation on pull request, test runs, rollback, drift detection.

Teams that try to do all five in one release usually revert to change sets in week three, and conclude that the tooling failed. It did not. The process change did, because it was attempted all at once. You can see how we approach it at Serpent, where setup takes under 15 minutes and onboarding for the whole team is included.

FAQ

Are change sets deprecated?

No. They still work and Salesforce has not announced a retirement. But the platform's investment has moved to DevOps Center and newer tooling, so betting your release process on change sets is a bet on stasis.

Can you roll back a change set?

Not natively. The common workaround is preparing a mirrored change set that redeploys the previous version, which only helps for components that already existed.

Is DevOps Center enough on its own?

For a small team on a simple pipeline, often yes. Teams usually outgrow it over rollback, backup, testing gates and support for their Git provider.

Do admins need to learn Git to leave change sets?

They should not have to. Choose an approach where source control runs underneath the work item rather than in front of it, or adoption will stall with the people who do most of the changes.