Deploying to Salesforce without breaking everything: Change Sets, SFDX and good practices

Deployment is the most dreaded phase of a Salesforce project. Not because it is technically complex, but because it concentrates every risk built up during development, and a mistake here hits real production.

I have seen deployments stall for hours because a validation rule was left out of the Change Set. I have seen data migrations fail silently because the target field did not exist in production yet. Here is what I have learned to do every single time.

Change Sets vs SFDX: understanding what you are choosing

The classic mistakes, and how to avoid them

Deploying straight from Dev to Production

This is mistake number one. A development sandbox never looks exactly like production: the data is different, profile configurations can drift, and customisations made directly in production (yes, that happens) are not in the sandbox.

The correct chain: Dev → Full Sandbox (or Partial) → UAT/Staging → Production. Each stage filters out problems that would not have surfaced in the previous one.

Forgetting dependencies in the Change Set

A custom field on a standard object depends on another field, on a record type, on a validation rule. Leave one component out of the Change Set and a deployment error is guaranteed.

Salesforce checks some dependencies automatically, but not all of them. The habit to build: always deploy to the Full Sandbox before production, and confirm everything works before going any further.

Ignoring code coverage

Salesforce requires 75% Apex code coverage for a production deployment. That threshold is often scraped through with tests that do not really test the behaviour of the code, only its coverage.

Tests that cover real scenarios (bulk, errors, edge cases) prevent regressions after deployment. Tests written just to hit the coverage number give a false sense of safety.

Having no rollback plan

Salesforce gives you no way to "undeploy" a Change Set. If a deployment causes trouble, rolling back means either a new corrective deployment or deleting the added components by hand.

Before every significant deployment: document the pre-deployment state, list the components being changed, and define the rollback procedure in case something goes wrong.

The checklist before every production deployment