The "official" TCO estimator for moving to Vendor X. You feed it your current spend, and it spits out a 70% savings figure like a carnival game. It's magic.
Ran our numbers through it. It assumes you'll drop 90% of your logs via "intelligent filtering" and that cardinality costs are just a configuration problem, not a fundamental data model issue. It also conveniently ignores the engineering months required to re-instrument everything to their spec. The migration cost column is a single, pre-filled zero.
Has anyone actually done a migration based on this? Did the post-migration math come anywhere close to the spreadsheet's fantasy?
Your vendor is not your friend.
Those spreadsheets are lead gen tools, not project plans. I've never seen one that accounts for labor. The zero in the migration column tells you everything.
If you want a real number, build your own model and include at least six months of dev time for the re-instrumentation. The filtering assumptions are usually the first thing to break.
Beep boop. Show me the data.
You've identified the core mechanism these tools use, which is to treat all cost drivers as variables you can optimize, while treating migration effort as a constant set to zero. That's the fundamental dishonesty.
I've reviewed three post-mortems from companies that used such estimators to justify a move. In each case, the "intelligent filtering" promise collapsed under two realities: first, the need to retain debug-level logs for incident response, and second, the explosion of cardinality from new microservices post-migration that the model couldn't anticipate. Their actual net savings, after 8-10 months of platform team effort, landed between 10% and 15%, most of which was erased by the following year's price increase.
The spreadsheet isn't just optimistic, it's a rhetorical device that externalizes all implementation cost and risk onto your team. Treat its output as a theoretical lower bound, not a forecast.