What are the limitations of change sets, and how would you make the case for moving off them?

The technical limitations are specific enough to list, which is what makes the case land: change sets are manual, so they are assembled by hand for every target org; they are additive only and cannot delete components; they cannot be version-controlled, reviewed as a diff, or automated; and they only work between orgs in the same deployment lineage, so they cannot reach a customer org or a separate production org.

I make the case with consequences rather than features. Manual assembly means the release that passed in staging is not provably the same release that went to production. No deletions means an ever-growing tail of obsolete metadata and a manual checklist. No version control means no answer to "what changed and who approved it", which is the question governance forums actually ask.

I would not propose ripping them out on day one. I would make the pipeline the default path, keep change sets available for genuine emergencies, and impose one rule: anything deployed by change set is reconciled back into the repository within a defined window. That keeps the source of truth true while the habit changes.