Skip to content

Thoughts about disabling classic pipelines in Azure DevOps

Reading Time: 4 minutes

In this post I want to share my thoughts about disabling classic pipelines in Azure DevOps. Which I know there are mixed feelings about.

In addition, I want to raise awareness that this is now possible. Due to the fact that towards the end of January Microsoft announced that you can now disable creation of classic pipelines in Azure DevOps.

In other words, you can now disable the use of the GUI-based Classic Editor and the Releases features in Azure Pipelines. Like the Classic Editor example shown below.

Classic Editor example
Classic Editor example

Which means that if this setting is enabled your only option is to work with YAML pipelines. In other words, a pipeline consisting of code. For example, the above GUI-based pipeline would be the below YAML code instead.

 - task: PowerShell@2
   targetType: 'inline'
   script: |
       # PowerShell to extract contents of a database in a serverless SQLPool into a dacpac file
 SqlPackage /Action:Extract /TargetFile:$(Build.ArtifactStagingDirectory)\$(TargetFile) /p:VerifyExtraction=true /SourceServerName:$(SQLPoolEndPoint) /SourceDatabaseName:$(SourceDB) /SourceUser:$(SQLPooluser) /SourcePassword:$(SQLPoolpw)

 - task: PublishBuildArtifacts@1
 displayName: 'Publishes dacpac as an artifact'
  # Publishes the dacpac as part of an artifact within Azure DevOps
          PathtoPublish: '$(Build.ArtifactStagingDirectory)'
          ArtifactName: $(SQLPoolartifactname)
          publishLocation: 'Container'

Anyway, you can select this setting at either the organization level or the project level. However, I suspect after reading the advantages of YAML pipelines in the official announcement more people will be keen to change the setting at an organization level.

Disabling classic pipelines in Azure DevOps within the organization settings
Disabling classic pipelines in organization settings

Personal thoughts about disabling classic pipelines in Azure DevOps

I do think that this setting is long overdue. Because there are a lot of advantages to working with YAML pipelines.

Plus, I am glad that Microsoft listed some of the advantages to YAML pipelines in their announcement. Because I have been asked in the past if there is anything in black and white from Microsoft relating to this.

Especially when alternative offerings only offer YAML as an option. For example, there is no GUI-based option when working with GitHub Actions.

Now, I know a lot of people are keen to keep using the classic pipelines. I fully understand that people do not want to learn how to work with YAML pipelines for one reason or another.

Especially in the data platform community. Where professionals want to focus on working with data instead of learning the Azure Pipelines YAML schema.

Microsoft offers help in this area. In addition to providing a lot of documentation about the YAML schema they also share a guide on how you can migrate your Classic pipeline to YAML.

In addition to the benefits listed in the official announcement there is one other thing like I like about them. Which is that they are a lot more portable than classic pipelines.


For example, if I move a Git repository I can setup the same YAML pipeline again by creating a new pipeline in Azure Pipelines and pointing it to an existing YAML file. Like I show in my post on how to connect a database project in Azure Repos to Azure Pipelines.

Sure, if I move to a new project I might have to recreate variable groups and service connections. But I still think that it is a lot easier to select a YAML file than all the clicking and copying required to manually recreate classic build and release pipelines.

Plus, I can share YAML pipelines in GitHub repositories so that anybody can download them. Like I did for my last post about my homemade serverless SQL Pool Database Project. As you can see below.

My AzureDevOps-ServerlessSQLPool-HomemadeDBProject repository that contains a YAML pipeline
My AzureDevOps-ServerlessSQLPool-HomemadeDBProject repository that contains a YAML pipeline

I do think that classic pipelines can be good for demos. In fact, now and again I do cover how to use both types of pipelines in my posts.

Like I do in my post about deploying a dacpac to a serverless SQL pool. However, some of you might have noticed that I tend to cover working with YAML pipelines more.

Infrastructure as Code

I personally think that if you are working with classic pipelines you are not truly working with Infrastructure as Code. Because you are still using a GUI-based method. I know others think differently, and that is perfectly fine.

However, it can lead to some interesting discussions within larger enterprises. Depending on what has been stated in your architecture principles. Because they can be open to interpretation.

Final words about disabling classic pipelines in Azure DevOps

I hope this post about my thoughts about disabling classic pipelines in Azure DevOps has raised awareness about the fact that it is now possible. Plus, given some of you food for thought.

I know there are mixed feelings about this already. Due to some feedback that I have already received. Which is to be expected since everybody is different and we all think differently.

You are more than welcome to share your own views with a comment in this post.

Published inAzure DevOps


  1. I love the Azure DevOps classic pipelines GUI. It’s the main reason why I prefer it over competitive pipeline tools.

    I do understand the argument for pipelines as code thing, but I don’t see a reason why this should entirely replace the GUI.

    I consider it completely reasonable to do your INITIAL pipeline development using GUI, and then when you need to clone it or something then you convert it to YAML.

    In other words: why not both?

    • Kevin Chant Kevin Chant

      It is a good idea. One thing I have suggested recently is to develop the classic pipelines in a separate organization first and than migrate a YAML version to the working organization.

  2. Atanu Atanu

    Still will vote for the GUI interface. YAML based is OK… but the GUI still gives the confidence and ease. MS should keep both ?

  3. Kevin Kevin

    The Classic Editor provides more control and ease of us. A pipeline should not be treated as code along with your code base. Forcing YAML is just not the solution. Thankfully, it seems Microsoft is going to continue allowing the best solution to those who want to/continue using Classic.

    As for GitHub Actions not having a GUI. So what? There’s a reason they’re separate, it’s because they are different. If Microsoft wants to have just one option, then merge them into one and discontinue supporting both. There’s no reason Azure DevOps should take a substantial hit in flexibility/control just because GitHub Actions lacks something.

    There are times when things are more complicated and they get pushed just so some folks can feel superior. YAML comes off as one of those things.

    Apparently I’m more passionate about Classic vs YAML than I thought!! haha

Leave a Reply

Your email address will not be published. Required fields are marked *