From Change Sets to Source Control: The Shift You Can’t Ignore Anymore

When Salesforce first introduced packaging, it wasn’t seen as a development strategy. It was a way to bundle components for distribution, primarily for ISVs building apps for AppExchange.

Most internal teams still relied on change sets, manual deployments, and metadata migration tools. The concept of modular, versioned development was far from reality.

Over time, however, the Salesforce ecosystem changed dramatically. What began as an optional feature for a small subset of ISVs has evolved into a central pillar of how modern Salesforce engineering teams build, deploy, and maintain systems.

Understanding that journey explains why packaging is no longer just “nice to have”; it’s the foundation of scalable development.

The early days: 1st generation managed packages

Before Salesforce DX existed, development happened directly inside orgs. Teams built features in sandboxes, used change sets or ANT scripts to deploy metadata, and often had no single source of truth. First-generation managed packages (1GP) allowed ISVs to distribute applications and control their intellectual property, but they came with major constraints.

Package creation and versioning were tied to the packaging org itself. Code lived in the org, and developers had to manually manage dependencies. There was no real connection to Git or CI/CD, which meant collaboration was slow and error-prone.

For most internal Salesforce teams, packaging felt like overkill. They stuck to direct deployments because that was faster, at least until systems grew large enough that it wasn’t.

The shift: Salesforce DX and the CLI era

The turning point came with Salesforce DX (SFDX) and the Salesforce CLI. It introduced a developer-first approach: source-driven development, scratch orgs, and external version control. For the first time, the org stopped being the source of truth.

This shift redefined how packages were created and maintained. Metadata could be extracted, stored in Git, and deployed consistently through automated pipelines. Salesforce introduced the concept of unlocked packages for customers and partners, designed to break large monolithic orgs into smaller, modular components that could evolve independently.

Unlocked packages were followed by org-dependent unlocked packages, which helped teams transition gradually from traditional org development without needing to refactor everything at once.

If you’ve been building directly in orgs your whole Salesforce career, this is where the shift starts to make sense. You don’t need to move everything overnight. You can begin small, package a single feature, a module, or a business process, and start tracking it in source control.

Have you ever wished you could roll back a change without losing hours of work? Or see exactly what changed between releases? Or deploy with confidence knowing every dependency is accounted for? That’s what org-dependent unlocked packages enable.

They let you adopt versioning, modular development, and CI/CD practices without breaking your existing structure. No massive refactor. No full metadata migration. Just a practical path from org-based building to modern, source-driven development.

These steps marked a clear direction: Salesforce wanted every team, not just ISVs, to move toward modular, source-controlled delivery at a pace that fits their reality.

Second-Generation Managed Packages: built for modern development

The introduction of second-generation managed packages (2GP) solidified this evolution. Instead of building and managing everything inside a single packaging org, developers could now create packages directly from their local source, version them through Git, and release them via the CLI.

This was a major change. It made packaging compatible with CI/CD tools, automated testing, and modern development practices. 2GP also improved dependency handling, namespace management, and security while aligning closely with how most SaaS platforms now manage releases.

Today, second-generation packaging is the default path for new ISVs and increasingly for enterprise teams who want maintainable, scalable development workflows. Salesforce continues to invest in improving this tooling, from the DevHub model and scratch orgs to the DevOps Center interface that abstracts much of the CLI work for admins.

From optional to essential

For years, packaging was treated as optional, something you’d only adopt once your org reached a certain size or complexity. That view is quickly becoming outdated. The reality is that every Salesforce team, whether building for internal use or commercial distribution, benefits from having source control and versioned packages.

The advantages go beyond deployment speed. Source-driven development ensures reproducibility, easier auditing, and safer releases. It eliminates the “works in sandbox but breaks in production” problem by enforcing consistent metadata definitions across environments. It also reduces maintenance overhead by letting teams manage upgrades and dependencies through versions instead of manual patching.

In short, packaging has matured from an AppExchange distribution mechanism into the backbone of sustainable Salesforce delivery.

What teams should be asking now

The conversation is no longer “Should we use packages?” but rather “ How do we start, and how fast can we migrate?”

Some key questions to consider:

• Is your team still deploying manually through change sets or scripts?

• Do you have a reliable source of truth for your metadata?

• How quickly can you reproduce a full environment from the source?

• Are your dependencies and integrations tracked, versioned, and testable?

• Can your developers work in parallel without overwriting each other’s work?

If your answer to any of these is “not yet,” it’s time to think about modernising. Migration doesn’t have to happen overnight, but every incremental move toward source-driven, package-based delivery pays off.

Here is everything you need to know about the shift's importance & implementation. "The Secrets of Salesforce Second Generation Managed Package"

Where tools like Serpent fit in

The technical foundation is now solid, but setting up CI/CD, version control, and packaging workflows still takes time. This is where solutions like Serpent by Tekunda can make the transition easier. Serpent streamlines Salesforce DevOps by automating packaging, version management, and deployment processes through a simple interface built around Git and the Salesforce CLI.

With guided onboarding, automated release pipelines, and native Git integration, Serpent helps teams move from manual org development to fully automated delivery, without adding unnecessary complexity. For teams considering their next step in packaging evolution, it’s a fast way to see the benefits in practice.

The takeaway

Salesforce package development has come a long way. What started as a niche ISV tool has evolved into a core part of how professional Salesforce engineering is done. The question is no longer whether your team should use packaging, but how quickly you can embrace it.

Moving toward source control and modular packages is not just a best practice; it’s the direction Salesforce itself is building toward. The sooner you align, the faster your releases, the cleaner your architecture, and the smoother your scaling will be.