Monday morning at a mid-sized SaaS company. The head of infrastructure projects an email onto the conference room screen. IBM has just sent the annual Terraform Enterprise renewal quote. It’s 40% higher than last year. Three seconds of silence. Then the room erupts.
“I told you we should’ve left the day HashiCorp switched to BSL,” says the backend lead.
“Left for where?” the infrastructure head shoots back. “We’ve written HCL for three years. Hundreds of modules. You think we can just migrate on a whim?”
“OpenTofu is drop-in compatible. Not a single line of code changes.”
“And what about Terraform Cloud? State management, policy checks, all of that. Who handles it when we switch to OpenTofu?”
This conversation is playing out across thousands of engineering teams in 2026. IBM closed its $6.4 billion acquisition of HashiCorp a year ago. The commercial roadmap for Terraform remains unclear, but the bills have already arrived. The options on the table have never been more numerous, and the decisions have never been harder.
The Escape Hatch: OpenTofu
If your pain point is purely licensing and pricing, OpenTofu offers the path of least resistance.
This Linux Foundation-backed fork of Terraform went GA in January 2024 and reached CNCF Incubating status by 2026. The promise is straightforward: 100% compatibility with existing Terraform code, open source forever. Swap the terraform binary for tofu, leave your .tf files untouched, and your state files work as-is. For teams with hundreds of modules and dozens of pipelines, this zero-friction migration is the only realistic short-term option.
But OpenTofu solves the problem of ownership, not capability. The expressive ceiling of HCL remains unchanged. The provider ecosystem is shared but development velocity is starting to diverge. Community contributors are splitting their attention between two projects. Teams choosing OpenTofu typically think like this: offload the licensing risk now, deal with everything else later.
In practice, many CI/CD pipelines have hardcoded terraform binary paths, version locks, and provider mirror addresses. What looks like a simple command swap turns into auditing every pipeline dependency. If you were using Terraform Cloud’s remote execution, you need to either self-host or purchase an alternative remote execution environment. These hidden costs don’t appear in official migration docs, but they consume two to three weeks of actual engineering time.
Redefining Infrastructure with Code: Pulumi
The backend lead later tells me what he really wanted to push was Pulumi.
“Have you ever seen HCL that batch-creates VPCs in a for loop? The stuff you write with count and for_each becomes incomprehensible three months later.” He opens VS Code and shows me infrastructure code written in TypeScript. Functions, type inference, conditional logic, unit tests. It looks identical to application code.
Pulumi has been betting on this approach since 2019: describe infrastructure using real programming languages like TypeScript, Python, Go, and C#. By 2026, its biggest differentiator has become AI integration. Pulumi AI generates infrastructure code from natural language descriptions. Pulumi Insights uses AI to analyze your cloud resource topology and suggest optimizations. For teams that are already software engineers, this eliminates the cognitive cost of learning a DSL.
The tradeoff? Ecosystem coverage and team fragmentation. Terraform providers cover nearly every cloud service and SaaS platform. Pulumi can bridge to Terraform providers, but the quantity and maturity of native providers still lag. If your stack includes obscure cloud services or internal systems, you might hit walls. The more subtle issue is internal team dynamics. Operations-oriented engineers are accustomed to declarative thinking. Development-oriented engineers prefer imperative logic. Pulumi naturally favors the latter, which can create new skill divides within the team.
The Control Layer Battle: Spacelift and env0
The infrastructure head’s real concern isn’t which language to write IaC in. It’s who manages the execution flow. The things Terraform Cloud does (remote state, plan approval, policy enforcement, drift detection, cost estimation) don’t exist in bare OpenTofu mode.
This is exactly where Spacelift and env0 enter. They are orchestration and governance platforms for IaC, not tied to any specific IaC engine.
Spacelift’s selling point is exceptionally granular policy-as-code. It uses Open Policy Agent to write rules that can specify things like “this team can only create instances smaller than t3.medium in us-east-1.” Its drift detection scans for divergence between actual state and declared state at fixed intervals, automatically generating remediation plans. For heavily regulated industries like finance and healthcare, this is table stakes. A typical scenario: someone manually modifies a security group rule through the console at midnight while troubleshooting an incident. The next day, Spacelift detects the drift and prompts you to either roll back or accept the change.
env0 takes a different approach: developer self-service. It lets each team request environments through a catalog interface, with IaC code, approval flows, and cost budgets all preconfigured. Imagine a new developer spinning up a complete staging environment with two clicks, no waiting three days for SRE to get around to it. env0 also invests heavily in cost management. Every plan displays estimated cost changes, and you can set budget caps that automatically reject applies when exceeded. For teams whose cloud bills regularly overshoot and whose finance departments hound DevOps for reconciliation every month, this feature alone justifies the investment.
Both platforms support Terraform, OpenTofu, Pulumi, and even CloudFormation as underlying engines. The logic for choosing them: IaC engines are replaceable, but the control layer is a long-term investment.
The Kubernetes Purist Route: Crossplane
Another voice in the room comes from the Kubernetes engineer. His view is more radical: if everything ultimately runs on K8s, why not manage cloud resources the Kubernetes way?
Crossplane models every cloud resource as a Kubernetes CRD. An RDS instance becomes a YAML manifest. Apply it to the cluster, and the Crossplane controller calls the AWS API to create it. State lives in etcd. The reconciliation loop handles drift natively. GitOps tooling like ArgoCD and Flux works out of the box. For teams already managing application deployments with GitOps, infrastructure management can reuse the same PR review and auto-sync workflows. No need to maintain a separate IaC pipeline.
This sounds elegant, provided your team has already embraced Kubernetes deeply. If your operations people are fluent in the K8s operator pattern, Crossplane will feel natural. But if some team members barely know kubectl, pushing Crossplane creates new knowledge barriers. The learning curve isn’t the tool itself but the mental model of the entire K8s ecosystem. You need to understand controllers, reconciliation, finalizers, and composition before you can troubleshoot effectively when things break.
Core Comparison
| Dimension | OpenTofu | Pulumi | Spacelift | env0 | Crossplane |
|---|---|---|---|---|---|
| Positioning | Open source Terraform replacement | General-purpose programming language IaC | IaC orchestration and governance | IaC self-service and cost management | K8s-native resource management |
| Language | HCL | TS/Python/Go/C# | Agnostic (orchestration layer) | Agnostic (orchestration layer) | YAML (K8s CRD) |
| Migration cost | Very low | Medium-high (rewrite) | Low (wrap existing code) | Low (wrap existing code) | High (new paradigm) |
| License | MPL 2.0 | Apache 2.0 | Commercial | Commercial | Apache 2.0 |
| Best for | Existing TF users escaping BSL | Software engineering-oriented teams | Compliance-driven large orgs | Strong self-service needs | Deep K8s teams |
| State management | Self-hosted/S3/Postgres | Pulumi Cloud/self-hosted | Built-in | Built-in | etcd (K8s) |
| AI capabilities | Community exploration | Native integration | Limited | Limited | None |
What Nobody Tells You
The variable most easily overlooked in these discussions is cognitive load. All five tools solve the problem of managing cloud resources, but they impose completely different cognitive demands on teams. OpenTofu requires fluency in HCL. Pulumi requires you to be a programmer. Crossplane requires K8s expertise. Spacelift and env0 require understanding platform engineering concepts.
Another overlooked factor is that lock-in is simply shifting layers. People used to fear AWS lock-in. Then they feared Terraform lock-in. Now if you choose Spacelift or env0, the lock-in point becomes the orchestration layer. Every choice just moves the dependency to a different location. What you can do is pick a lock-in position you’re willing to live with.
The Hidden Migration Costs
When teams evaluate these alternatives, they tend to focus on feature comparisons and ignore the second-order costs that emerge during migration. These costs vary dramatically depending on which path you take.
For OpenTofu migrations, the advertised compatibility hides workflow dependencies. Your CI/CD system might use HashiCorp’s official Docker images. Your Terraform Cloud remote backends need replacement. Your team’s muscle memory expects specific error messages and output formats that might differ slightly. One team I spoke with found that their custom tooling around terraform output JSON parsing broke because OpenTofu’s JSON structure had minor differences in how it represented certain resource types. The fix took an afternoon, but nobody had budgeted for it.
Pulumi migrations are rewrite projects disguised as tool adoptions. You’re not just changing syntax. You’re changing how your team thinks about infrastructure. The Python or TypeScript code you write needs testing, linting, and code review standards. Suddenly you need decisions about project structure, dependency management, and whether to use classes or functions for resource definitions. Teams that succeed with Pulumi typically assign one or two engineers to build internal libraries and patterns first, then gradually onboard others. The teams that struggle try to convert everything at once and end up with five different styles of Pulumi code that nobody else can maintain.
Spacelift and env0 migrations involve less code change but more organizational change. You’re centralizing control that used to be distributed. Engineers who previously ran terraform apply from their laptops now submit plans through a UI and wait for approval. This is better for governance, but it changes daily workflows. Some engineers will resist. You need executive buy-in to enforce the new process, and you need to configure the platform to match your approval hierarchies, which means articulating policies that might have been informal before.
Crossplane migrations require rethinking your entire infrastructure delivery model. You’re not just adopting a tool. You’re adopting GitOps as a philosophy. That means training people on Git-based workflows, setting up ArgoCD or Flux, defining what belongs in which repository, and establishing who owns the cluster that runs Crossplane itself. For teams already deep into Kubernetes, this feels natural. For teams still treating K8s as a runtime for applications, not a control plane for infrastructure, the conceptual leap is substantial.
What About the Existing Codebase?
Most organizations considering alternatives have years of Terraform code in production. The question isn’t whether the new tool is better in a vacuum. It’s whether the delta is worth the migration cost for your existing codebase.
If you have 50 modules managing simple cloud resources, migration is tractable. If you have 500 modules with complex interdependencies, including custom providers for internal systems, the calculation changes. OpenTofu becomes the only realistic option in the short term because it requires zero code changes. Everything else requires a multi-quarter initiative.
Some teams adopt a hybrid strategy: freeze the existing Terraform/OpenTofu codebase in maintenance mode, then use Pulumi or Crossplane for all new infrastructure. This avoids the big rewrite while letting you experiment with better tools for future work. The downside is running two systems in parallel, which means two sets of state to manage, two approval workflows, and two skill sets to maintain on the team. For smaller teams, this overhead isn’t worth it. For larger organizations with dedicated platform teams, it’s a reasonable transition strategy.
Another approach is greenfield first. Deploy a new product or environment using the alternative tool. Learn from that experience before deciding whether to migrate existing infrastructure. This reduces risk but delays the benefits. If your primary motivation is escaping Terraform Enterprise pricing, greenfield experimentation doesn’t help with the bills you’re paying today.
Vendor Roadmaps and Ecosystem Momentum
Tools don’t exist in isolation. They exist in ecosystems that evolve over time. The decision you make in 2026 is really a bet on where these ecosystems will be in 2028.
OpenTofu’s momentum depends on sustained community contribution now that the initial fork energy has settled. The question is whether enough contributors stick around to keep pace with cloud provider changes. AWS alone launches hundreds of new services and features each year. Keeping providers current is unglamorous maintenance work. Terraform’s advantage was HashiCorp’s full-time staff dedicated to this. OpenTofu has passionate volunteers and some corporate backing, but the resource imbalance is real. If you choose OpenTofu, you’re betting that the CNCF governance model and community energy will sustain it long-term.
Pulumi’s trajectory depends on whether programming language ecosystems embrace infrastructure as code. The company is well-funded and shipping features aggressively. The AI integration is ahead of competitors. But Pulumi needs to expand beyond early adopters into the mainstream. If you choose Pulumi, you’re betting that the next generation of infrastructure engineers will prefer TypeScript over HCL, and that Pulumi can reach feature parity with Terraform’s provider coverage before teams lose patience.
Spacelift and env0 are both venture-backed startups. They’re building quickly and have strong customer traction in enterprises. The risk is typical SaaS risk: pricing changes, acquisition, or strategic pivots. If you choose either one, you’re betting on their ability to remain independent and customer-focused. The advantage is that they’re not trying to own the IaC layer, just the orchestration layer, which means you retain flexibility to swap the underlying engine.
Crossplane’s future is tied to Kubernetes’ dominance. If the industry continues consolidating on K8s as the universal control plane, Crossplane’s approach becomes increasingly natural. If the pendulum swings back toward simpler, more specialized tools, Crossplane might remain a niche solution for K8s-heavy shops. If you choose Crossplane, you’re betting that Kubernetes won’t just run your workloads but will also manage your infrastructure for the next decade.
The Real Question
After walking through all these options, the real question isn’t which tool is best. It’s what problem are you actually trying to solve?
If the problem is Terraform Enterprise pricing and licensing, OpenTofu solves it today with minimal disruption. You can make the switch in weeks and resume normal operations.
If the problem is that HCL has become a bottleneck for your engineering velocity, and your team is frustrated by its limitations, Pulumi solves that by bringing real programming languages to infrastructure. The migration will take months, but you’ll gain expressiveness and tooling integration that HCL can’t match.
If the problem is lack of governance, compliance failures, or runaway cloud costs, Spacelift or env0 solve that by adding the control layer you’ve been missing. You can keep your existing IaC code and wrap it in proper workflows.
If the problem is infrastructure and application delivery living in separate worlds, and you want to unify them under GitOps, Crossplane solves that by making infrastructure look like any other Kubernetes resource.
Most teams discover they actually have multiple problems. The Terraform licensing concern is the trigger, but underneath it are deeper frustrations about expressiveness, governance, or workflow integration. The trick is being honest about which problems matter most, then choosing the tool that addresses your top two or three issues, even if it doesn’t solve everything.
The infrastructure head’s final decision is to spend two weeks on a proof of concept. Run existing code on OpenTofu to validate compatibility, while letting the backend lead rewrite a new project’s infrastructure in Pulumi. Two paths in parallel. Look at the data in three months. Maybe pilot Spacelift on top of OpenTofu for the governance layer. See what breaks, what works, and what the team actually prefers once they’ve touched real code instead of reading marketing pages.
That’s probably the most honest answer for 2026. No tool is a silver bullet, but at least now you have options. Three years ago when Terraform dominated, there wasn’t even a choice. And choice itself is the greatest gift open source ecosystems give to engineers.
Stay updated with our latest AI insights
