Change Sets vs SFDX: Choosing the Right Deployment Approach in Salesforce
The Deployment Question Everyone Faces
Building features in a sandbox is straightforward. Deploying them to production opens a minefield of decisions. Two completely different paths exist: Change Sets (the GUI-based approach) and Salesforce DX (the source-driven workflow). Every blog post declares "SFDX is the future!", but many orgs have successfully used Change Sets for years. This article cuts through the noise and explains when each approach actually makes sense, based on real project patterns across organizations of different sizes and maturity levels.
Deployments using both methods reveal that neither approach is universally "better." The right choice depends on team size, development patterns, existing infrastructure, and control requirements. What works for a 3-person startup doesn’t scale well for larger teams, and vice versa.
Change Sets: The Point-and-Click Deployment
How They Work
Change Sets are Salesforce's built-in deployment tool. Metadata components are selected in Setup, added to an Outbound Change Set, uploaded to the target org, and then deployed via the Inbound Change Set interface. Everything happens through the UI - no command line, no Git, no external tools required.
When Change Sets Make Sense:
Small teams (1-5 developers): Coordination overhead is minimal. Everyone knows what everyone else is working on.
Simple orgs with few customizations: Limited metadata means less chance of conflicts or missing dependencies.
Infrequent deployments: Monthly or quarterly deployments make manual processes acceptable.
Admin-heavy teams: Admins are comfortable with Setup but unfamiliar with command line tools.
No version control infrastructure: No Git repository, no CI/CD pipeline, no DevOps resources.
One-off emergency fixes: Quick production hotfixes without touching deployment pipelines.
The Good Parts:
Zero setup required - built into Salesforce
No external tools or CLI knowledge needed
Visual interface shows exactly what's being deployed
Works immediately, no authentication or connection setup
Non-technical users can deploy with proper permissions
Dependency validation happens automatically
The Painful Parts:
No version control - tracking what was deployed when becomes impossible
Can't see diffs between environments
No rollback capability - broken deployments require manual fixes
Complex dependency management - missing dependencies fail with cryptic errors
No automation - every deployment requires manual clicking
Profile/permission set deployments include everything, often failing or overwriting
Can't deploy certain metadata types (some settings, features)
No pre-deployment testing - hoping tests pass in production
Concurrent deployments cause conflicts
Change Set size limits (10,000 components)
Salesforce DX: The Source-Driven Approach
How It Works
SFDX (Salesforce CLI + source tracking) treats metadata as code. Metadata is pulled from orgs into local Git repositories, changed locally, committed, then pushed to target orgs. Everything lives in version control. Deployments can be automated via CI/CD pipelines (Jenkins, GitHub Actions, GitLab). Scratch orgs enable temporary development environments.
When SFDX Makes Sense:
Medium-to-large teams (5+ developers): Source control prevents conflicts. Feature branches isolate work.
Complex orgs with extensive metadata: Source tracking shows exactly what changed. Diffs are visible in Git.
Frequent deployments: Automated pipelines deploy on every merge. Manual processes don't scale.
Developer-heavy teams: Teams comfortable with Git, CLI tools, and DevOps practices.
Multi-environment strategy: Dev → QA → UAT → Prod pipelines require consistent deployments.
Rollback requirements: Git history enables reverting to previous states.
Compliance/audit requirements: Git log provides complete deployment history with who/what/when.
Package development: Creating managed/unmanaged packages requires SFDX.
The Good Parts:
Full version control - every change tracked in Git
Diffs show exactly what changed between versions
Automated deployments via CI/CD pipelines
Rollback by reverting Git commits
Scratch orgs for isolated development
Modular deployments - deploy only what changed
Better dependency management - package.xml is explicit
Testing runs before deployment (in CI/CD)
Multiple developers work simultaneously without conflicts
Metadata stored in readable XML format
The Painful Parts:
Steep learning curve - requires Git, CLI, and DevOps knowledge
Initial setup is complex - repos, pipelines, authentication
Metadata conflicts in Git require manual resolution
Source tracking can desync between local and org
Some metadata types don't work well with the source format
Profile/permission deployments remain problematic
Requires infrastructure (Git hosting, CI/CD tools)
Admins without a technical background struggle
Scratch org limits (active scratch orgs per day)
Learning investment required before productivity gains
Common Deployment Mistakes (Both Approaches)
The Top 10 Deployment Disasters:
Deploying without testing
Never deploy to production without running tests. SFDX automates this in CI/CD. Change Sets require manual test execution in the target org before deployment.Missing dependencies
Both approaches fail due to missing dependencies. Change Sets attempt detection but miss components. SFDX package.xml must include everything explicitly. Always deploy to the sandbox first.Profile/Permission Set chaos
Profiles include everything - all field permissions, object access, tab visibility. Deploying profiles often fails or overwrites permissions. Solution: Use Permission Sets, or break profiles into smaller pieces using SFDX source format.Deploying during business hours
Deployments lock metadata and can cause downtime. Deploy outside business hours or use maintenance windows. SFDX allows testing the deployment before execution.No rollback plan
Change Sets have no rollback - changes must be manually undone. SFDX can revert Git commits, but requires a clean history. Always document the rollback plan before deploying.Forgetting field-level security
Custom fields deploy without field-level security. Users can't see new fields. Change Sets require manually adding FLS. SFDX can include FLS in permission sets.Not validating before deploying
Both approaches support validation-only deployments. Always validate first, especially in production. Catch errors before they break production.Deploying everything at once
Large Change Sets (5,000+ components) often fail. Break into smaller deployments. SFDX allows incremental deployments - deploy only changed files.Ignoring deployment errors
Partial deployment success is still failure. If any component fails, investigate. Don't redeploy hoping it works. Check deployment logs thoroughly.No deployment documentation
Document what was deployed, why, and when. Change Sets provide minimal history. SFDX Git commits should explain changes. Future maintenance depends on this.
Problematic Metadata Types (Both Approaches)
These metadata types cause deployment headaches regardless of method:
Profiles: Include every permission in the org. Deploying profiles often overwrites existing permissions. Solution: Deploy permission sets instead, or use SFDX source format to break profiles into manageable pieces.
Custom Settings: Data and metadata are separate. Change Sets deploy structure, not data. SFDX requires separate data import. Solution: Export/import CSV data separately.
Email Templates: Classic vs Lightning templates have different formats. Folder structure matters. Solution: Keep templates in folders with clear naming. Deploy folders first, then templates.
Reports and Dashboards: Folder structure must exist first. Report types must be deployed before reports. Dashboard components reference reports. Solution: Deploy in order - folders → report types → reports → dashboards.
Custom Metadata Types: Type definition and records are separate deployments. Change Sets handle this poorly. SFDX requires two deployments. Solution: Deploy type first, verify, then deploy records.
Flows: Active flows can't be deleted, only deactivated. Deploying flow changes requires deactivation first. Solution: Include deactivation step in deployment process.
Sharing Rules: Recalculate after deployment. Can cause performance issues in large orgs. Solution: Deploy during low-usage windows, monitor sharing recalculation.
Managed Packages: Can't deploy managed package components. Dependencies on managed packages break deployments. Solution: Ensure all managed packages are installed in target org first.
The Hybrid Approach: Best of Both Worlds?
Using Both Methods Strategically
Many organizations successfully use both approaches. The key is defining when to use each one based on the situation, not rigid adherence to one method.
Practical Hybrid Strategy:
Regular development: Use SFDX for normal feature development. All code changes, metadata updates, and new features go through Git and CI/CD.
Emergency hotfixes: Use Change Sets for critical production fixes that can't wait for CI/CD pipeline. Document these deployments carefully.
Admin changes: Let admins use Change Sets for simple config changes (validation rules, page layouts, fields). Pull these into Git periodically.
Major releases: Use SFDX for planned releases with full testing, rollback plans, and deployment automation.
Third-party integrations: Use SFDX to version-control integration components. Makes troubleshooting easier when integrations break.
Making Hybrid Work:
Establish clear rules on when to use each method
Sync Change Set deployments into Git after deployment
Use separate sandboxes for SFDX vs Change Set work
Train team on both approaches
Monitor what gets deployed via each method
Gradually migrate to SFDX as team matures
Migrating from Change Sets to SFDX
The Reality of Migration
Organizations currently using Change Sets who want to switch to SFDX face a significant undertaking. Migration requires planning, training, infrastructure setup, and gradual adoption over months, not weeks.
Migration Steps:
Set up Git repository and retrieve production metadata using SFDX CLI
Establish branching strategy (main, develop, feature branches)
Set up CI/CD pipeline basics (GitHub Actions, Jenkins, etc.)
Train team on Git basics, SFDX CLI, and source-driven workflow
Start with new development in SFDX, keep Change Sets for existing work
Gradually migrate existing sandboxes to SFDX source tracking
Document deployment processes for both methods during transition
Phase out Change Sets once team is comfortable with SFDX
Maintain emergency Change Set access for critical hotfixes
Common Migration Pitfalls:
Trying to migrate everything at once - gradual migration works better
Not training team before switching - expect 2-3 months of lower productivity
Assuming SFDX solves all problems - it introduces new complexities
Not documenting the process - institutional knowledge gets lost
Expecting immediate ROI - benefits come after initial investment period
Forcing SFDX on non-technical admins - keep Change Sets available for simple tasks
Decision Framework: Which Should You Use?
Key Questions to Consider:
How many developers?
1-3 → Change Sets probably fine
4-10 → SFDX worth considering
10+ → SFDX essential
How often are deployments?
Monthly or less → Change Sets acceptable
Weekly → SFDX recommended
Daily → SFDX required
Is deployment history required?
Nice to have → Change Sets with manual docs
Required for compliance → SFDX with Git
What is team composition?
Mostly admins → Change Sets
Mixed admins/developers → Hybrid
Mostly developers → SFDX
Is DevOps infrastructure available?
No Git, no CI/CD → Change Sets
Git but no CI/CD → SFDX manual deployments
Full pipeline → SFDX automated
What is org complexity?
Simple (few objects/fields) → Either works
Moderate complexity → SFDX helps with organization
High complexity (1000+ objects) → SFDX essential
Is rollback capability needed?
No → Either works
Yes → SFDX with Git history
The Honest Assessment
Neither Method Is Perfect
Change Sets are simple but don't scale. SFDX scales but requires investment. The "right" choice depends on team size, org complexity, deployment frequency, and technical capability. Internet opinions shouldn't pressure teams into SFDX if Change Sets work for their situation. Conversely, sticking with Change Sets because "that's how it's always been done" fails when teams grow to 15 developers deploying daily.
Practical Starting Points:
Small team, simple org, infrequent deploys → Change Sets are sufficient
Growing team, increasing complexity → Plan SFDX migration
Large team, frequent deploys → Invest in SFDX infrastructure
Mixed technical capability → Use a hybrid approach
Legacy org with years of Change Sets → Gradual migration, not big bang
The Strategic Reality:
Deployment method is not just a technical decision - it's strategic, affecting team productivity, deployment reliability, and long-term maintainability. The cost of switching from Change Sets to SFDX is real (training, infrastructure, productivity dip), but so is the cost of staying on Change Sets when the team and org have outgrown them (deployment errors, lack of version control, manual overhead).
The decision should consider not only your current setup, but also how your team and org are expected to grow. A 3-person team today might be 10 people in a year. An org with 50 custom objects today might have 500 next year. Choose the approach that scales with growth, or plan migration before hitting the breaking point.
Both Change Sets and SFDX work - the question is which one works better for the specific context. Make informed decisions based on actual needs, not theoretical best practices. And whatever approach is chosen, document deployments, test before deploying, and always have a rollback plan. That matters more than the tool itself.
