Stop clicking.
Start declaring.

In August 2023, HashiCorp relicensed Terraform from the MPL open-source license to the Business Source License (BSL 1.1). The BSL is source-available, not open source: you can still read and run the code, but you cannot build a competing commercial product on it. For the vast majority of teams simply using Terraform to manage their own infrastructure, nothing about day-to-day work changed — and that is the honest headline.

The response was OpenTofu, a fork of the last MPL-licensed Terraform, now stewarded by the Linux Foundation. OpenTofu stays open source, tracks the HCL language closely, and is a near drop-in replacement for most workflows, with some genuinely useful features of its own such as state encryption and early variable evaluation. It is not a perfect mirror, and much of the provider and module ecosystem still centers on the Terraform registry, so a migration is a real decision rather than a rename.

We do not hold a religious position here. If you are an enterprise with a Terraform Cloud contract and Sentinel policies, staying put is often the right call. If you are wary of vendor lock-in or need everything under an OSI-approved license, OpenTofu is a strong, stable choice. What matters is that you decide deliberately, with a written rationale, rather than drifting into one by accident. We lay out the trade-offs for your specific situation and support whichever you pick.

When a migration is the answer, we treat it as an engineering project, not a find-and-replace. That means pinning your current version, standing up the new binary in CI alongside the old one, running plans through both to prove they agree, and cutting over environment by environment behind feature branches. The same discipline applies to the migrations we run most often: lifting a click-ops estate into code, moving local state to a locked remote backend, or upgrading across major provider versions. Every step produces a reviewable plan, and there is always a way back.

Terraform is easy to start and hard to keep clean. Most teams reach us at one of a handful of familiar breaking points:

• A single four-thousand-line state file that everyone is scared to touch, where one plan re-reads the entire estate.
• Copy-pasted HCL across ten repositories, so every change has to be made ten times and one copy always gets missed.
• Drift: the console and the code disagree, nobody knows which is right, and apply has become a gamble.
• A cloud footprint built by hand over three years that finally needs to come under version control.
• A new platform, fintech compliance requirement, or SOC 2 audit that demands every infrastructure change be reviewed and logged.
• The engineers who wrote the original modules have left, and the ones who remain treat Terraform as read-only.

If any of those sound like your week, that is exactly the work we do. Infrastructure as Code is the backbone of modern DevOps practice, and getting it right unlocks everything downstream, from safe deploys to predictable cloud spend.

You get engineers who have run Terraform at scale in production, not a slide deck. We write code you would be happy to inherit: small modules, clear interfaces, tests where they earn their keep, and documentation that lives close to the code. Everything ships in pull requests your team reviews, so knowledge transfers as we go rather than in a rushed handover on the last day.

We are also honest about scope. If your problem is really a cloud cost problem or a reliability problem wearing a Terraform costume, we will say so and point you at the right work — whether that is our cloud and FinOps practice, our SRE team, or a broader DevOps engagement. The goal is a durable IaC estate your team owns, not a standing dependency on us.