Terraform vs OpenTofu

WHAT IS BEING DECIDED Which infrastructure-as-code engine to standardise on. OpenTofu forked from Terraform after HashiCorp moved Terraform to the Business Source License; the fork is under the Linux Foundation and remains open source. For most existing configurations the two are still interchangeable. The decision is therefore mostly about licence exposure, governance and where each roadmap is going — not about whether your modules will work. HOW TO WEIGH IT Weight licence terms heavily if you sell software or services that could be read as competing with HashiCorp's offerings, or if your legal function requires an OSI-approved licence in the toolchain. For most end users deploying their own infrastructure, the BUSL terms do not bite — but "does not currently bite" is a legal judgment worth getting rather than assuming. Weight ecosystem and commercial support heavily if you depend on HashiCorp's managed platform or on vendor support contracts. WHEN EACH WINS Terraform wins when you use the surrounding commercial platform, need vendor support, or want the largest install base and the first-party provider relationship. OpenTofu wins when an OSI-approved licence matters to your organisation, when you want foundation governance rather than single-vendor control, or when you value features the fork has shipped independently. It also wins by default for organisations that simply do not want the licence question on their risk register. HOW TO DECIDE For a new project the migration cost is near zero either way, so decide on licence and governance and move on. For an existing estate, the cost is a state-file migration and a CI change — small today, and likely to grow as the tools diverge, which argues for deciding deliberately rather than drifting. Get a legal read rather than relying on engineering interpretation of the licence, then record it as an architecture decision — see /templates and /infraops.