Not on Source Control Yet Is a Hot Signal, Not an Embarrassment

Short answer: a Salesforce team still deploying with change sets is not behind, it is unencumbered. There is no half-built pipeline to unwind, no abandoned branching model to explain, and no scripts written by someone who left. The first week of source control is shorter for that team than for almost anyone else, and the improvement is larger.

Why is "not on source control yet" a hot signal?

Because the gap between where you are and where you could be is the whole distance, and none of it is blocked by a previous decision. Teams that never started have three quiet advantages:

• Nothing to migrate. Your org is the source of truth today. That is a clean baseline, not a mess.
• No sunk-cost politics. Nobody has to admit that the pipeline they championed in 2023 was a dead end.
• No habits to unlearn. The team learns one workflow, once, and that workflow can be the modern one.

The Salesforce teams with the worst release outcomes are rarely the change-set teams. They are the half-migrated ones: two deployment paths running in parallel, one person who understands the YAML, and a review step everyone routes around when the release is late.

What is change-set pain actually made of?

The pain is real, and naming it precisely matters more than being told you are behind. Working from a good published rundown of how change sets behave, the recurring costs are:

• A change set cannot be edited after upload. Forget a component and you clone and rebuild the package.
• Components are selected by hand, and the dependency helper misses indirect chains of references.
• Deployment connections are one-directional by default, and unrelated production orgs cannot deploy to each other at all.
• Some metadata simply will not travel, including standard picklist values and org-wide email addresses.
• Profiles overwrite in the target org, silently removing permissions that were not in the source.
• There is no rollback after a deployment, and no snapshot taken before it.

Notice that none of that is a skills problem. It is a tooling problem your team has been absorbing with overtime.

What do you actually have to learn?

Less than the discourse implies. The industry habit of answering "we are not on Git yet" with a branching-strategy lecture has done real damage, because it moves the first step from deploy more safely to become a developer. Those are not the same project.

What a change-set team already has is most of what matters: knowledge of the org, a sandbox habit, a sense of what breaks. What it needs is a record of every change, a way to reverse one, and a review that happens before production rather than after the incident. Git can supply all three while running in the background. Whether your admins ever open a terminal is a tooling choice, not a law of the platform.

How do you start next week without a DevOps engineer?

1. Snapshot the org into a repository. Not to deploy from yet. Just so that today's state is recorded and tomorrow's changes are visible as a diff.
2. Connect your existing sandboxes. Keep the environments you have. The path from developer sandbox to UAT to production does not need to change on day one.
3. Move one recurring change type. Pick the deployment you do most often and route only that one through the new path for two weeks.
4. Get rollback working before you widen scope. The first time a release is reversed in a minute instead of an evening, the argument for the change is over.
5. Add review last. Once changes arrive as diffs, a second pair of eyes costs minutes. Adding review before that is what makes teams quit.

You can do this with Salesforce DevOps Center, with Gearset or Copado, or with Serpent. Compare them honestly on one axis first: how much of the workflow assumes a person who writes YAML for a living.

What should you ignore?

• Maturity models that rank you against companies with a platform team of eight.
• Branching-strategy debates. One protected main branch and short-lived feature branches will carry you for years.
• Anyone implying source control is a moral position. It is a mechanism for undoing mistakes. That is all it has ever been.

Serpent was built for exactly this starting point: ticket-based deployments with Git running underneath, one-click rollback, AI code review on every plan, and no Git expertise required from admins or consultants. It installs nothing in your org, setup takes under 15 minutes, and our team runs a hands-on session with everyone rather than handing you a manual. There is a free Essentials plan with unlimited users, and you can pick a prepopulated demo workspace during signup if you want to look before you connect anything. Start at Serpent.

FAQ

Is it too late to move off change sets?

No. Change sets are still supported and still work. Moving is a decision about deployment risk and team time, not a deadline you have missed.

Do our admins have to learn Git?

Not with tooling that keeps Git in the background. Admins should understand what a version and a rollback mean. Branching commands are optional.

What is the single biggest win in week one?

Rollback. Being able to reverse a bad release quickly changes how a team feels about deploying more than any other single capability.

Is DevOps Center enough?

It is a genuine step up from change sets and it is free from Salesforce, so it is a fair place to start. Teams usually outgrow it when they need packaging, testing gates or richer rollback.

Should we clean up the org before we start?

No. Put the org under source control as it is. A recorded mess is far easier to improve than an unrecorded one.