How to Graduate From Change Sets to Source Control (Step by Step)

TL;DR: To graduate from change sets to source control, retrieve your org's metadata into a Salesforce DX project, commit it to a Git repository as your single source of truth, adopt a branch-per-environment model, and deploy through an automated pipeline instead of clicking change sets org to org. Do it incrementally: start with one project, prove the workflow, then bring the rest across.

Why move from change sets to source control at all?

Change sets are a manual, org-to-org tool with three hard limits: no version history, no rollback, and no audit trail. Each deployment is a fresh rewrite of metadata with no record of what changed or why, and they only move between orgs that share the same production. Salesforce itself now recommends teams adopt DevOps practices and graduate from the org-to-org release model.

Source control fixes all three. Git gives you a single source of truth, a full history of every change, branching and merging for parallel work, and the ability to roll back to a known-good state in minutes. It is the foundation every other DevOps practice is built on.

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 graduate from change sets to source control, step by step?

1. Convert your metadata to source format. Use the Salesforce CLI to retrieve metadata into a Salesforce DX (SFDX) project, so your org is described as files rather than a change-set snapshot.
2. Create a Git repository. Commit that project as your baseline - the first single source of truth for the org.
3. Pick a branching model. The simplest is one long-lived branch per environment (for example dev, uat, main), with feature branches merged in through pull requests.
4. Automate deployment. Wire a pipeline that deploys from each branch to its environment on merge, running validation and tests automatically instead of manual change-set uploads.
5. Add tests and checks. Require Apex tests, code review, and validation to pass before a merge reaches production.
6. Retire change sets. Keep them only as an emergency fallback once the pipeline is trusted.

You do not have to do this big-bang. Start with a single project or team, prove the workflow, then bring the rest of the org across.

What tools do you need to make the move?

At minimum: a Git host (GitHub, GitLab, or Bitbucket), the Salesforce CLI, and a Salesforce DX project. Salesforce's free DevOps Center adds source control, work items, and change tracking through a point-and-click interface, which is a solid first step for low-code teams. Growing teams usually move to a dedicated platform that bundles source control, automated testing, and rollback so admins do not have to live in the CLI. See how the pieces fit together in our SF Guides library.

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 the common migration mistakes?

• Do not retrieve everything at once. Start with the metadata your team actively changes, then expand.
• Watch profiles and permission sets. They are the trickiest metadata to version cleanly, so plan them deliberately.
• Do not run change sets and Git in parallel long-term. Two sources of truth defeats the purpose.
• Bring admins along. The switch fails on culture more often than on tooling.

When you are ready to move without the manual overhead, our migration guide walks the whole path.

FAQ

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

Largely yes. DevOps Center and third-party platforms provide point-and-click source control, though someone still runs the initial CLI retrieval to seed the repository.

What is a Salesforce DX project?

It is the source-format representation of your org's metadata as files and folders, retrieved with the Salesforce CLI, which Git then tracks and versions.

Is DevOps Center a full replacement for change sets?

For many teams, yes. It adds version control and change tracking on top of Git, but larger teams often need the automated testing and rollback that dedicated platforms provide.

How long does the migration take?

A single project can move in days. A full multi-team org is usually a phased rollout over weeks, done environment by environment.