Three main paths, plus a few specialised tools.
Change Sets — the classic point-and-click. You build an Outbound Change Set in the source org, add metadata components, upload it, and a matching Inbound Change Set appears in the target. You validate, then deploy. Pros: fully GUI, no extra tooling. Cons: slow, error-prone for missing dependencies, no real version control (you can't diff a change set), limited to deployment connections between linked orgs.
Salesforce DX with metadata API / SF CLI — script sf project deploy start from a Git-tracked source folder. You can review diffs in PRs, run validations against any sandbox, and deploy with a tested metadata set. This is the modern professional baseline. Pros: version control, automation, scriptable. Cons: requires team buy-in and a CI/CD setup.
Managed/Unmanaged Packages — for distributing reusable components, especially across unrelated orgs. Less common for internal deploys but the right answer for ISVs and internal libraries.
DevOps platforms — Gearset, Copado, Salto, AutoRABIT, Flosum. They wrap the metadata API with diffing, conflict detection, scheduled releases, rollback, and analytics. Worth using once team size and release cadence outgrow plain DX.
How to pick:
- One admin, occasional changes, no Git -> Change Sets are fine.
- Team with developers, regular releases -> SF CLI plus Git is the floor.
- Multiple environments, frequent releases, regulated change management -> DevOps platform.
Regardless of tool, the workflow rule of thumb is: changes start in a Developer or Developer Pro sandbox, get tested in a Partial Copy or Full sandbox with realistic data, get a final smoke in a UAT/staging sandbox if you have one, then deploy to production during a low-traffic window with a validated rollback plan.
A common gotcha: not every metadata type deploys cleanly. Profiles are notoriously painful — they often need manual edits in production after deployment because the metadata only includes the bits the change set touched. Activated Approval Processes must be deactivated before redeploy. Standard Picklist values are not deployable via change sets and must be replicated by hand.