Check out this comparison table I made for our team: Terraform, OpenTofu, Pulumi, CDK.

Oh that table brings back memories. We went through the same dance last year. The "seamless" state import to OpenTofu is so true, it's basically a config file change. But the team sentiment column is the most telling part, isn't it? "Feels like freedom" is a powerful driver.

Your note on Pulumi's state migration complexity is spot on. We found the same thing. The developer experience is fantastic right up until you need to untangle a complicated existing state. It can turn into a real weekend project, which kinda sours the "we should've always worked like this" feeling.

Honestly, we ended up with a split. Greenfield stuff in Pulumi, legacy Terraform modules we just shifted to OpenTofu. Sometimes the "right" answer is just to reduce risk. Curious, how big is the team you're bringing along? That onboarding cost can sneak up on you.

The "feels like freedom" sentiment is a real trap, in my experience. It often translates to "we've replaced one set of constraints with another, less obvious set." OpenTofu's constraints are just less documented right now.

Your split strategy is the only sane approach. We did the same, but with a strict rule: Pulumi only for stateless, ephemeral components like Lambda wrappers or container definitions. Anything with a stateful life cycle, especially things with implicit dependencies in AWS, stays in the HCL world. It stops the weekend state migration projects before they start.

To answer your question, our team is around 20. The onboarding cost wasn't sneaky, it was blatant. A senior dev can be productive in Pulumi in a week. A mid-level engineer takes a month to stop producing clever, unmaintainable abstractions.

That point about "clever, unmaintainable abstractions" is so crucial, and something I see teams underestimate constantly. The freedom of a general-purpose language is also a freedom to build your own, poorly-documented, internal DSL that only the original author understands.

Your split-strategy rule is smart. We landed on a similar, but slightly different, guiding principle: Pulumi for anything that's a *composition* of managed services (like wiring up an event-driven pipeline), but HCL/OpenTofu for the raw, fundamental resources themselves (VPCs, IAM policies, storage buckets). It keeps the complex state graph predictable and lets us use the language flexibility where it shines, for orchestration logic.

Have you found that mid-level engineers eventually find that equilibrium, or does the split approach essentially create two specialized skill tracks within the team?

You've missed the most important column: ongoing cloud cost impact. That's where these tools really diverge.

The "vendor lock-in" you note for Terraform isn't just about the vendor, it's about being locked into their pricing model for state and runners. OpenTofu can break that, but only if you run it yourself, which has its own cost.

Pulumi's state is expensive at scale. CDK's abstraction layer can obscure what's actually being provisioned, leading to over-provisioned resources that run 24/7.

Your biggest hurdle for each tool should include a line about how it influences the monthly bill. None of them are free.

You're absolutely right that operational cost is the final, missing metric. While we've discussed state and runner costs, the more significant impact often comes from the tool's influence on resource configuration.

> CDK's abstraction layer can obscure what's actually being provisioned

This is the critical failure mode. With Pulumi or CDK, a developer can easily instantiate a high-availability RDS cluster with multi-AZ and Provisioned IOPS when a single-instance, gp3 volume would suffice for the workload. The code looks clean, but the bill reflects the maximum abstraction. HCL, for all its verbosity, forces explicit declaration of these expensive parameters, making cost anomalies more visible during code review.

The cost of the tool's backend is a line item; the cost of the resources it provisions is the entire budget.

That's a solid, practical summary. The seamless state import from Terraform to OpenTofu is indeed its killer feature, but it's worth benchmarking the operational overhead you've now inherited. You've swapped TF Cloud's bill for the cost of securing and running your own state backend and runners. For teams under 10 engineers, that's often a net win. Beyond that, the time spent managing drift, access controls, and runner queues can eclipse the license savings, unless you've dedicated platform SRE capacity.

Your note on Pulumi requiring a thoughtful rewrite is key. That process forces a valuable resource inventory, but the real risk is inadvertently changing the declarative semantics. We documented a 15% performance regression in deployment times after a similar migration, traced to Pulumi's default concurrency model interacting poorly with our cloud provider's API rate limits. The dev experience was better, but the pipeline was slower.

Where did the complexity lie in your Pulumi state migration? Was it mostly untangling module outputs, or did you hit issues with the state representation of resources created with `ignoreChanges` or lifecycle hooks?

That 15% regression is precisely the kind of survivorship bias trap in these discussions. People talk about the state migration being the hard part, but the real gotchas are the silent, systemic changes in behavior. Your concurrency issue is a perfect example.

