ADR-0005: Terraform Dual-Track

Status: Implemented | Date: 2026-04-17

Context

The SMB Ready Foundation was originally Bicep-only (ADR-0001, ADR-0002). Partner adoption data showed a subset of SMB operators standardize on Terraform across their multi-cloud estate and are unwilling to add Bicep. Three options:

1. Bicep only (status quo) — Partners on Terraform cannot adopt without dual-tooling
2. Replace Bicep with Terraform — Abandons existing partners and discards verified AVM code
3. Publish Terraform alongside Bicep — Partners pick one per subscription

Decision

Ship a Terraform track with functional parity alongside the Bicep track. Neither is authoritative at the architecture level — both compile to the same resource inventory, policies, tags, and WAF scoring from ADR-0001.

Parity Invariants

• Same CAF naming conventions and region abbreviations
• Same required tags: Environment, Owner, Project, ManagedBy
• Same 4-scenario matrix: baseline, firewall, vpn, full
• Same 33 MG-scoped policies + 1 sub-scope DINE
• Same cost envelopes and security baseline

Mutual Exclusion

Both tracks produce identical resources with intentionally colliding names. Choose one per subscription — deploying both simultaneously causes conflicts.

Intentional Divergences

Concern	Decision
ManagedBy tag	"Terraform" (provenance tracking)
AVM posture	Raw azurerm_* for 1:1 parity review
Scope composition	Single root (see ADR-0006)
State management	Remote state in Azure Storage
Budget start date	Injected by hook (Azure API immutability)

Consequences

Positive: Unlocks Terraform-only partners, functional parity means architecture documentation applies to both, dual-track validates design portability.

Negative: Maintenance burden of two IaC codebases, partners must choose one per subscription, AVM-TF adoption deferred (tracked as future refactor).