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.
• Pin Terraform to 1.9.x in all CI/CD pipelines (e.g., GitHub Actions, atlantis config) and add required_version = '~> 1.9.0' to all root modules across 3 AWS accounts
• Write a 1-page license compliance memo documenting internal-use-only status under BSL 1.1, reviewed by legal if company offers any client-facing managed services
• Set up quarterly compatibility check: run OpenTofu plan against a non-production state file copy to verify state format compatibility with pinned Terraform version
• Set Q3 2026 calendar reminder to reassess: check OpenTofu/Terraform state divergence, HashiCorp pricing changes, and provider registry status
• If HashiCorp announces per-resource/per-account pricing exceeding $500/month or restricts provider registry access, trigger emergency migration using the reserved $20K budget

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