Your team still has several Classic (UI-designer-based) release pipelines nobody wants to touch. What's the actual case for migrating them to YAML pipelines, and how would you approach it?

The core case is that Classic pipeline configuration isn't version-controlled — it lives only in the Azure DevOps UI, with no diff, no code review, no history beyond Azure DevOps' own internal audit trail, and no way to test a change in a branch before it affects the real pipeline. Migrate incrementally: recreate each Classic pipeline as YAML in a feature branch, run both in parallel to confirm equivalent behavior, then cut over one pipeline at a time rather than attempting to convert everything simultaneously.

The reason "nobody wants to touch" a Classic pipeline is itself the strongest argument for migrating it — configuration that's fragile and poorly understood because it's not in version control, has no code review history, and can't be tested in isolation is exactly the kind of technical debt that gets worse (not better) the longer it's avoided, since institutional knowledge about why it's configured a certain way erodes further over time.

YAML pipelines bring pipeline configuration under the same version control and review discipline as application code: changes go through a pull request, are diff-able, and have a full history explaining why a change was made — none of which Classic's UI-based configuration provides natively.

YAML pipelines are also inherently reusable via templates (see the related templates question), which Classic pipelines don't support in the same way — if you're also trying to reduce duplication across pipelines, staying on Classic works against that goal structurally.

Migration should be incremental, not big-bang: recreate one Classic pipeline as an equivalent YAML pipeline (in a separate, non-production-triggering branch or pipeline definition first), and run it in parallel against the same triggers as the Classic pipeline for a real observation period — comparing actual behavior and outputs, not just assuming the YAML conversion is functionally identical.

Document what each Classic pipeline actually does before converting it, especially for pipelines with unclear history: some Classic pipeline steps or task configurations may encode institutional knowledge nobody currently remembers the reason for — treating an unclear step as safe to drop during conversion risks quietly removing something that mattered, so investigating first (checking task configuration details, testing what happens if a step is removed in a non-production context) is worth the time for genuinely unclear cases.

Cut over one pipeline at a time, disabling the Classic version only after the YAML equivalent has been verified in parallel, rather than migrating and disabling simultaneously — this mirrors the same incremental, parallel-run migration pattern used for the Jenkins freestyle-to-pipeline-as-code migration, since the underlying risk (undocumented legacy configuration, hidden behavior) is the same class of problem.

• The core case for migrating off Classic pipelines is bringing configuration under version control, code review, and diff-able history — none of which Classic's UI-based configuration provides.
• "Nobody wants to touch it" is itself evidence the migration is overdue, not a reason to keep avoiding it — the risk of undocumented legacy configuration only grows over time.
• Migrate incrementally: recreate as YAML, run in parallel against real triggers, verify equivalent behavior, then cut over one pipeline at a time.
• Investigate genuinely unclear Classic pipeline steps before converting, rather than assuming they're safe to drop — they may encode institutional knowledge nobody currently remembers.

• Azure Pipelines: Migrate from Classic to YAML