What Codifying 1,000 Azure Resources Actually Looks Like

The theory of IaC codification is straightforward: discover what exists, generate code that describes it, import into Terraform management. Clean steps, clean outcome.

The practice is messier. Dependencies between resources aren't always obvious. Resources created in the console months or years ago may have configurations that don't map cleanly to current provider schemas. And the volume of resources in a mature Azure environment makes the manual approach impractical at any meaningful scale.

We ran a live codification test against an Azure subscription with over 1,000 resources. Here's what the process actually looked like.

The inventory problem is the real problem

Before writing a single line of code, you need to know what's there. That sounds obvious. It isn't.

Cloud environments accumulate resources that nobody fully owns: test infrastructure that never got cleaned up, resources provisioned for projects that ended, dependencies created implicitly and never documented. The gap between what teams think is in their environment and what's actually there is where most of the risk lives.

The subscription had 1,003 resources across 16 resource types, all provisioned through the Azure portal over time. No Terraform, no state file, no documentation beyond what Azure itself records.

A full inventory scan surfaced all 1,003 resources in roughly 10 minutes. But the raw count wasn't the useful part. The dependency mapping was. A storage account with containers attached needs to be codified with those containers. A VM tied to a network interface and security group needs all three handled together. Without that map, you discover scope problems mid-run rather than before you start.

This is the kind of visibility a cloud inventory gives you before any code gets written. Not as a codification tool, but as a prerequisite to doing it well.

The codification runs

Run 1: Storage account and container

The first run targeted a storage account and its container, a contained dependency tree chosen to validate the approach first.

The generated Terraform followed standard module structure: main.tf, reusable modules, a variable file. Running terraform plan showed no additions, no modifications, no deletions. The code also passed cost analysis and 400+ policy checks before being prepared for a pull request, catching misconfigurations that had existed in the environment but were never validated against a policy framework.

Run 2: Virtual machine with network interface and security group

The second run targeted a more complex tree: a VM, its network interface, and the attached security group (seven to eight resources in total).

The plan showed a near-complete match, with the delta consisting of minor tag discrepancies. No infrastructure changes, no risk to running resources. The fix is straightforward: review the plan output, update the variable file, re-run.

What the process revealed

Two things stood out beyond what the inventory predicted.

Shared resources need deliberate scoping. The security group in run two was used by multiple VMs. Including it in a single codification run would have created a state file claiming ownership of a shared resource. The right call was only obvious because the dependency map was in hand before starting.

The documented/actual gap is real. In an environment managed manually over years, there will be configuration details nobody remembers setting. Codification surfaces those, and knowing about them before resources go under Terraform management matters more than how fast the code gets generated.

The practical upshot

A 1,000-resource Azure environment that would have taken an experienced engineer months to codify manually was reduced to a series of targeted runs, each taking minutes. That's a different category of approach, not a marginal improvement.

But speed isn't the bottleneck most teams expect. Discovery is. Knowing what's there, how resources relate, and where scope boundaries should be is the work that determines whether a codification project succeeds or stalls.