Should we adopt OpenTofu after the HashiCorp license change, or stay on Terraform for infrastructure managing 3 AWS accounts and 1,200 resources?

Council notes

Evidence boundary

Observed from your filing

• Should we adopt OpenTofu after the HashiCorp license change, or stay on Terraform for infrastructure managing 3 AWS accounts and 1,200 resources?

Assumptions used for analysis

• All 1,200 resources across 3 AWS accounts are managed for internal use only — the company does not resell or offer IaC/infrastructure management as a hosted service to third parties
• Engineering cost rate of ~$800/day is representative of the team's fully-loaded cost
• Terraform 1.9.x state format remains compatible with OpenTofu 1.8.x through at least mid-2026 based on current divergence trajectory
• HashiCorp/IBM does not introduce mandatory Terraform Cloud integration or registry restrictions for BSL-licensed versions already distributed
• The $20K budget can be preserved as an emergency migration fund rather than being reallocated
• current scale defaulted: moderate scale assumed (not_addressed)
• existing stack defaulted: greenfield assumed (not_addressed)

Inferred candidate specifics

These details were introduced by the Council during analysis. They were not supplied in your filing.

• Stay on Terraform (BSL 1.1) and defer migration. For 3 AWS accounts and 1,200 resources used as internal infrastructure, BSL imposes zero additional cost — HashiCorp's license explicitly permits end-user infrastructure management. Migrating now costs ~$9,600 (12 engineering days at $800/day) for zero functional gain, consuming 48% of the $20K budget. Concrete actions: (1) Pin Terraform at 1.9.x — do not auto-upgrade. (2) Document internal-use-only status in a 1-page compliance memo (2 hours). (3) Set Q3 2026 calendar reminder to reassess OpenTofu state compatibility. (4) Reserve the $20K as emergency migration fund. Re-evaluate trigger: If HashiCorp/IBM introduces per-resource or per-account pricing exceeding $500/month, or if the provider registry becomes restricted, execute migration. The version pin at 1.9.x maintains state compatibility with OpenTofu 1.8.x through at least mid-2026, preserving this escape hatch. Key failure mode: 'Boiling frog' — IBM progressively tightens terms and by the time you react, state divergence makes migration cost $40K+. Quarterly compatibility checks between pinned Terraform and latest OpenTofu mitigate this.
• Pin Terraform to version 1.9.x in all CI/CD pipelines and version constraint files across all 3 AWS accounts, then write a 1-page internal license compliance memo documenting that all 1,200 resources are managed for internal use only under BSL 1.1 permitted usage.
• b003 had the highest confidence (0.88), survived 3 rounds of adversarial prosecution including direct attacks on the 'zero cost' rationale (b005, killed) and reframing attempts (b004, killed). It names specific version pins (1.9.x), specific cost thresholds ($500/month trigger), specific migration costs ($9,600), specific failure modes (boiling frog, audit surprise) with concrete mitigations, and specific timelines (mid-2026 compatibility window). No other branch matched this level of specificity or adversarial resilience.
• b001: Adopt OpenTofu with phased migration (50% by Q3 2024, 100% by Q1 2025), allocating $15K for migration and $5K for training.
• Spends $15K+ to migrate away from a license that costs $0 for internal use. The phased approach still consumes 75% of budget for zero functional gain at this scale. The timeline (Q3 2024) may already be past. Does not articulate what concrete risk justifies the expenditure today.
• b002: Evaluate OpenTofu with a proof-of-concept before deciding; alternatively negotiate HashiCorp terms.
• Structurally a non-decision. 'Evaluate' and 'negotiate' are deferral mechanisms without concrete thresholds for when to act. b003 provides the same optionality (version pin as escape hatch) without the overhead of running a PoC that produces no production value.
• b006: Split strategy — Terraform for stable resources, OpenTofu for new/experimental infrastructure.

Inferred specifics table

Structured audit rows for Council-added details. Synthetic basis means the detail was introduced by analysis, not supplied by the filing.

Unknowns blocking a firmer verdict

• Whether IBM (post-acquisition) will change HashiCorp's licensing strategy is fundamentally unpredictable — the version-pin mitigation assumes state format divergence remains manageable through mid-2026, but this timeline is a projection based on current divergence rate, not a guarantee
• If the organization offers any managed services or consulting that touches this infrastructure, the BSL internal-use classification may not hold — this requires legal review specific to the company's business model
• OpenTofu's long-term ecosystem viability (provider registry completeness, community module support) is uncertain — if it becomes the de facto standard and Terraform's registry degrades, the calculus reverses
• The $800/day engineering cost and 12-day migration estimate are synthetic — actual migration complexity depends on custom providers, remote state backend configuration, and CI/CD pipeline specifics

Operational signals to watch

Branch battle map