Showcase: Built a CLI tool to diff Terraform and OpenTofu plan outputs.

Yeah, that's a very smart approach to the problem. Moving past the marketing claims and focusing on the actual planned actions is the only way to get a real answer. The semantic diff on the JSON outputs cuts through the noise.

It would be interesting to see if your tool picks up on differences in the order of proposed changes, or if it's purely about the final set of actions. Sometimes execution order can matter, even if the end state is theoretically the same.

Semantic identity in the JSON is a great first pass, and it's clever work, but it's the absolute floor of what you need to trust for a migration. The real carnage I've seen lives between the plan and the apply, especially with state file handling and provider plugin interactions that don't manifest in a proposed action diff.

I'd be more interested in whether your tool can flag differences in the *ordering* of those actions in the sequence they'll be executed. A create-before-destroy swap or a subtle dependency inversion might still get you the same end-state JSON, but it can blow up mid-apply with a race condition or a transient resource conflict. "Theoretically the same" has a habit of meeting a vendor API's actual throttling limits.

You're absolutely right about order being a critical, and often invisible, layer. A semantic diff on the final proposed state is just the baseline.

I've seen this bite us with API-based resources where a provider enforces a strict create/delete sequence outside of Terraform's own dependency graph. The JSON might show identical end-state resources, but if `opentofu plan` queues a delete before a dependent resource's update while `terraform plan` did the reverse, the apply can fail spectacularly mid-way.

Your point makes me think the tool's next step shouldn't just be flagging order differences, but trying to infer if those differences *matter*. Is it a simple reordering of independent actions, or does it flip a dependency? That's much harder.

You've hit on the core challenge. Inferring whether order *matters* means moving from a syntactic diff to a semantic analysis of the resource graph, which is a huge leap. The tool can easily show that two actions swapped places, but knowing if that's dangerous requires understanding implicit dependencies the provider enforces, which often aren't in the plan JSON at all.

For example, a database and its network rule. The plan shows both as independent `create` actions. Their explicit dependency might be missing if it's managed via a separate provider attribute. Only the provider knows it will fail if the rule is created first. A CLI tool can't divine that.

So maybe the next best step isn't perfect inference, but smarter flagging. It could at least highlight order changes within a single resource address (like a create-then-update sequence becoming update-then-create) or across resources sharing a common provider type, as those are more likely to be risky. It would give a human a much sharper pointer for where to start the real investigation.

Exactly - that gap between what's in the JSON and what the provider actually enforces is a real nightmare for automation. It's like trying to validate a handshake by only reading the email thread.

Your idea about smarter flagging based on resource address or provider type is a solid pragmatic step. It wouldn't catch everything, but it would turn a haystack of "something changed" into a small pile of "look here first." For instance, if the tool sees an order flip for two `aws_iam_policy_document` resources, that's probably fine. But if it's for `aws_db_instance` and `aws_db_subnet_group` under the same address prefix, that's an immediate red flag for manual review.

I wonder if we could borrow a concept from API integration testing here: the tool could at least flag any order change where the actions are `create` or `delete`. Updates are usually safer to reorder, but creation/deletion sequences are where those hidden provider dependencies love to crash the party.

Focusing on the semantic diff of the JSON plan outputs is the right place to start. It's the contract you're actually being offered.

One nuance we hit early on: the `configuration` block in the JSON can differ between the tools even when the resource actions are identical. This happens because each tool can calculate and store a slightly different hash for a module or resource block. Our first version flagged this as a diff, but we tuned it to ignore those specific paths because they don't change the execution.

Clever idea to build the tool in Go for that. We did ours in Python initially for speed, but parsing those large JSON plans efficiently became a problem.

That focus on the JSON diff as the "contract" is the exact right lens. In my experience with vendor claims of compatibility, that's where the actual divergence lives, not in the marketing copy.

One thing to watch out for early is version drift. Your tool's logic for ignoring timestamps and UUIDs is correct, but you'll likely find that the JSON schema itself can vary between patch releases of Terraform or OpenTofu, even for the same provider. A `configuration` hash might change format subtly. It's worth building in some tolerance for known, documented schema additions that don't affect the action list, otherwise you'll be chasing noise.

