AzureRM 5.0 shipped 28 July 2026: why classic Azure landing zones cannot follow

Summary. HashiCorp made Terraform AzureRM provider 5.0 generally available on 28 July 2026. If your Azure estate was built on the classic Azure landing zones Terraform module, Azure/terraform-azurerm-caf-enterprise-scale, you cannot take that upgrade. That module declares azurerm (~> 3.108) in its requirements and pins ~> 3.107 in its own usage example, and a pessimistic constraint on 3.x will not resolve to 4.x, let alone 5.0. Its last release is v6.3.1, dated 28 July 2025, one year before AzureRM 5.0 shipped. The module's README carries a deprecation notice: extended support with "quality updates (e.g. bug fixes) and policy library updates only", "No new features", and a repository archive date of 1 August 2026. The module still shows 960 stars and 642 forks, so a large number of Azure estates are sitting on a frozen foundation.

That reframes the work. For teams on the classic module, moving to AzureRM 5.0 is not a provider bump in a pipeline. It is a migration to Azure Verified Modules for Platform landing zone, which is four separate Terraform modules rather than one, plus a set of behavioural changes in AzureRM 5.0 that change what Terraform does to your subscriptions on day one. The most consequential of those: the provider used to check and attempt to register roughly 60 Azure Resource Providers at initialization, and in 5.0 it registers none by default. Microsoft's own Azure landing zones documentation lists 14 Resource Providers needed for an empty ALZ deployment. Those 14 are now your responsibility to declare.

This article sets out what actually changed, the sequence we use to move a live estate, and where the work usually goes wrong. eCorpIT is a Gurugram technology consultancy founded in 2021, CMMI Level 5 assessed, MSME certified and ISO 27001:2022 certified, and we run this migration for Indian and global platform teams.

What AzureRM 5.0 actually changed

Tiberiu Radu, writing HashiCorp's general availability announcement for the AzureRM provider on 28 July 2026, framed the release this way: "This major release gives users more control over how the provider interacts with Azure subscriptions, introduces opt-in Azure preflight validation, and removes resources and properties deprecated across previous releases."

Four changes matter to an existing estate.

Resource Provider registration is now opt-in. Previous versions "automatically checked and attempted to register a legacy set of approximately 60 Azure Resource Providers during initialization", which HashiCorp says "could add startup time, create permission errors in restricted environments, and register services a team did not intend to use." In 5.0 no Resource Providers are registered by default. You can register only what your configuration needs, retain the legacy behaviour explicitly, or manage registration outside Terraform entirely.

Preflight validation is available and opt-in. For supported resources the provider can call the Azure Preflight Validation API during terraform plan and surface "certain policy violations, quota breaches, and invalid property values before an apply begins." Two caveats from the same announcement: it covers a subset of resources, and values Terraform does not know until apply cannot be included in the validation request. It is an extra checkpoint, not a replacement for apply-time failure handling.

Validation defaults flipped. Validation of Azure locations and Resource Provider names through the Azure Metadata Service is now disabled by default, and teams that want those checks at plan time have to enable them through the enhanced_validation feature block. A configuration that silently caught a typo in a region name in 4.x will not catch it in 5.0 unless you turn the check back on.

Deprecated surfaces are gone. The older App Service and Function App resources are removed in favour of the Linux and Windows-specific resources, along with resources for retired or replaced Azure services. The release also continues the shift toward Azure resource IDs instead of separate resource names across several schemas, and moves configuration that used to be embedded in larger resources into dedicated resources, including Storage Account queue properties and static website configuration.

The classic module problem, in one table

The four AVM pattern modules that cover the scope of the original ALZ Terraform module are avm-ptn-alz for management groups, policy and role assignments, avm-ptn-alz-management for management resources, avm-ptn-alz-connectivity-hub-and-spoke-vnet, and avm-ptn-alz-connectivity-virtual-wan. Microsoft's stated rationale for the split is community feedback that the single module "contained a combination of components that you may not need", and that different teams needed to own different components.

That last point is the one platform leads underrate. Splitting connectivity from management groups and policy is not only a packaging change. It lets a network team and a governance team hold separate state and separate pipelines, which is usually the actual blocker in a 200-engineer organisation, not the HCL.

The Resource Provider list you now own

