Skip to content
Notifications
Clear all

Hot take: If you're on a stable CloudFormation setup, stay put. The grass isn't greener.

4 Posts
4 Users
0 Reactions
4 Views
(@cloud_cost_auditor)
Estimable Member
Joined: 3 months ago
Posts: 106
Topic starter   [#234]

Alright, I've been pulled into three of these "let's migrate to Terraform" projects in the last year. Every single time, the business case was built on vibes and developer sentiment, not numbers.

The pitch is always the same: "CloudFormation is clunky, HCL is more readable, the ecosystem is better." Fine. But has anyone actually run the TCO projection for a *stable* stack? I'm talking about:
* Engineering months for the state migration and refactoring. Did you cost that at fully loaded salary + benefits?
* The inevitable debugging of imported resources that don't map 1:1. How many production issues were budgeted?
* Ongoing cost of now maintaining two IaC knowledge bases (if you do a partial migration) or retraining everyone.

I once saw a team burn 5 person-months to move a few dozen stacks, only to realize their clever new Terraform modules didn't handle drift detection the same way. Their "savings" from more efficient deployments were eaten in the first week by a minor Azure VM SKU change that went unnoticed.

If your CloudFormation works, it's declarative, and it's auditable... what's the actual ROI? Show me the break-even analysis where the migration costs are offset by tangible operational savings. Not hypothetical developer happiness points.

I'm genuinely asking: has anyone here done a full migration *and* tracked the before/after numbers on cost, deployment frequency, and incident rates? Or did you just trade one set of quirks for another?

-auditor


Show me the bill


   
Quote
(@observability_watcher_2025)
Eminent Member
Joined: 5 months ago
Posts: 24
 

Yeah, the "vibes and developer sentiment" part rings so true. I'm new to this, but I've already seen a push for a Terraform move because "the docs are nicer." That's not a project plan.

Your point about drift detection costing them real money is interesting. That's an observability and alerting issue too, right? If they had better detection on the Azure side, maybe they catch that SKU change regardless of IaC tool. Makes me wonder if the effort is better spent on monitoring the stack you have, not rebuilding it.



   
ReplyQuote
(@crm_pragmatist)
Estimable Member
Joined: 2 months ago
Posts: 98
 

Exactly. Monitoring the stack you have is almost always the higher ROI play. I've watched teams burn cycles migrating IaC while their actual infrastructure had zero alerting for cost spikes or degraded performance.

The "docs are nicer" argument falls apart when you realize half your team's Terraform questions will be answered by the provider's own docs, not HashiCorp's. And those are often just as messy as CloudFormation's.

Invest in drift detection and guardrails first. If your current setup is stable but opaque, making it transparent is cheaper than rebuilding it.



   
ReplyQuote
(@martech_hopper_22)
Trusted Member
Joined: 3 months ago
Posts: 48
 

>what's the actual ROI?

This is the gut-check question. I tried Terraform for a new greenfield project last year. Sure, HCL felt cleaner.

But when I tried to run a cost projection for migrating our *existing* campaigns setup, the numbers fell apart. The "ecosystem" benefit vanished because we'd still need to write custom modules for our specific martech glue. That's the same dev work, just a different syntax.

The real cost no one talks about is the distraction. My team would have stopped building new lead flows for a quarter to rebuild what already works. How many pipeline conversions is that worth? Zero.


Trial number 47 this year.


   
ReplyQuote