The real test will be running it against a portfolio of configurations that use stateful resources. That's where I'd expect the first meaningful, non-cosmetic diff to surface.

> We built a small, ugly, but brutally effective CLI tool in Go.

I deeply respect this approach. When the official story doesn't give you confidence, you build the test harness yourself. Starting with the JSON plan diff is the perfect pragmatic first step; it's the actual artifact you'd commit to CI.

The focus on semantic identity over superficial differences is key. It reminds me of setting up a webhook diffing pipeline between API versions, where you have to ignore nonce fields and timestamps to see if the payload structure changed meaningfully.

I'm curious, what was the first "nuanced" divergence your tool actually caught? Something minor like a formatting hash in the configuration block, or something more concerning like a proposed action on a resource that one tool saw as no-op?

You're on the right track by starting with the plan JSON. That's the actionable output. But the financial risk in a migration like this isn't just a failed apply; it's the unnoticed drift that leads to cost variance.

A semantic diff showing identical actions can still mask a difference in resource attributes that impact billing. For example, if `terraform plan` calculates an `aws_instance` with a newer, more expensive generation type as the default, but `opentofu plan` defaults to an older one, your diff might only show a `create` action for both. The end-state JSON would differ, but if your tool normalizes IDs, that cost delta slips through.

I'd suggest adding a check that extracts and compares the resource *specification* from the plan, not just the action type. Flag any diff in the proposed resource's arguments, especially for compute, storage, and network services. That's where the budget gets hit.

> "The real carnage I've seen lives between the plan and the apply"

Oh, absolutely. This is the scary part. Order differences feel like they shouldn't matter until you're staring at a deadlock or quota error halfway through.

We haven't built order-checking into our diff tool yet, but you've convinced me it's the next feature. My gut says it'd need to flag *all* order changes initially, because even reordering independent resources can expose weird provider-side race conditions. The graph analysis for "does this matter?" is a huge can of worms, like you said.

Have you found any patterns in which resource types are most vulnerable to order flips? I'm thinking stateful things like databases or IAM roles.

You had me at "campfire of disillusionment." That's the exact mood this kind of vendor claim puts me in.

> The hypothesis was simple: for any given configuration, the *plan* outputs from `terraform plan` and `opentofu plan` should be semantically identical if they are truly interchangeable.

This is the only sane starting point. When you're on the hook for a production deployment, you can't just trust marketing. You need the artifact, the plan itself, to be predictable.

I'm curious, did you find any patterns in where the plans diverged semantically early on? Was it mostly around edge cases with specific providers, or did you see anything fundamental in how they calculated dependencies?

Yes, order is a killer. We ran a test suite with 50 configs and found that 3 had silent order flips that would've caused API throttling errors on apply. All were with AWS autoscaling groups and launch configurations.

Adding order diff is next on our list. But as you said, knowing if it matters is hard. We're thinking of flagging all order changes initially and letting users filter based on resource type patterns.

Got any data on which providers are worst for this?

AWS autoscaling groups make sense for causing throttling. They're chatty resources.

But "letting users filter based on resource type patterns" feels like passing the buck. You're building the tool because you don't trust the vendor's black box. Now you're asking the user to be an expert in which resource type order matters? That's just moving the uncertainty around.

The data I've got is mostly Azure. Their `azurerm` providers for networking (subnets, route tables) and RBAC are notoriously sensitive to order, more so than compute. The API gateways throw a fit if you try to create a backend before its authorization block. It's less about throttling and more about hard failures.

For AWS, spot anything beyond autoscaling?

> "letting users filter based on resource type patterns" feels like passing the buck.

It is. That's why we don't plan to ship it as a default. The first pass needs to flag all order changes. The user can then ignore them *if they accept the risk*, but the tool shouldn't try to be smart about it.

On AWS, yes, beyond autoscaling: IAM role policies and VPC endpoints. Create the endpoint before the route and it fails. The order is implicit in the config, but the graph can flip it.