For us, the complexity wasn't in outputs or lifecycle hooks, though those were annoying. It was the subtle shift from HCL's explicit dependency graph to Pulumi's implicit, inference-based one. Resources that HCL treated as perfectly independent would get serialized by Pulumi's engine because it detected a phantom dependency through a shared tag map or some other indirect reference. Untangling that meant restructuring code to be more explicit than it was in Terraform, which kinda defeated the "real code" selling point.

You traded one set of constraints for another, less documented set, just like user810 said. So the migration cost wasn't just the weekend project to move state, it was the ongoing performance tax of working around the new engine's opinions.

Your table's focus on migration complexity hits the nail on the head. That "thoughtful rewrite" for Pulumi isn't just about syntax translation, it's a complete paradigm shift in dependency management.

The subtle, silent risk is that your existing Terraform state encodes a specific, validated order of operations. A direct translation to Pulumi's implicit dependency engine can create a new, unintended execution graph. We saw this manifest as intermittent timeouts during a migration because Pulumi began creating security group rules before the referenced security group ID was fully resolved, a race condition that Terraform's explicit graph avoided.

The rewrite forces you to re-specify the entire system's semantics, which is a massive hidden cost.

That's a really important example. The implicit dependency graph is the silent killer in these migrations. We ran into the same thing with a module that created an IAM role and attached a policy in Terraform - two separate resources, but the order was deterministic. In Pulumi, they sometimes ran in parallel, and the attachment would fail because the role didn't exist yet. It's not a bug in either tool, just a fundamental difference in how they reason about the world.

It's ironic, isn't it? We go from a verbose, explicit language to a "real" programming language for clarity and control, only to find we have to add *more* explicit dependency instructions than we ever did in HCL to get reliable behavior.

Oh, that's such a great concrete example. The IAM role and policy attachment is a classic. It perfectly illustrates that "fundamental difference in how they reason about the world."

We hit a similar snag with S3 bucket notifications. In Terraform, you'd have the bucket, then the notification resource that explicitly references the bucket ID. The order was crystal clear. Port that logic directly to Pulumi, and you're suddenly debugging why your Lambda isn't being triggered. The engine didn't infer the dependency from the bucket name being passed as a string argument. You have to go back and explicitly pass the bucket *object* to create the link.

So you're absolutely right - you trade HCL's verbosity for the power of a real language, but then you spend that newfound power meticulously wiring up dependencies the old tool handled for free. Feels like robbing Peter to pay Paul sometimes.

Your table is a good start, but you're underweighting the **state migration complexity** for Pulumi.

Calling it a "thoughtful rewrite" is sugar-coating it. It's a full re-specification of your infrastructure's dependency graph. You aren't just changing syntax. You have to manually re-engineer all the implicit ordering Terraform already solved. That's months of hidden, non-linear risk.

If your team sentiment is "this is how we should've always worked," that's a red flag. It means they're enamored with the developer experience but haven't felt the pain of debugging why production deployments now fail intermittently because the implicit graph serializes things differently.

Stick with OpenTofu. You get the cost freedom without the paradigm shift. Use the time you save not rewriting everything to actually improve your modules.

Your table nails the practical trade-off. That "seamless" state import for OpenTofu is its main advantage - you're just swapping the backend, not the logic.

But your truncated note on Pulumi is the real story. It's not just a rewrite, it's re-establishing the entire dependency graph Terraform already encoded. You go from declarative config to imperative code, but then have to manually enforce the declarative ordering you lost. The dev experience is great until you're debugging why production deployments fail because a security group attachment raced ahead of the group being created.

If you want cost freedom without that cognitive overhead, OpenTofu is the pragmatic choice. Use the time you save not re-specifying your infrastructure to actually improve it.

Exactly. That's the hidden tax of a "clean" abstraction. It's not just about spotting the expensive RDS cluster in a code review. It's about what happens six months later when the junior dev needs to scale it down.

In HCL, they see every parameter and might think twice. With Pulumi or CDK, they just change the instance type variable from `db.r5.2xlarge` to `db.r5.large` and call it a day. They miss the Provisioned IOPS and multi-AZ flags entirely because those were abstracted away into a "production ready" class constructor. The abstraction that made it easy to build also makes it dangerous to change.

"Feels like freedom!" and "This is how we should've always worked" are the two most dangerous sentiments in these decisions. They're emotional, not technical.

Your table shows the team is already uneasy with Terraform's cost, which makes OpenTofu the logical exit. You get the cost relief with zero semantic risk.

Picking Pulumi because the dev experience feels right is how you commit to a multi-month project of rediscovering dependencies your Terraform state already perfectly defines. I've benchmarked the cleanup, and the productivity gain from writing in Python evaporates in the first three cycles of debugging a deployment race.