Moving a Classic release pipeline to YAML does not automatically remove the Classic definition or its run history. Azure DevOps treats the new YAML pipeline and the old Classic pipeline as separate objects; release records may also remain under retention rules. First identify what is still visible, then decide whether to retire a definition or adjust retention.
What is still showing: a definition, a release, or a deployment?
Azure DevOps uses several related terms for different things. A pipeline definition describes how work is configured; a release is a versioned set of artifacts and settings; a deployment is the execution of tasks for a stage. One release can be deployed more than once. Microsoft explains these distinctions in its Classic release overview.
- Classic release pipeline: The configuration or definition that remains available to create and run releases.
- Release: A specific record with its artifacts and settings.
- Deployment: A run of stage tasks associated with a release.
- Deployment group: A collection of target machines used by Classic release pipelines.
If the old item is a Classic definition, its continued presence does not by itself mean the old deployment path is running. If it is an individual release, retention rules—not the YAML cutover—are likely governing how long the record remains.
Why does the Classic pipeline remain after moving to YAML?
Conversion creates a separate YAML pipeline; it does not overwrite or delete the Classic one. Microsoft’s Classic-to-YAML migration guide says the result is two pipelines: the new YAML pipeline and the original Classic pipeline, which can then be retired. The Classic pipeline’s run history remains with that Classic pipeline.
#1 Best Overall
Classic release definitions are not exported to YAML in one step. Microsoft says each task must be exported individually, so migration involves translating and validating the configuration rather than pressing a conversion button that replaces the source definition.
Why do old release records remain visible?
Release retention controls the lifetime of release records. In Azure DevOps Services, review Project settings > Pipelines > Release retention. The days-based timer resets when a release is modified or deployed to a stage, and a configured minimum number of releases takes precedence over the days setting. Deleted releases can also remain until the configured permanent-destruction period expires. See Microsoft’s release retention guidance.
Services and Server do not expose all retention controls in the same way. In Azure DevOps Services, global defaults and maximums can be viewed from the project page but not changed there. Azure DevOps Server supports project-level release defaults and maximums, as well as collection-level retention controls for Classic build pipelines. Confirm which deployment you use before changing policy; do not assume a Server setting is available in Services.
How to check what remains before retiring Classic
- Identify the object. Determine whether the item is a Classic release definition, an individual release, a deployment record, or a deployment group. Their lifecycles differ.
- Confirm YAML is the intended deployment path. Verify the replacement’s tasks, artifacts, variables, triggers, approvals, target environments, and permissions. Treat these as parity checks; creating a YAML pipeline does not establish that every Classic setting transferred.
- Review retention. Check both the days rule and minimum release count, and account for the timer resetting after a release is modified or deployed.
- Preserve required records. Before retiring the old definition, retain any run history or release records needed for audit, compliance, or operational reference.
- Retire deliberately. Once the replacement is confirmed and required records are preserved, an owner can retire the Classic definition. Cutover does not provide a universal automatic deletion step.
What needs particular attention during migration?
Variables and schedules
Microsoft flags Classic UI variables that need to be redefined in YAML or pipeline settings. Schedules also need review: YAML uses UTC by default, whereas Classic schedules use the organization’s local time zone. A schedule can therefore run at a different local time unless its intended timing is translated carefully.
Rank #3
Deployment groups and YAML environments
Classic deployment groups do not automatically become YAML environments. Deployment groups are for Classic release pipelines; YAML uses deployment jobs and environments. Microsoft’s guidance on deployment groups and YAML environments describes the separate models. Inventory target machines, agent dependencies, and permissions when planning the new deployment path.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Which migration approach fits?
| Approach | Best fit | Trade-off to plan for |
|---|---|---|
| Keep Classic temporarily | A staged cutover where the YAML path still needs validation. | Both definitions remain; make clear which path is approved for active deployments. |
| Translate release tasks into YAML | A team moving deployment configuration into version control and a review workflow. | Tasks and settings require deliberate translation and validation; deployment groups, variables, schedules, approvals, and permissions need attention. |
| Clone or import a Classic definition | Reusing a Classic pipeline in another project rather than converting it to YAML. | Microsoft says cloning copies settings but not security; security must be configured again. See its Classic release clone and import guidance. |
Choose based on how much translation the release tasks require, the desired version-control and review workflow, the target model, approvals and permissions, and whether Classic history must remain accessible.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
