DevOps & Infrastructure

Bicep vs Terraform in 2026: Which to Choose for Azure

By Falak MahmoodMarch 5, 20262125 views

Two years ago the Bicep-vs-Terraform conversation was easier: Terraform won on ecosystem, Bicep on Azure-native ergonomics. In 2026 the picture is more nuanced. Bicep closed most of the tooling gap, Terraform's licensing story is stable, and the OpenTofu fork has given Terraform users more options. This is an honest comparison aimed at teams making the choice for a new Azure workload, or reconsidering an existing one.

Already leaning Bicep? Our follow-up covers the practical move: Migrating from Terraform to Bicep on Azure, including state handling, coexistence patterns and CI/CD changes.

Summary

  • Azure-only, small-to-mid team, no multi-cloud ambition. Bicep is simpler, cheaper to operate, and ergonomically tight with Azure.
  • Multi-cloud or heavy third-party integration. Terraform (or OpenTofu) keeps paying for itself through the ecosystem.
  • Large platform team with existing Terraform investment. The migration cost is rarely worth it.

State Management

The single biggest operational difference. Terraform keeps an explicit state file, which is powerful (drift detection, plans, targeted operations) and burdensome (state corruption, remote state locking, sensitive values leaking into state). Bicep is stateless from the user's perspective. It computes the desired state from ARM's view of the live resources. Bicep users never manage a state file; they also never have a tidy list of destroy-ready resources.

Provider and Resource Coverage

Bicep gets day-zero coverage of new Azure services through ARM. Terraform's AzureRM provider lags by weeks for some services and has historical inconsistencies in resource naming. For bleeding-edge Azure features, Bicep wins. For anything outside Azure. DNS providers, Cloudflare, GitHub, third-party SaaS. Terraform is where the modules live.

Module Ecosystems

  • Terraform has the larger public module registry. The quality varies; the surface area is unmatched.
  • Bicep's AVM (Azure Verified Modules) has matured meaningfully, with Microsoft-curated modules for common resources. For Azure-only teams, this is often sufficient.

Syntax. Matters More Than It Should

Bicep reads cleaner than HCL for Azure resources. It has stronger type inference, nicer error messages, and an editor experience that feels like writing TypeScript for infrastructure. Terraform's HCL is more mature but shows its age on complex modules.

// Bicep
resource storage 'Microsoft.Storage/storageAccounts@2023-05-01' = {
  name: 'st${uniqueString(resourceGroup().id)}'
  location: location
  sku: { name: 'Standard_LRS' }
  kind: 'StorageV2'
  properties: {
    minimumTlsVersion: 'TLS1_2'
    allowBlobPublicAccess: false
  }
}
# Terraform equivalent
resource "azurerm_storage_account" "this" {
  name                     = "st${random_string.suffix.result}"
  resource_group_name      = azurerm_resource_group.this.name
  location                 = var.location
  account_tier             = "Standard"
  account_replication_type = "LRS"
  min_tls_version          = "TLS1_2"
  allow_nested_items_to_be_public = false
}

Drift Detection

Terraform's plan surfaces drift by diffing state against live. Bicep detects drift by re-running deployments in what-if mode. Less dramatic, but it works. Where Terraform wins is the full-graph view of drift across a large estate; where Bicep wins is that drift in one resource does not corrupt a state file.

CI/CD and Pipelines

Both integrate cleanly with Azure DevOps and GitHub Actions. Terraform's pattern, plan → human review → apply. Is slightly richer than Bicep's what-ifdeploy, but both are production-ready. The meaningful difference is cost: Terraform with a hosted state backend (Terraform Cloud, spacelift) adds a line item; Bicep does not.

Testing

  • Terraform. Terratest, terraform-compliance, tflint, tfsec. The testing story is mature if verbose.
  • Bicep. Az-bicep build for lint, deployment-what-if for preview, PSRule for policy checks. Thinner than Terraform's testing story but improving.

Migration Cost

Migrating from Terraform to Bicep (or vice versa) is a multi-month project for anything non-trivial. Unless there is a pressing reason. A team that cannot support state management, or a multi-cloud pivot. The migration is rarely worth it. The better move for most teams is to standardise on one for new projects and let old projects attrit.

The Recommendation Matrix

  • Greenfield, Azure-only, small platform team. Bicep.
  • Greenfield, multi-cloud intent, any platform team size. Terraform or OpenTofu.
  • Brownfield with significant existing Terraform. Stay on Terraform.
  • Brownfield with heavy ARM-template inheritance. Bicep is an easier upgrade path than Terraform.

The tool matters less than the discipline. A well-run Bicep estate outperforms a neglected Terraform one; the reverse is also true. Pick the one the team will actually keep tidy.

Related posts

DevOps & Infrastructure
Terraform to Bicep Migration on Azure: A Field Guide

Moving Azure infrastructure from Terraform to Bicep is less about converting HCL files and more about replacing a state-file workflow with a deployment-based one. This field guide covers when migration pays off, inventorying tfstate, incremental coexistence patterns, the decompile tooling that exists, deployment stacks as the lifecycle answer, and the what-if validation and rollback discipline that keeps the cutover safe.

DevOps & Infrastructure
Self-Hosted GitHub Runners on Azure: The ROI Calculation

The honest cost model for self-hosted GitHub Actions runners on Azure — break-even math against hosted runners, when self-hosting is a trap, and the ephemeral scaleset architecture that keeps them safe in production.

AI & Machine Learning
Anthropic prompt caching pricing: write, read and TTL math

Anthropic prices prompt caching with three numbers: a 1.25x or 2x premium on cache writes depending on TTL, a 0.1x rate on cache reads, and the base input rate for everything after the last breakpoint. This deep-dive verifies every figure against the current official docs and covers per-model minimums, break-even math, batch stacking and how Claude on Azure converts it all into CCUs.

Azure & Cloud
Azure Assistants API retired: migrating to Foundry Agents

The Azure OpenAI Assistants API reached its retirement date on 26 August 2026, and the classic Foundry Agent Service it underpins retires 31 March 2027. A step-by-step migration guide to the new Foundry Agent Service on the Responses API: threads become conversations, runs become responses, assistants become versioned agents, and Microsoft's migration tool rewrites code but not stored state.