If you read the industry press, you’d think infrastructure-as-code is a solved problem. Everyone’s doing it. Terraform and Pulumi dominate. Everything’s version-controlled, repeatable, and automated. Simple.

The reality in mid-market Australian companies is a lot messier. I’ve worked with dozens of organisations in the 200-to-2,000-employee range over the past few years, and the gap between IaC aspiration and IaC reality is wider than most people admit. Here’s what the landscape actually looks like in 2026.

The Three Stages I Keep Seeing

Most mid-size firms fall into one of three categories when it comes to IaC maturity.

Stage one: IaC exists in name only. Someone wrote some Terraform files two years ago to provision a few cloud resources. Those files are in a repository somewhere, but they’ve drifted significantly from the actual infrastructure. Changes have been made manually through the console because it was faster, and nobody went back to update the code. The Terraform state file may or may not reflect reality. In some cases, nobody on the current team even knows how to run it.

This is more common than you’d think. I’d estimate 40 percent of the mid-size companies I’ve worked with are here. They’ve technically adopted IaC, but in practice it’s decorative.

Stage two: IaC for new stuff, manual for legacy. This is probably the most common position — maybe another 40 percent. New infrastructure gets provisioned through code. There’s a pipeline, there’s version control, there might even be code review. But the existing environment — the stuff that was built before IaC was adopted — is still manually managed. And since that existing environment represents 70 or 80 percent of the infrastructure, most of the operational burden is still manual.

The challenge at this stage is that maintaining two operational models simultaneously is expensive and error-prone. Teams context-switch between automated and manual workflows constantly. Documentation is split. Troubleshooting requires different approaches depending on which part of the estate you’re working with.

Stage three: comprehensive IaC with mature practices. Everything — or nearly everything — is defined in code. Infrastructure changes go through pull requests. There’s a proper CI/CD pipeline for infrastructure. State is managed centrally. Drift detection is automated. Maybe 15 to 20 percent of mid-size firms have reached this level, and most of them are tech companies or have significant engineering DNA.

Why the Gap Persists

The barriers aren’t technical. Terraform, Pulumi, CloudFormation — the tools are mature. The documentation is good. Training is available. The problems are organisational and practical.

Skills gaps are real. IaC requires a combination of infrastructure knowledge and software development practices. Your existing infrastructure team knows the infrastructure but may not be comfortable with version control, code review workflows, or writing modules. Your developers know those practices but may not understand networking, security groups, or IAM policies. The intersection — people who do both well — is a small talent pool.

Retrofitting is painful. Importing existing manually-provisioned infrastructure into Terraform is tedious, time-consuming, and risky. Every resource needs to be imported individually, the state needs to be validated, and there’s always something that doesn’t map cleanly. Most organisations start with good intentions about retrofitting their legacy environment and then quietly shelve it because it’s not delivering enough immediate value to justify the effort.

The business doesn’t see it. IaC is an enabler, not a feature. It makes deployments faster, more reliable, and more auditable. But explaining that to a CFO who wants to know why you need two more engineers and three months of effort is difficult. The ROI is real but diffuse — it shows up as fewer outages, faster provisioning, better compliance posture. Those benefits are hard to quantify in a business case.

Working with firms like Team400.ai who’ve helped mid-market organisations accelerate their IaC adoption has shown me that the biggest accelerator isn’t better tooling — it’s dedicated capacity. Most internal teams never get the focused time to push through the retrofitting and pipeline work because they’re constantly pulled into operational firefighting.

What Actually Works

Based on what I’ve seen succeed, here are the approaches that move organisations from stage one or two to stage three:

Start with the pipeline, not the code. Get a working CI/CD pipeline for infrastructure changes before you worry about coverage. Even if it only manages 10 percent of your infrastructure, having the workflow established — code review, plan, approve, apply — creates the foundation everything else builds on.

Use modules aggressively. Don’t let teams write raw Terraform for common patterns. Build modules for standard configurations — a web app stack, a database setup, a networking baseline — and make those modules the expected way to provision. It reduces errors, enforces standards, and makes it easier for less experienced team members to contribute.

Accept the hybrid state. You’re going to have manually managed infrastructure alongside IaC-managed infrastructure for a while. Maybe a long while. Rather than pretending that’s not the case, build operational practices that accommodate it. Tag resources clearly. Document which resources are code-managed and which aren’t. Create a backlog for retrofitting and work through it gradually.

Drift detection is not optional. Without automated drift detection, your code and your actual infrastructure will diverge silently. Tools like Driftctl, Spacelift, or the built-in drift detection in Terraform Cloud make this manageable. Run it weekly at minimum. Address drift immediately or acknowledge it explicitly.

The Payoff Is Real

Despite all these challenges, the organisations that push through to mature IaC practices see genuine benefits. Provisioning time drops from days to minutes. Configuration consistency eliminates entire categories of production incidents. Audit and compliance become dramatically simpler. Onboarding new team members is faster because the infrastructure is documented in code.

It’s worth the investment. But going in with realistic expectations about the effort required and the organisational challenges you’ll face makes it much more likely you’ll get there. The technology isn’t the hard part. The hard part is everything around it.