Why this exists

Terraform that worked for one team rarely works for ten.

Most Terraform codebases start clean and decay fast. Modules get copied, naming drifts, state files multiply, pipelines diverge. Adding a new resource becomes a forensic exercise. The Standardisation Framework gives you a versioned module library, clear conventions, and CI patterns that hold up as your team grows — without rewriting everything from scratch.

What's included

The full framework, applied to your codebase.

Module library design

Versioned modules for the resources you use most: networking, compute, data, identity. Semantic versioning, input/output contracts, and a private registry pattern.

Naming & tagging conventions

A documented standard for resource naming, tagging, environments, and regions. Enforced in code and validated in CI — no more bikeshedding in PRs.

State management strategy

Remote state with locking, state separation by environment and workload, secrets handling, and a clear pattern for state migrations.

CI patterns

Pull request validation: format, lint, security scan, plan output, cost estimate. Apply gated by environment and approval. Works in GitHub Actions or Azure DevOps.

Testing strategy

Static analysis with tflint and Checkov, unit tests where they make sense, integration tests for critical modules. Pragmatic, not dogmatic.

Migration plan

A staged rollout for moving existing Terraform onto the new framework. We don't rewrite everything — we agree the path and the priorities.

Deliverables

What you get at the end.

→Module library repositoryVersioned, documented, ready for your teams to consume. Semantic versioning and a clear release process.
→Standards & conventions documentThe naming, tagging, structure, and review rules — short enough to read in one sitting, specific enough to be useful.
→Reference CI templatesWorking pipeline definitions for GitHub Actions or Azure DevOps. Validation, planning, and gated apply.
→Migration roadmapA staged plan to move existing Terraform onto the framework, with effort estimates and risk callouts.

Timeline

Three phases. One to three weeks.

Days 1–3

Audit

Review your existing Terraform, team structure, pipelines, and pain points. Agree the conventions and module priorities.

Week 1–2

Build

Module library, CI templates, conventions doc, and reference patterns — written and tested in your environment.

Final week

Adopt

Migrate the first workload onto the framework together. Walkthrough, training session, and handover.

FAQ

Common questions.

We don't have any Terraform yet — should we start here?

Probably not. If you're greenfield, the Azure Launchpad sets up the foundation including a starter Terraform repo. Come back to standardisation when you have multiple teams and 10+ workloads in code.

We have Terraform but it's a mess — different from this scenario?

If everything is in code but inconsistent, this is the right engagement. If most of your environment is still managed via the portal or scripts, look at Brownfield Terraform Migration first.

Do you replace our existing modules?

Not unless we have to. We assess what you have, keep what works, and standardise the rest. The goal is a working framework, not a rewrite.

What about Terragrunt or other wrappers?

If you already use Terragrunt and it's working, we'll work within it. If you don't, we generally recommend staying close to vanilla Terraform plus good module patterns — fewer moving parts.

Can you also set up the CI/CD pipelines?

The reference templates are included here. If you need full pipeline build-out across multiple repos and environments, the CI/CD & Release Engineering Setup engagement is the right next step.

Terraform Standardisation Framework.