Moving Azure DevOps release pipelines to Argo CD: what the move involves
Consider a team whose Azure Pipelines release stages build an image, then run kubectl or Helm steps against an AKS cluster using a stored service connection and pipeline secrets. The move replaces those push deployments with pull-based reconciliation: Argo CD watches a repository in Azure Repos, compares it with the cluster, and applies the difference from inside the cluster. The effort depends on how many release stages, environments, clusters and secret variables exist, so no fixed duration can be stated until someone has inventoried them. Start by listing every stage, its target namespace, the service connection it uses, each variable group and the Key Vault links behind it.
Argo CD is released under the Apache License 2.0 (SPDX: Apache-2.0) and has no paid edition from the project itself, so the cost of the move is labor, infrastructure and ongoing operation, not licensing. Azure DevOps costs remain whatever your organization already pays for Azure Repos, Azure Pipelines and agents, and those costs continue for any pipelines that still build images. Ask any partner for a quote built from the written inventory, and separate one-time work (repository layout, cluster registration, cutover) from recurring work (upgrades, patching, access reviews).
The work has three parts: planning, configuration and cutover. Planning decides the repository layout, environment promotion by pull request and which approvals move from pipeline gates to pull request reviews. Configuration covers repository credentials, webhooks, AKS access through workload identity and Argo CD projects. Cutover moves one stage or environment at a time while the old release stage is disabled, so that no two systems reconcile the same resources. Confirm the Azure DevOps and Argo CD versions you will run, and check each stage against your own change control rules before scheduling anything.
Which Azure Pipelines release capabilities map to Argo CD and which do not
This table compares the release features of Azure Pipelines with their closest Argo CD equivalents, so you can see what carries over, what changes shape and what has no direct counterpart. Read each row as a question about your current pipeline: if the capability is central to how you release, plan for the replacement before cutover. The main takeaway is that Argo CD replaces the push step and the state held in pipeline definitions, but approvals, secret retrieval and some gates move into Git, the cluster or add-ons that you must confirm.
| Azure Pipelines capability | Argo CD equivalent | Status |
|---|---|---|
| Release stages that run kubectl or Helm against AKS | Argo CD Applications that pull desired state from an Azure Repos path and reconcile it | Mapped, but the deploy action moves from the pipeline to the controller |
| Classic release pipelines and task groups | No equivalent object. Rebuild steps as manifests, Kustomize overlays or Helm values in Git | No direct equivalent |
| Variable groups with plain values | Values committed in the config repository per environment, or Helm and Kustomize parameters | Mapped, but values become reviewable Git content |
| Variable groups linked to Azure Key Vault | Secrets pulled by an operator or external secrets controller on the AKS cluster, not by Argo CD itself | Needs add-on, confirm the operator and its Key Vault access model |
| Service connections to AKS and Azure Container Registry | Cluster registration with credentials scoped by Argo CD projects, plus AKS workload identity for the controller | Mapped, confirm identity setup for your AKS cluster |
| Pre-deployment approvals and gates | Pull request review, branch protection and Argo CD sync windows for timing | Partly mapped, gates that query external systems need a separate check |
| Deployment history and rollback to a prior run | Git history of the config repository and Argo CD revision history, with rollback by Git revert | Mapped, rollback runs through Git rather than a release button |
| Secret variables masked in logs | Argo CD redacts cluster, Git and OAuth2 credentials from API responses and logs, but application secrets must stay out of Git | Partly mapped, confirm your secret handling before cutover |
Documented import paths and export sources for the move
The move has four inputs: the new source of truth in Azure Repos Git, the Argo CD resources that replace release stages, the repository Secrets Argo CD reads, and exports of what Azure DevOps runs today. No automated converter from release pipelines to Argo CD is assumed, so each piece is built and checked by hand against the current cluster state.
Azure Repos Git as source of truth
Azure Repos Git becomes the repository Argo CD watches, so the desired state for each AKS namespace lives in a commit history your reviewers already use. Decide the repository layout first: one config repository per team, or one shared repository split by environment folder. Confirm that the Azure Repos branch policies, required reviewers and build validation you plan to rely on are available in your organization's plan and settings.
Application and ApplicationSet resources
Each release stage that deployed to one AKS cluster maps to an Argo CD Application that points at a path in the config repository and a destination cluster. Where the same workload runs in several environments, an ApplicationSet generates those Applications from one template instead of copying stage definitions by hand. Record which stage variables become Helm values or Kustomize overlays so no environment setting is lost in translation.
Repository Secrets for Azure Repos
Since Argo CD 3.0, repository definitions live in Kubernetes Secrets rather than the argocd-cm ConfigMap, so each Azure Repos URL needs its own Secret with the credential type your Azure DevOps setup supports. Inventory every repository the Azure Pipelines YAML and classic release definitions currently read, including shared template repositories. Check each credential's scope and expiry before the first sync, because a single missing repository breaks every Application that references it.
Azure DevOps YAML pipeline exports
Export every YAML pipeline definition from the Azure DevOps project, including the templates it extends, so you can see which deployment steps call kubectl, helm or az aks and which variables they set. Treat this export as the inventory of what must be replaced, not as input to Argo CD. Mark each stage as a deployment to AKS, a build step that must stay in Azure Pipelines, or a step with no GitOps equivalent that needs a design decision.
Classic release pipeline and REST inventory
Classic release pipelines, task groups and deployment groups are not stored in YAML, so pull their definitions through the Azure DevOps REST API or the portal and record stage order, approvals, gates and variable groups. Microsoft's default setting disables creating new classic pipelines in newer organizations, so older releases may be the least documented part of the estate. Confirm with your Azure DevOps administrator which export method your organization permits before the inventory begins.
Third-party converters and their checks
No automated converter from Azure Pipelines release definitions to Argo CD is assumed in this plan, and the mapping is written by hand from the inventory. If a vendor or open-source tool claims to convert these pipelines, ask it to show the generated Applications for one stage, the secrets it expects in the cluster, and what it does with approvals and variable groups. Confirm its license, maintenance status and support terms with the vendor before any output reaches a production repository.
Sequence for inventory, pilot, parallel run, cutover and decommission
This sequence moves each Azure Pipelines release stage to Argo CD in controlled steps, so every namespace has one controlling deployment path at any moment and the old path is removed only after the new one has proven itself. It produces an inventory, a tested config repository, a pilot in a non-production stage, and an auditable cutover record for each environment.
Inventory every release stage and dependency
Your team lists each release stage in every Azure Pipelines release definition and YAML pipeline that deploys to AKS. For each stage, record the target cluster and namespace, the service connections it uses, the variable groups and secret variables it reads, the approval gates and their approvers, and any deployment tasks that run kubectl or Helm. Note which secrets are linked to Azure Key Vault and which are stored only in Azure Pipelines. Confirm the list with the people who approve releases, because approvals often exist outside the YAML. Done when every stage has one inventory row and every row names an owner.
Design the config repository layout
Your platform and application teams agree on a repository structure that separates application source, rendered or templated manifests, and environment-specific values. Decide where image tags are updated, who can merge to the production path, and how branch protection on Azure Repos Git maps to Argo CD's sync source. Keep secrets out of this repository and plan how they will reach the cluster. Done when a reviewer can point to the Git path, branch and pull request policy used by each environment, and the layout has been reviewed against the inventory.
Stand up Argo CD and repository access
Your platform team installs Argo CD on a cluster you control, enables SSO, and defines the Azure Repos repositories as Kubernetes Secrets, since repository configuration no longer lives in argocd-cm. Create a read-only credential for Argo CD to clone the config repository, and configure a webhook from Azure Repos so pushes trigger a fast refresh. Confirm the webhook secret and the credential scope with your Azure DevOps administrators. Done when Argo CD shows the repository as connected and a test push to a sandbox path refreshes the expected application within the webhook path, not only on the polling interval.
Pilot one non-production stage
Choose one non-production release stage with a low blast radius and create an Argo CD Application for it that points at the new config repository path. Keep the Azure Pipelines stage running for that namespace until the pilot is verified, but remove its deploy step from the pipeline's trigger path only after the Argo CD sync is confirmed. Run a planned change through a pull request, check sync status, health, and rollback by reverting a commit. Done when the pilot has completed a full change and a rollback, and the team has written down every manual step it still needed.
Run both paths with one owner per namespace
Keep Azure Pipelines and Argo CD running side by side, but assign each namespace to exactly one controller. Record the owner in the inventory and in the Argo CD Application definition, and disable automated sync or pipeline deploy steps on the path that does not own it. Check that no Azure Pipelines run and no Argo CD Application writes to the same resources, because two controllers reconciling one object produce drift. Review the ownership table weekly with the release approvers. Done when the ownership table matches the live cluster and no namespace has two active writers.
Cut over each environment in order
Move environments one at a time, starting with the least sensitive and ending with production. For each environment, freeze pipeline releases, confirm the Argo CD Application reflects the current running state with no unexpected diff, transfer ownership in the inventory, and make the first production change through a pull request with the approvals that the old pipeline required. Keep the previous pipeline definition available so the team can revert ownership quickly. Done when the environment's first Argo CD-driven release has passed its health checks and the approval record for it is stored in Azure Repos and the Argo CD audit history.
Disable pipeline deploy rights and remove service connections
After every environment has run on Argo CD for an agreed period, remove the deploy stages from the Azure Pipelines definitions, disable the classic release pipelines if any remain, and revoke the service connections and their Azure identities from AKS. Remove unused variable groups and secret values that no longer reach a running deployment. Confirm with Azure DevOps administrators which service principals and workload identities are retired. Done when no pipeline can deploy to the AKS clusters, the service connections are deleted, and the decommission record lists each credential removed and who confirmed it.
What drives the cost and duration of the migration
This table compares the factors that change the size of an Azure DevOps to Argo CD move, and separates one-time migration work from the recurring cost of running Argo CD. Use it to see which inputs your quote should be built on, and to check that each driver appears in the written scope before work starts.
| Driver | Why it changes cost or effort | What to ask for or confirm |
|---|---|---|
| Release stages and environments | Each stage that deploys to AKS becomes an Argo CD Application or ApplicationSet entry with its own sync policy, and each needs a cutover step. | A list of every stage, its target cluster and namespace, and whether stages share manifests. |
| Service connections and variable groups | Azure Resource Manager and Kubernetes service connections must be replaced with cluster access that Argo CD uses, and each variable group must be mapped to a config source or secret store. | A full inventory of service connections, variable groups and which pipelines reference them. |
| Key Vault links | Variable groups linked to Azure Key Vault fetch secrets at run time, so the replacement needs an agreed secret delivery path that keeps values out of Git. | Which vaults are linked, how many secret names exist, and who owns secret rotation after cutover. |
| AKS cluster count and access model | Each cluster needs a registered identity for Argo CD, workload identity configuration, and separate verification, so cost grows with cluster count. | Number of AKS clusters, whether they share a network, and the planned Azure identity model for Argo CD. |
| Helm or Kustomize usage | Charts and overlays already rendered in pipelines must be moved into repository layouts that the repo-server can build, which often requires value file cleanup. | Counts of Helm charts, Kustomize overlays and inline scripts that edit manifests during release. |
| Approval chains moving to pull requests | Manual approval gates become branch protection, required reviewers and environment promotion by merge, which needs policy design with the approvers. | The current approval matrix per environment and which roles must approve each promotion. |
| Number of teams | Each team needs its own repository access, Argo CD project boundaries and SSO group mapping, and each adds review and training effort. | Team count, existing Azure DevOps project structure, and who will own each application after handover. |
| Recurring Argo CD operation | Upgrades, patch releases, SSO maintenance, backup checks and on-call support recur for as long as Argo CD runs, and the cost depends on the support model chosen. | Whether support is a retainer or an as-needed arrangement, the upgrade cadence agreed, and who receives alerts. |
How the parallel run keeps one controller per namespace
During the parallel run, Azure Pipelines and Argo CD must never both write the same AKS resources. If a release stage still runs kubectl apply or helm upgrade against a namespace while Argo CD is syncing it, each tool will reconcile the other's changes, and the result is drift that looks like a regression. The safe pattern is to assign every namespace or Argo CD Application to exactly one owner at any moment. Write that assignment down per environment before the first sync, and make it a reviewed artifact in the config repository, not a convention remembered by the release team.
Enforce the split on both sides. On the pipeline side, the service connection and the workload identity used by the release stage should be limited to the namespaces still owned by Azure Pipelines, so that a stale stage fails with an authorization error instead of silently applying. On the Argo CD side, set the destination namespaces and cluster resource allowances on each AppProject so that Applications can only sync into the namespaces they have been handed. Confirm both controls with a test: attempt a deploy from a migrated namespace in the old pipeline and a sync into an unmigrated namespace from Argo CD, and check that both are refused. The exact permission model depends on how your Azure RBAC and Kubernetes RBAC are bound, so confirm it in your own cluster rather than assuming it.
Set the cutover order per environment, starting with the lowest-risk environment and moving toward production. Within an environment, move namespaces in dependency order, with shared services such as ingress configuration or secrets references handed over before the workloads that depend on them. For each namespace, disable the pipeline stage first, let Argo CD take ownership and report Synced and Healthy, and only then remove the old stage from the pipeline definition. Record the handover in the pull request history so auditors can see when ownership changed. Because the config repository will hold deployment definitions, apply the guidance in the Argo CD security documentation on repo-server exposure: restrict who can change the repository, do not let Applications point at untrusted repositories, and remember that Helm and Kustomize run on repository content during manifest generation.
What usually goes wrong when release stages move to GitOps
Moving AKS release stages from Azure Pipelines to Argo CD usually fails at the seams between the two systems rather than inside either one. The cards below cover the risks that most often cause double deployments, leaked secrets, failed cluster access, stale syncs and lost approvals, each paired with the check to run before cutover.
Two systems deploying the same workloads
If the Azure Pipelines release stage and Argo CD both keep write access to the same AKS namespaces, each run can overwrite the other's changes and drift becomes hard to explain. Before cutover, disable the release stage's triggers, remove or disable the service connection that targets the cluster, and confirm that only the Argo CD controller applies changes to the migrated namespaces. Record which pipeline owned each namespace so the cutover order is explicit.
Secrets copied into Git or Argo CD
Pipeline secret variables and variable groups linked to Azure Key Vault often end up pasted into manifests, Helm values or repository credentials during the move. Azure Pipelines does not mask substrings of secrets in logs, so the same habit carries risk into Git history. Keep secret values in Key Vault or another external store, reference them from the destination cluster, and scan the config repository for credential patterns before the first sync.
Workload identity misconfigured for AKS
Argo CD's controller needs a working path to the AKS API, and a federated identity that is missing, mis-scoped or bound to the wrong service account will fail sync with access errors that look like unrelated RBAC problems. Confirm the issuer URL, subject, audience and role assignments on the identity, and test a read and a dry-run apply in each target namespace. Keep the cluster role narrow, because the controller's permissions define how far a bad commit can reach.
Webhooks missing, so syncs lag
Argo CD polls Git on an interval by default, so a release that used to start within seconds of a merge can wait noticeably longer after the move unless the Azure Repos webhook is configured. Set up the webhook with a shared secret, confirm that Argo CD receives push events for the config repository, and check that a test commit triggers a refresh. Document the polling fallback so a broken webhook does not silently stretch release times.
Approvals lost in the move to pull requests
Azure Pipelines environment approvals and checks often sat outside the repository, so they can disappear when promotion moves to pull requests. Map each approval to a branch policy on the config repository, require reviewers for production paths, and restrict who can merge to the branch Argo CD tracks. Test the policy with a real pull request so you know approvals are enforced, not just documented.
Classic release pipelines that do not export cleanly
Classic release definitions store stages, variables and task settings in the Azure DevOps UI rather than in source files, so a direct export often misses conditions, variable scopes and deployment group targets. Newer organizations may have classic creation disabled by default, which makes older definitions harder to inspect. Inventory every classic release, rebuild the intent as manifests or Helm values, and compare rendered output against the live deployment before retiring the pipeline.
Questions teams ask before moving Azure Pipelines to Argo CD
What does Azure Pipelines cost compared with running Argo CD?
Argo CD itself is open source under the Apache License 2.0, so the project charges no license fee. Your costs are the Kubernetes capacity to run Argo CD, the people who build and operate it, and whatever Azure DevOps spend continues for source control, build and test. Azure Pipelines pricing is set per parallel job: the Azure DevOps Services pricing page lists 1 free Microsoft-hosted parallel job with 1,800 minutes and 1 free self-hosted parallel job, then $40 per extra Microsoft-hosted parallel job and $15 per extra self-hosted parallel job per month. Ask your team to total the parallel jobs you use for release stages today, since that line is what the move can reduce.
How long does a move from Azure Pipelines to Argo CD take?
Duration depends on how many release pipelines exist, how many AKS clusters and namespaces they target, how many variable groups and service connections need replacing, and how many approval gates must be re-created as pull request rules. No duration is fixed by the Argo CD or Azure DevOps documentation for this work, so treat any single number as a placeholder until a written scope exists. A staged cutover, one application or environment at a time, usually takes longer than a single switch but keeps rollback simple. Ask for the timeline as a list of milestones tied to the pipelines in scope.
What does the work need from our team?
You need named owners for the Azure Repos configuration repository, the AKS clusters, the identity model and the approval policy. Plan time from people who know the current release stages, the variable groups linked to Azure Key Vault and the environments that require manual sign-off. Your platform team must agree on how Argo CD reaches Azure Repos, which credentials it holds and where the Argo CD instance runs. Expect reviews from security, because Argo CD's repo-server runs Helm and Kustomize on repository content, which makes repository trust a control point.
Can our team do the migration ourselves?
Yes, if you have engineers comfortable with Kubernetes, Helm or Kustomize, Azure Repos and Azure identity. The harder parts are usually not the Argo CD manifests but the decisions: how to split configuration repositories, which pipeline checks become pull request policies, and how to avoid two systems deploying the same resources during cutover. A partner can plan and implement this under a fixed written scope, or work alongside your team as a reviewer. Ask any partner to state what they will hand over, including runbooks and the configuration repository layout, so your team can operate the result.
How do approvals move from release stages to pull requests?
Approvals move into branch policies on the configuration repository. A release stage that waited for a named approver becomes a pull request that requires reviewers, with protected branches for each environment and promotion done by merging a change to the environment path. Azure Repos supports required reviewers and build validation for pull requests, which you can use for checks that used to run as stage gates. Record who may approve each environment, because Argo CD projects and RBAC can restrict which applications a given team may sync. Confirm the exact policy options in your Azure DevOps organization before finalizing the design.
How is AKS access set up with workload identity instead of stored credentials?
The goal is that Argo CD's controller authenticates to AKS with a federated identity rather than a long-lived kubeconfig or service connection secret. Create a managed identity or workload identity for the Argo CD application controller, grant it only the Kubernetes RBAC it needs in the target namespaces, and register the cluster through a Kubernetes-side configuration that matches your AKS setup. Argo CD's security documentation says it redacts cluster, Git and OAuth2 credentials from API responses and logs, which helps, but it does not replace limiting the identity's permissions. Confirm the current AKS workload identity steps with Microsoft's documentation and test them in a non-production cluster first.
What Azure DevOps costs remain after the move?
Some Azure DevOps costs usually remain, because Argo CD does not replace source control, work tracking or every pipeline. Repos and user licenses continue under the Basic plan, which the Azure DevOps Services pricing page lists as free for the first 5 users and then $6 per user per month, with Basic + Test Plans at $52 per user per month. Build pipelines that still run continue to consume parallel jobs at the rates above. Azure Artifacts costs begin after 2 GiB free, starting at $2 per GiB. Ask for a list of every Azure DevOps feature in use today so you can see which costs stop and which continue.
Does moving to Argo CD keep the Azure Pipelines approval trail for audits?
It can, if the Git history becomes the record. Each deployment becomes a commit with an author, a reviewer and a merge, and Argo CD shows the sync history for each application. Auditors will still want evidence that approvers were authorized and that changes matched what was reviewed, so plan how the pull request approvals, branch protection settings and Argo CD RBAC are exported and retained. Argo CD does not issue audit reports; independent auditors make that judgment, and DeployOpen prepares the systems, controls and evidence they test.
What stays in Azure DevOps and what the Azure DevOps bill still covers
Moving release stages to Argo CD does not remove Azure DevOps from the delivery chain by default. Continuous integration can stay in Azure Pipelines, and in many cases it should, because the build, unit tests and image publishing jobs still need an agent and a place to run. Before changing anything, list every pipeline and stage and mark which ones only deploy. Those are the candidates to retire. The rest keep running and keep billing, and the bill is driven by parallel jobs, not by the number of pipelines.
Azure Repos, user licensing and parallel jobs continue to cost money until someone changes them. The Azure DevOps Services pricing page lists one free Microsoft-hosted parallel job with 1,800 minutes and one free self-hosted parallel job, with extra parallel jobs charged per month. Basic access is free for the first 5 users and then charged per user. Removing release stages reduces demand for parallel jobs, but it does not remove the need for Basic users who still open pull requests or read boards. Ask your Azure DevOps administrator to export current parallel job and user counts, then confirm with Microsoft which seats and jobs are actually reduced after cutover. Also confirm whether the Azure Repos config repository will sit in the same organization, which affects both seat count and the webhook setup.
The new flow moves sensitive material into places you must document. Azure DevOps Services stores source code and work items in the geography you chose for the organization, but personal access tokens and SSH keys are stored in a US datacenter. Your Argo CD repository credentials will be a deploy key or token that Argo CD holds, so review where those credentials are created, rotated and revoked, and whether your data residency policy accepts that split. Confirm the data location for your organization in the Azure DevOps settings and record it in your change records before the first Argo CD repository is registered.
How DeployOpen works on this
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts and clusters. For an Azure DevOps to Argo CD move, we scope the release stages, AKS access and cutover order in writing before work starts, so your team knows what changes and what stays in place.
How we scope
- We inventory every Azure Pipelines release stage that deploys to AKS, including variable groups, service connections and approval gates.
- We map each deployment to a config repository layout in Azure Repos and agree which environments move first.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- We configure Argo CD repository credentials as Kubernetes Secrets and set up webhooks from Azure Repos for faster refresh.
- We set up AKS cluster registration and workload identity access, then test that Argo CD can sync only the intended namespaces.
- We move approvals into pull request review and test the promotion path against a non-production cluster first.
How we hand over
- We document the repository structure, Application and project definitions, RBAC mappings and the cutover runbook for your team.
- We run staged cutover with a written rollback plan for each namespace, and record which pipeline stages were retired.
- We confirm with your team and auditors which evidence of change approval they need, and how Azure DevOps audit logs are retained.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after handover.
- We can plan Argo CD version upgrades against the project's patch and minor release cadence, which your team confirms in its own environment.
- We can review access, secrets handling and webhook exposure on a schedule that your change process requires.