Because AzureRM 5.0 registers nothing by default, the Resource Providers your landing zone depends on have to be registered deliberately. Microsoft's Azure landing zones FAQ publishes the list for an empty subscription deployment:

            # The 14 Resource Providers Microsoft lists for an ALZ deployment
# into empty subscriptions. Register these in ALL subscriptions
# associated with the landing zone.
locals {
  alz_required_resource_providers = [
    "Microsoft.Insights",
    "Microsoft.AlertsManagement",
    "Microsoft.OperationalInsights",
    "Microsoft.OperationsManagement",
    "Microsoft.Automation",
    "Microsoft.Security",
    "Microsoft.Network",
    "Microsoft.EventGrid",
    "Microsoft.ManagedIdentity",
    "Microsoft.GuestConfiguration",
    "Microsoft.Advisor",
    "Microsoft.PolicyInsights",
    "Microsoft.ContainerInstance", # used by deployment scripts
    "Microsoft.Storage",           # used by deployment scripts
  ]
}
          

Microsoft flags Microsoft.ContainerInstance and Microsoft.Storage specifically because deployment scripts use them, and recommends registering them up front "to avoid issues mid-run if there is any problem registering them." A separate list of 12 commonly needed providers covers workloads rather than the platform itself: Microsoft.Compute, Microsoft.Storage, Microsoft.ResourceHealth, Microsoft.KeyVault, Microsoft.Sql, Microsoft.Capacity, Microsoft.ManagedServices, Microsoft.Management, Microsoft.SecurityInsights, Microsoft.Blueprint, Microsoft.Cache and Microsoft.RecoveryServices.

Microsoft also notes that Azure will usually register a provider automatically if it is missing, "However, in some cases, deployment fails if the proper Resource Providers are not registered." Combine that with a restricted-permission service principal, which is the norm in a regulated Indian enterprise, and the automatic path is exactly the one that fails at 2 a.m. Registering explicitly is the boring, correct answer.

How we sequence the migration

There is no version bump that gets a classic-module estate to AzureRM 5.0, so we sequence it as a migration with a working system at every step.

Microsoft publishes migration guidance in two parts, "Management and Connectivity Resources" and "Management Groups and Policy", plus a migration FAQ. HashiCorp's own recommendation list for the provider upgrade is short and worth following literally: review the resources and properties your configurations and modules use, decide how Resource Provider registration should be managed, decide whether to enable location, Resource Provider or preflight validation, test in a non-production environment and review the resulting terraform plan, and pin the provider version while validating and rolling out.

The single most useful engineering habit here is reading plans rather than trusting them. A migration of this shape produces plans containing destroys that are actually state moves. Every destroy in phase 3 should be explained before anyone runs apply.

Where teams lose time

Three patterns account for most of the overrun we see.

Treating the archive date as the deadline. The archive date announced in the module's README was 1 August 2026, and archiving a repository does not break anything that already runs. Existing pinned versions keep working. The real deadline is the first time you need a bug fix, a new Azure service, or a provider feature that only exists in 4.x or 5.x. That deadline is unpredictable and usually arrives during an incident.

Migrating the network first. Connectivity is the visible part, so it attracts attention, but management groups and policy assignments are where state conflicts bite. Microsoft's own migration guidance is split precisely along that seam, and the ordering matters because policy assignments reference management group scopes that the new modules create.

Turning validation off and forgetting. AzureRM 5.0 disables Azure Metadata Service validation of locations and Resource Provider names by default. A team that never notices loses a plan-time check it had been relying on for years without knowing. Decide explicitly, write the decision into the provider block, and move on.

One more, specific to cost: the ALZ Accelerator ships documented options to turn off components you may not want on day one, including the DDoS protection plan, Bastion host, Private DNS zones and Virtual Network Gateways. Azure DDoS Network Protection is billed as a fixed monthly plan fee covering up to 100 public IP resources across a tenant, with per-resource billing above that, while IP Protection bills per protected public IP. Microsoft's DDoS pricing guide, dated 17 March 2026, publishes the billing model but deliberately no amounts, pointing to the regional pricing page instead. Decide that one on purpose rather than inheriting it from a starter scenario.

India-specific considerations

Indian platform teams hit three variations on this migration that global guidance does not cover well.

