Highlights
- Change Sets are limited in scope and scale, and need to be retired.
- Salesforce offers DevOps Center as an included tool that works relatively simply out-of-the-box.
- The Salesforce CLI is a powerful, open-source tool that can be used to assist with your DevOps process. However, it is not in and of itself a DevOps tool.
- Third-party tools bring many different features and benefits to the table, but come at an additional cost.
According to the SF Ben Salesforce Admin Survey Results 2026, Change Sets remain the primary method for deploying changes from sandbox to production. Almost half of all respondents (41.6%) responded that they continue to use this archaic tool to move metadata between orgs.
There are many reasons that this could be the case, but one that I intend to resolve today is simply that there is a lack of awareness of other options. This article serves as your ultimate resource for selecting a better DevOps tool.
You’ll learn why Change Sets need to be left in the past, the options that you have available to you, and how to select the best tool for your organization.
Change Sets Are On Borrowed Time
You’ve likely already heard that Change Sets aren’t fantastic, but you may be curious as to why. In short, they do not support true version control (there’s no rollback history, no succinct audit trail of the Change Set itself).
The process is manual and prone to human error, with no standard way of scripting them. They don’t scale with the size of your team, either. They’re passable if you’re a solo admin, but with multiple contributors or when working as a team, they get overcomplicated quickly.
Change Sets are on borrowed time. If you’ve used them in the past and still use them as a quick-and-nasty way of moving metadata between orgs, you should consider the long-term impact of doing this. I don’t say this as someone sitting up on a pedestal – I myself still use Change Sets from time to time when I’m in a rush. Slowly but surely, I’m moving over to a better tool – more on that later.
Version Control for Salesforce Admins
From the get-go, I want to be clear about something. The purpose of this article is not to give a deep dive into Git, but rather to help Salesforce Admins understand some concepts that may not be super familiar to them. By the end of this article, you’ll understand why using a proper version control system for your Salesforce org is critical to your success as a Salesforce professional, and for the business you work for.
That being said, there are some core concepts that you’ll need to wrap your head around, at least at a high level, before you can make the best decision around which tool you want to use. That’s what this section is for – so strap in, and let’s get into some jargon and version control basics.
Branching
Think about how you use sandboxes for building out new features today (I really hope you are, or you’ve got some bigger fish to fry!). You’ll spin up a sandbox, build your changes, hopefully test a deployment to another sandbox at the very least, and then push the changes to production. This is the most common approach that I see personally. This is where branching can make things a lot easier for you.
Branching basically empowers you to spin up a new sandbox for every specific project that you wish to make. Your main codebase spins off into a new branch that you can then use to build a new feature without directly impacting your production code. Once you’re done and happy with your changes, you can then merge them back into the main branch.
A good practice is to have a single branch per feature or project that you’re working on. This can be a bit difficult to do solely with sandboxes (which is why you often see Salesforce Admins having Prod, Partial, and Dev only and reusing them across multiple projects). Branching solves this problem.
Environment Synchronization
There’s nothing more frustrating than building and testing a new feature in a sandbox, only to realize that you’ve been building with a version of Salesforce that’s six months out of date. After deployment, you learn that your new automations are clashing with something built a few months ago, and causing grief for your users. Yuck.
It’s critical to work in a fresh environment that’s up to date with your production org at all times to avoid this. This is why you’ll want to make sure that you’re keeping your various environments in sync as much as possible. In the Salesforce world, this is done typically through keeping sandboxes refreshed frequently and leveraging scratch orgs for feature development.
Pull Requests
When building in Salesforce, working in a team is a luxury that not everyone has. There are many Salesforce Professionals who work alone and bear the burden of managing the org entirely on their own.
However, when working in a team, it can be difficult to keep track of who’s working on what, and where it’s located. Pull requests simplify this process by formalizing the process of merging code from one branch to another. Think of a pull request as a checkpoint for your code before it’s merged into the main branch – which reduces the risk of introducing big bugs into production.
The PR shows what was changed, what specifically in those files was changed, all the commits that make up the PR, and who made those changes. A great way of tracking changes and managing them across a larger code base.
Rollback/Version History
Change Sets just got real quiet over there in the corner, as it lacks an easy way of rolling back to a previous version of the code! There’s nothing worse than pushing something to production only to realize it needs to be reverted… and needing to do so manually.
Luckily, this is something that has been solved in the dev world in the form of a rollback, and is built into source control tools like Git. Let me tell you from personal experience – once you’ve used a tool like git that supports rollback, and you’ve needed to use it, it’s a life-changing experience.
High-Level Overview
Now that you understand some of the benefits of using a more advanced option than Change Sets, you may be wondering which one is best suited for your needs. To be clear – there’s no one solution for everyone. Every individual is different, and every org is different.
To keep things as uniform and easy to compare as possible, I’m going to do my best to give each tool a detailed rating based on the factors outlined below.
- Learning Curve: How easy is it for someone new to the tool to pick it up and begin gaining value from it?
- Cost: The financial impact of using the tool.
- Metadata Management: How easy is it to bundle your metadata into a package and deploy it where it needs to go?
- Rollback Support: How easy it is to revert to an earlier state if you run into issues.
- Governance: Does the tool bake in the ability to create an audit trail of who made what changes and when?
- Multi-team Support: How easy is it to work with other team members to work on the same project?
Salesforce DevOps Center
For this section, I’m specifically referring to the “Next-Generation DevOps Center” that went GA in April 2026, following its showcase at TDX 2026. This version no longer requires the installation of a managed package and is baked right into your Salesforce org. Salesforce also markets this option as totally free, not requiring any additional licenses above those you already have in most cases.
This tool was designed to bridge the gap between developers and admins, and as such is a fantastic option for replacing Change Sets in a majority of Salesforce orgs. It’s designed to be frictionless from the get-go, and fixes many of the issues that Change Sets have.
Learning Curve
By design, the learning curve for Salesforce DevOps Center is very low. When Salesforce introduced this tool, their goal was to bridge the gap between developers and admins. For this reason, the tool is very admin-friendly. That said, it’s not the kind of tool that you’d immediately know how to use without some training or guidance.
The Salesforce DevOps Center scores a 4 out of 5 for learning curve.
Cost
Salesforce DevOps Center is free to enable once you’re a paying Salesforce customer. So, if we’re being pedantic, it’s not truly free – the cost lies in the core Salesforce licensing. However, for this comparison I’m going to continue to refer to it as free, as I won’t be including the cost of Salesforce licensing for each other tool.
With this in mind, Salesforce DevOps Center scores a 5 out of 5 for cost.
Metadata Management
Salesforce DevOps Center can be set up to automatically track your metadata changes and keep them in sync with your source control system. You’ll use Work Items to organize your changes, and deploy them with relative ease using the visual deployment pipeline.
However, one issue that it has is that it only supports linear deployments. If you’re a consultant and you’d like to build something to deploy across multiple customers, then you’ll need to use another tool. DevOps Center only supports the ability to deploy up and down along a single production environment.
I’m scoring it a 3 out of 5. It’s super simple to manage your metadata, including changes and built-in source tracking, but the inability to move from one production environment to another is a big downside.
Rollback Support
Salesforce DevOps Center does not have a native rollback feature. That said, if you need to roll back a deployment, you can create a new Work Item to rectify those changes and push them instead. This isn’t a true rollback, though, as you need to manually revert and redeploy.
Unfortunately, Salesforce DevOps Center scores a 1 out of 5 in this category. It keeps a single point due to its ability to connect to source control systems that can revert, but it is still a fiddly process.
Governance
Governance has improved significantly with the introduction of the new version of Salesforce DevOps Center. There is a dedicated Governance feature that can be enabled, which gives access to a Governance tab in the DevOps Center navigation. This gives you granular governance controls. There are also six predefined governance policies that cover the most critical security and quality risks when using AI-assisted development, which is fitting given the era that we’re in.
Governance is a 4 out of 5 for Salesforce DevOps Center.
Multi-Team Support
Salesforce DevOps Center works well for small teams (far better than change sets). However, its rigidity means that it isn’t a great fit for larger organizations that need more complex deployment pathways or need the ability to work with multiple production orgs in a single project.
I’m giving Salesforce DevOps Center a 3 out of 5 for multi-team support.
Salesforce CLI
I’ve always been a fan of Change Sets – I’ll admit it. When I started my Salesforce career, it was all that was available to me. I learned them, used them, worked with their limitations, and they’ve been a tough habit to break. Learning how to work with the Salesforce CLI was a challenge, but well worth it for me, as it broke my Change Set addiction.
As a Functional Consultant, I needed to have access to a tool that would work for multiple clients (in other words, not one that needed a per-org license). I also wanted something available out-of-the-box and didn’t require additional security approval beyond core Salesforce.
That said, the Salesforce CLI is a whole different beast than DevOps Center. It’s powerful, but it’s far less user-friendly, as you’ll see below.
Learning Curve
With great power comes great responsibility, and with flexible tooling often comes complexity. This is where the Salesforce CLI takes a little bit of getting used to, especially if you’re not used to working with the command line.
If you’re going to attempt to use the Salesforce CLI, which I highly recommend you do, you’ll need to spend some time learning how to work with your computer’s terminal. This is extremely daunting if you’re a clicks-not-code kind of Salesforce professional, but once you realize exactly what you’re trying to do and ignore the rest, it gets easier.
Unfortunately, the Salesforce CLI gets a 1 out of 5 for learning curve for this reason.
Cost
Once again, the Salesforce CLI is free to use as Salesforce doesn’t charge for it, nor does it require a license to download it. In fact, it’s open source, so you can download it and use it no matter who you are or what system you’re on. Technically speaking, you can even use it if you don’t have a paid Salesforce license!
As such, the Salesforce CLI gets a 5 out of 5 for cost.
Metadata Management
The Salesforce CLI is really good at metadata management in terms of extraction, deployment, and packaging. Given that it’s a command-line tool that manages metadata locally, you can also connect it to your source control system of choice. Leveraging a Salesforce DX project, you can also enable source tracking with the Salesforce CLI. That said, there’s still a lot of manual work required if you’re not super familiar with the tool.
The Salesforce CLI shines here and gets a 5 out of 5 for metadata management.
Rollback Support
While the Salesforce CLI doesn’t support a native rollback solution, you can cancel a deployment that is in progress or queued. You can then leverage your source control tool to roll back or revert to a previous version of the metadata, as required.
Similar to the Salesforce DevOps Center, the Salesforce CLI gets a 1 out of 5 for rollback support given its ability to revert or roll back using a connected source control system. It’s still a manual process, and there’s no native rollback support built directly into the Salesforce CLI.
Governance
This is where the Salesforce CLI shows a bit of a weakness. Given that it’s a pretty low-level tool that’s designed to be used in conjunction with other tools, it doesn’t have any governance built in. This is by design, though, as it’s supposed to be flexible enough for developers to bring their own governance systems.
Unfortunately, this means that the Salesforce CLI gets a 1 out of 5 for governance. Its saving grace is the ability to easily connect to other governance tools, but there is nothing built in.
Multi-Team Support
The Salesforce CLI operates on a per-user basis. You download it onto your local computer, install it, and operate it yourself from there. Any multi-team support is due to it being connected to a source control system, but there’s no built-in multi-team support feature directly in the Salesforce CLI.
Similarly, the Salesforce CLI gets a 1 out of 5 for lacking native, built-in multi-team support features.
Third Party Options
Rather than considering just one of the many third-party DevOps options that are available in the Salesforce ecosystem, I decided to look at them holistically. I don’t want to be trying to assess every single tool, nor do I want to highlight just a handful, as this wouldn’t be a great analysis.
Instead, I’m going to do my best to cover third-party DevOps tools as a whole.
Learning Curve
Each tool is different, and this is by design. A smaller team of two or three Salesforce Admins may find value in a simpler tool designed for small teams. They would struggle to find value in a more advanced tool designed for large teams and complex environments.
As such, each DevOps tool requires its own learning. It’s not as simple as learning how to use one tool and you’ve mastered them all. Each is unique and will require upskilling when you implement it. Typically, though, these tools are designed to be as user-friendly as possible for their target audience. In my experience, this pays off and leads to relatively low learning curves.
I’m going to give the learning curve a score of 4 out of 5, but this will vary based on the tool that you select.
Cost
Third-party DevOps tools can be expensive. Compared to the two earlier options, which were both free or included with your Salesforce license, anything with a price tag is going to be more expensive.
This begs the question: why would someone pay for a DevOps tool if there are free options available from Salesforce directly? It’s the same reason you’d pay for Salesforce in the first place, over the free alternatives – quality and a specific subset of features. If you’d prefer more control over how your DevOps process works, or you’re happy with the built-in features, then Salesforce CLI or DevOps Center are great options. If not, then there’s likely to be a third-party tool that does what you need it to do.
Third-party DevOps tools receive a 1 out of 5 for cost, but there will be fluctuations depending on the tool that you select. Some charge per org, others per user, and the cost varies significantly. It all depends on the features that you’re buying and how much you’re willing to pay for them.
Metadata Management
Once again, this differs from tool to tool, but in my experience most of them manage metadata relatively well. There will be some tools that have the ability to deploy across multiple production orgs, and others that don’t. Again, this really depends on the tool that you’re after and the features that you’re looking for.
As such, it’s difficult to give a score for metadata management, but in my experience of using multiple DevOps tools, they’re all sitting around the 4 mark for metadata management.
Rollback Support
A majority of the DevOps tools that I’ve used have some form of rollback support, which is something that Salesforce doesn’t offer. Again, not all third-party DevOps tools will have rollback support, so take this with a grain of salt and choose wisely.
Third-party tools get a 4 out of 5 for rollback support, given that they’re far more likely to have something available out-of-the-box.
Governance
Most DevOps tools have some form of governance baked in, with many vendors even proudly boasting about their certifications and compliance. It really depends on which tool you select, though, so it’s important to do your due diligence and ensure that the tool you want to use gives you the level of governance and control you need.
In general, third-party DevOps tools get a 3.5 out of 5 for governance.
Multi-Team Support
This is where third-party DevOps tools really shine. By their very nature (even if just to sell more seats!), they support multi-team environments very well. Tools that are installed into Salesforce directly are designed to be accessed and used by multiple people.
Similarly, tools that connect to Salesforce are often designed to be used by multiple people through a web interface. Within both of these experiences, pipelines are managed by multiple people, rather than just one.
Third-party DevOps tools get a 4 out of 5 for multi-team support.
Quick Comparison
Below is a quick comparison of the tools I’ve overviewed in this article. Again, the third-party DevOps tools will depend on the tool that you select. The numbering is based on my personal experience with years of using external tools, and as a way to get a rough understanding of how they compare to the first-party options.
You’ll notice that I’ve not calculated the total score for each tool as well. This is on purpose, as I don’t believe it’s as simple as that. Each tool has its own strengths and weaknesses, and giving a total score or crowning a winner would be a disservice to you, the reader.
| Salesforce DevOps Center | Salesforce CLI | Third-party DevOps tools | |
|---|---|---|---|
| Learning Curve | 4 | 1 | 4 |
| Cost | 5 | 5 | 1 |
| Metadata Management | 3 | 5 | 4 |
| Rollback Support | 1 | 1 | 4 |
| Governance | 4 | 1 | 3.5 |
| Multi-Team Support | 3 | 1 | 4 |
A small caveat that I really can’t stress enough: The Salesforce CLI is not a DevOps tool. It is a low-level tool that makes it easier for you to manage your DevOps process, but it is not a DevOps tool by design.
This is why it may appear to score lower than the other tools. If you’re looking for something with a lot of flexibility and low cost, and you’ve either got the time to learn how to use it or you’ve got experience already, then the Salesforce CLI is a great option.
How to Pick Which Works For Your Org
As I said earlier, there is no one-size-fits-all solution. I’ve not crowned a winner, and I’ve deliberately avoided giving names to any of the third-party tools I was referencing. I don’t want to be trying to convince you that one tool is better than another, as there truly is a different correct answer for every business, based on their needs.
In order to pick the right tool for you, you first need to understand exactly what your priorities are in terms of the features you need, the budget you have for tooling, and the time you have to learn and implement the tool.
This is why I’ve compared the tools on a category-by-category basis, and not tried to give each a total score. Each business’s requirements are unique, so there’s no point trying to compare apples with oranges here.
Final Thoughts
Change Sets served their purpose, and you may be finding that using them is a tough habit to break. However, there are so many better options out there. Salesforce’s CLI is great if you want control, and DevOps Center is great if you want a great tool at no additional cost. If neither of those works, there are plenty of third-party options that serve various audiences.
Which DevOps tool do you use? If you’ve been using Change Sets, has this article changed your mind, and which option are you looking at using? I’m also curious to learn which third-party tools the Salesforce community is using – let me know your tool of choice!
