The obsession with picking the "best" IaC tool is a waste of cycles. I've managed Salesforce and HubSpot ecosystems where the data model and process integrity mattered infinitely more than the tool used to build it. The same principle applies here.
I've seen teams paralyzed evaluating Terraform vs. Pulumi vs. CDK for six months. Meanwhile, a team with a mediocre tool but a locked-down, consistent pattern for deployments (and rollbacks) is shipping infrastructure daily.
The real value is in the pattern:
* A single, well-defined pipeline for plan/apply/destroy.
* Immutable versioning of both code and state.
* A mandatory, machine-readable review process for changes.
* Consistent module structure, even if it's just `modules/` directory.
Example: Your deployment pattern should be so rigid that switching tools is just a translation exercise. The painful part isn't the new HCL or YAML; it's the lack of a pattern forcing you to redesign your entire workflow.
I migrated a client from CloudFormation to Terraform last year. The state import was a technical nuisance. The real effort was refactoring their 50 "snowflake" templates into a reusable module structure—something they should have had from day one. The migration was worth it only because it forced that discipline.
Bottom line: Argue about your deployment pattern first. Once that's settled, any mainstream tool will do the job. The tool didn't save you; the process did.
Show me the query.
Completely agree, but I'd frame it as a security and governance necessity rather than just an efficiency win. Your point about the pattern being so rigid that tool switching is just translation is key.
A consistent deployment pattern creates a predictable, auditable security boundary. When you have that single pipeline for plan/apply/destroy with mandatory review, you've effectively built a compliance and least-privilege engine. The tool just defines the syntax of the policy; the pattern enforces it. I've seen teams with "the best" tool fail their SOC2 audits because their deployment pattern was ad-hoc and permissions were sprawled across three different CI systems.
Your migration story hits home. The threat model shifts from "does this tool have a vulnerability?" to "can we verify and trust the change process?" The latter is vastly more important.