The right deployment tool depends on what you are moving and where. For ad-hoc changes between related sandboxes, Change Sets are quickest. For repeatable, version-controlled deployments, use the Salesforce CLI. For production, validate first, then deploy.
- Choose the right tool
Related sandboxes and one-off changes: Change Sets. Git-backed source and CI: Salesforce CLI (sf project deploy start). Enterprise teams with multiple developers and approval gates: a third-party DevOps platform such as Copado, Gearset, Flosum, or AutoRABIT.
- Build or identify the deployment payload
For a Change Set, add components in the source org's Outbound Change Sets. For the CLI, ensure your project metadata reflects the changes; use sf project retrieve start to pull from an org or git diff against the upstream branch.
- Run a validation against production
Before deploying to production, run sf project deploy validate --target-org production --tests RunLocalTests, or use the Validate button on an inbound change set. Read the result carefully; the same code that passes in sandbox can fail in production due to data or test-class differences.
- Schedule the deployment window
Production deployments lock metadata edits while they run. Schedule outside business hours when possible. If validation succeeded within the past 4 days, you can do a Quick Deploy from the same payload, which skips re-running tests.
- Run the deployment
From the CLI, sf project deploy start --target-org production. From the Setup UI, open the inbound change set and click Deploy. Monitor progress at Setup, then Deployment Status. Errors fail the entire payload; the org is left in its pre-deployment state.
- Validate post-deploy behavior
After a successful deployment, run smoke tests on the affected flows, classes, and pages. If something looks wrong, prepare a rollback (re-deploy the previous version from Git or a saved metadata snapshot). Document the deployment in your change log.
UI-based, sandbox-to-related-sandbox only. No version control, no automation. Best for small, ad-hoc changes.
The modern default. Git-aware, scriptable, supports validation and quick deploy. Suitable for individual developers and CI pipelines.
Direct API calls for custom tooling. Used by third-party DevOps platforms under the hood.
Copado, Gearset, Flosum, AutoRABIT. Wrap the Metadata API with merge management, approval workflows, and rollback features. Best for large teams and regulated industries.
- Production deploys require Apex tests at 75 percent overall coverage and a 100 percent pass rate. A test that passes in sandbox can fail in production if it depends on data that does not exist or on a configuration difference.
- Profile XML deploys are partial: only grants for objects and fields in the same deployment are written. Including just the profile without the referenced metadata produces unexpectedly incomplete grants.
- Quick Deploy is only available within 4 days of a successful validation. After 4 days, you must validate again. Mark the validation expiry in your change log.
- Production deploys lock metadata edits during the deploy window. If anyone tries to save a Flow or class in production while a deploy runs, they get a locking error. Communicate the window.