How to Graduate From Change Sets to Source Control in Salesforce

TL;DR: To graduate from change sets to source control, put your org's metadata in a Git repository, adopt a source-tracked development environment, and deploy through a pipeline instead of hand-picking components. Do it incrementally: enable source tracking, pilot one team on Git and a validate-only pipeline, then retire change sets scope by scope.

Salesforce itself now recommends customers graduate from the org-to-org release model, and most guides tell you why change sets fall short. Fewer give you the actual migration path. This guide is that path: a repeatable playbook you can run without freezing delivery.

What does it mean to graduate from change sets to source control?

It means moving the source of truth for your metadata out of the org and into a version control system, usually Git. Change sets copy components org to org and leave no history. Source control stores every layout, flow, permission set, and Apex class as versioned files, so you can branch, review, deploy, and roll back. The org becomes a deployment target instead of the master record.

Why move off change sets?

Change sets are a fine starting point and stay useful for tiny teams. They hit a wall as you grow:

• No version control and no history of who changed what.
• No automated rollback if a deployment goes wrong.
• No code review before changes land.
• Manual selection of every component, which is slow and error-prone.
• Unsupported metadata types and immutable, non-editable uploads.

When is it time to make the switch?

Consider moving as soon as any of these are true:

• More than one person makes changes in parallel.
• You run three or more environments.
• You ship frequent or emergency releases.
• You have compliance needs: approvals, separation of duties, audit trails.

If two or more apply, change sets are already costing you more than they save.

How do you migrate from change sets to source control?

Run these steps in order. The goal is a working pipeline for one scope before you expand.

1. Create the repository. Stand up a Git repo and agree a branching model your team understands.
2. Enable source tracking in production. New Developer and Developer Pro sandboxes then inherit it, which is what makes automatic change capture possible.
3. Establish a baseline. Retrieve your existing org metadata with the Salesforce CLI and commit it as the first snapshot of truth.
4. Convert to source format. Use the CLI to break large metadata files into smaller, mergeable source files that reduce conflicts.
5. Pilot one team. Move a single team or project to feature branches and a validate-only deployment while everyone else keeps using change sets.
6. Add continuous integration. Wire a pipeline that validates each pull request and deploys merged source to the next environment.
7. Retire change sets by scope. Once the first pipeline is trusted, switch that scope off change sets and repeat for the next team.

Change sets vs source control: what actually changes?

• Source of truth: the org becomes a deployment target; the repository holds the record.
• Change capture: manual ticking becomes automatic source tracking.
• Review: no review becomes pull requests.
• Deploy: manual clicks become a repeatable pipeline.
• Recovery: no rollback becomes revert-and-redeploy from history.

Which tools should you use?

The free baseline is Salesforce's own: the Salesforce CLI, Salesforce DX, and DevOps Center, which replaces change sets with a Git-backed UI and integrates with GitHub and Bitbucket. When you need managed pipelines, backups, metadata-aware diffs, and quality gates, platforms such as Serpent, Copado, Gearset, AutoRABIT, Flosum, Salto, and Blue Canvas build on the same Git foundation. Start free, then adopt a platform when process, not tooling, is your bottleneck. We walk through this specific upgrade path on change sets versus Serpent. For more Salesforce DevOps how-tos, see the Serpent guides.

For the mindset shift behind the move, read the shift you can't ignore anymore, and when you are ready to build a repeatable release flow, our change sets to continuous delivery playbook takes it further.

How do you avoid common migration mistakes?

Do not try a big-bang cutover. Migrate one scope at a time and keep change sets running in parallel until each pipeline is proven. Enable source tracking before you build, not after, or your first sandboxes will not capture changes. And baseline the whole org before anyone starts a feature branch, so your repository reflects production from day one rather than drifting from it.

Plan profiles and permission sets deliberately, since they are the hardest metadata to version cleanly. Keep the parallel run short, because two sources of truth for long defeats the purpose. And bring admins along from the start: the switch fails on culture more often than on tooling.

FAQ

Do I have to stop using change sets immediately?

No. Migrate scope by scope and keep change sets for teams that have not moved yet, so delivery never freezes.

What environments support source tracking?

Scratch orgs and Developer and Developer Pro sandboxes support source tracking; Partial Copy and Full sandboxes do not.

Is DevOps Center enough, or do I need a paid tool?

DevOps Center is a free, Git-backed starting point. Add a commercial platform when you need managed pipelines, backups, or advanced quality gates.

How do I baseline an existing org?

Retrieve the org's metadata with the Salesforce CLI, convert it to source format, and commit it as the first version in your repository.

Can I move from change sets to Git without writing code?

Yes. Serpent gives admins point-and-click source control on Git, and our team seeds the repository with you, as we show in change sets versus Serpent.