Restricted service principals are the norm, not the exception. Banking, insurance and listed-company estates rarely grant a Terraform identity subscription-level permission to register arbitrary Resource Providers. Under AzureRM 4.x and earlier, the provider's automatic registration attempt against roughly 60 providers was a recurring source of permission errors in exactly those environments. AzureRM 5.0's default of registering nothing is a genuine improvement for regulated Indian estates, provided someone owns the explicit list.

Data residency shapes the module choice. Where personal data under the Digital Personal Data Protection Act 2023 is in scope, region pinning and policy assignment are governance controls, not conveniences. The AVM approach helps here because avm-ptn-alz handles management groups, policy and role assignments as its own module, so the governance team can own that state independently of whoever owns the hub network. We design Azure architectures aligned with DPDP Act requirements and with the client's own regulator commitments; we do not claim certification against frameworks eCorpIT does not hold.

Multi-region is now the default assumption. Microsoft's Accelerator ships 11 starter scenarios, and multi-region hub-and-spoke, multi-region Virtual WAN, single-region variants and two SMB scenarios are all documented paths. Indian estates that started single-region in Central India and later added South India or an offshore region tend to have hand-rolled the second region. The migration is the moment to replace that with a supported scenario rather than carrying it forward.

What we build

For an Azure landing zone and Terraform modernisation engagement, eCorpIT's senior engineering teams take on the inventory, the Resource Provider ownership model, the module migration itself, the provider cutover and the pipeline split. We work against your existing state rather than rebuilding an estate from scratch, because a greenfield rebuild is usually sold as lower risk and is almost never lower risk once workloads are running. We also write the runbook your team keeps: which provider version is pinned where, who owns which state file, and what has to be reviewed before an apply reaches a production management group.

Related reading from our engineering team: Terraform AzureRM 5.0 breaking changes and migration covers the provider-level detail, cloud FinOps for Indian teams covers the spend side of a platform rebuild, and Azure App Service Isolated v4 cost and performance covers a hosting decision that often lands in the same quarter. Our cloud migration and modernization service page describes the wider engagement.

FAQ

How eCorpIT can help

eCorpIT runs Azure landing zone and Terraform modernisation for teams whose infrastructure as code was correct when it was written and has since been overtaken by the provider. We inventory the estate, take ownership of Resource Provider registration, migrate management groups and policy before connectivity, cut over to AzureRM 5.0 with the validation decisions written down, and split the pipelines so separate teams can ship without waiting on each other. We are a senior-led, multi-disciplinary organisation in Gurugram, CMMI Level 5 assessed, MSME certified and ISO 27001:2022 certified, and a Microsoft partner. If your Terraform is pinned to a provider line that stopped moving, talk to our platform engineering team.

References

1. Terraform AzureRM provider 5.0 now generally available - HashiCorp, 28 July 2026, Resource Provider registration, preflight validation, validation defaults and removed surfaces.

1. AzureRM 5.0 upgrade guide - Terraform Registry, provider-level changes, removed resources and data sources, breaking schema changes.

1. hashicorp/azurerm provider - Terraform Registry, current provider versions and documentation.

1. Azure/terraform-azurerm-caf-enterprise-scale - the classic Azure landing zones Terraform module, deprecation notice, version requirements and release history.

1. AzureRM provider CHANGELOG - the complete list of changes in version 5.0.

1. terraform-provider-azurerm - the provider repository, issues and releases.

1. Azure Verified Modules for Platform landing zone, Terraform - Microsoft, the four pattern modules and the rationale for the modular approach.

1. ALZ Azure Resource Provider recommendations - Microsoft, the 14 providers for an empty-subscription deployment and 12 further recommendations.

1. ALZ Terraform migration guidance - Microsoft, the two-part migration path and migration FAQ.

1. ALZ Accelerator, Terraform starter scenarios - Microsoft, the 11 documented starter scenarios.

1. ALZ Accelerator, Terraform options - Microsoft, the 16 documented customisation options.

1. Azure/avm-ptn-alz - Terraform Registry, the ALZ core pattern module for management groups, policy and role assignments.

1. Compare pricing between Azure DDoS Protection tiers - Microsoft, dated 17 March 2026, the Network Protection and IP Protection billing models.

Last updated: 9 August 2026.