Your team is deciding between staying on Terraform and moving to OpenTofu. What technical and operational factors actually decide it?
Quick Answer
Compatibility is a wash at the core workflow level (state, HCL, providers via the OpenTofu registry) — the decision hinges on: license exposure (BUSL restrictions vs MPL), features unique to each side (OpenTofu: state encryption, provider iteration via for_each, exclusion flags; Terraform: Cloud/Enterprise integration, some newer HCL features), ecosystem/vendor support in your toolchain, and the migration/rollback cost including provider source pinning.
Detailed Answer
Work the decision as four columns: (1) Legal/strategic — HashiCorp's BUSL matters mostly to vendors embedding Terraform and orgs uncomfortable with license-change risk; OpenTofu's Linux Foundation home and MPL license remove that class of concern; if you sell a product wrapping the tool, this column often decides alone. (2) Features — OpenTofu shipped differentiators: client-side state encryption (the big one for regulated teams), -exclude planning flags, provider for_each; staying current with Terraform gets you its own additions and first-party Terraform Cloud. If you're an HCP/TFE shop, that integration is a strong Terraform anchor; if you run Atlantis/Spacelift/env0/raw CI, both work. (3) Ecosystem — check your critical providers and modules resolve from registry.opentofu.org (mainstream ones are mirrored; long-tail or vendor-private ones may need explicit source pins to registry.terraform.io — a known migration pitfall), and confirm your wrapper tooling (linters, cost tools, policy engines) supports tofu binaries. (4) Migration mechanics — the switch itself is usually 'install tofu, tofu init, plan shows no diff', but do it on a state copy first, pin provider sources explicitly, migrate one low-risk workspace as canary, and keep the terraform binary path tested for rollback during a defined window. Divergence grows over time, so 'decide later' quietly becomes 'migrate more expensively later'.
Code Example
# migration canary checklist
cp -r envs/dev /tmp/dev-copy && cd /tmp/dev-copy
tofu init # watch provider resolution — pin sources if any fail
tofu plan # must be empty vs terraform plan
# pin explicitly where needed:
terraform { required_providers { vendor = { source = "registry.terraform.io/vendor/thing" } } }Interview Tip
Structure beats allegiance: license, features, ecosystem, migration cost. Mentioning the registry provider-resolution pitfall and 'empty plan on a state copy' as the canary shows hands-on migration knowledge.