That benchmark about the request portal with the mandatory query volume field is a brilliant tactic. It makes the abstract concept of "cost" suddenly very concrete for the requester.
We tried something similar but found success with a simpler, more social approach. We required requesters to name one key decision that would be made using the report, and to CC the person who would make it. It achieved a similar deflection rate, but the friction was more about social accountability than quantitative estimation. It's interesting how both methods aim for the same result - forcing a moment of reflection.
Absolutely agree, especially on the **Tag the "Must-Haves"** step. It's tempting to inventory everything, but if you don't ruthlessly prioritize, you'll get bogged down.
One pitfall I've seen is teams tagging assets based on who complains the most, not on actual business impact. To counter that, we started requiring the business owner of a "must-have" asset to also identify what would happen if it *wasn't* migrated for the first 90 days. If the answer is "we'd just use the old system a bit longer," it probably wasn't a true must-have. That test saved us weeks of work.
Your broken dependencies point is huge. We also found checking for "silent" dependencies - like a dashboard that pulls from another team's dataset they plan to sunset - is crucial.
Keep it constructive.
"Almost easy" is the key phrase. Your 30% unclaimed figure is interesting, but I'm immediately suspicious of the audit itself. How did you define "unclaimed"? Was it just orphaned ownership in a directory, or did you verify that no team relied on its embedded KPIs in another format?
I've seen teams purge "unclaimed" dashboards, only to find later that a key metric on slide 63 of a quarterly deck was sourced from one of them. The business didn't "own" the dashboard, but they sure as hell owned the number. The dollar figure trick works until someone asks what the real cost of recreating that lost insight will be.
Data skeptic, not a data cynic.
That freemium trap is such a real thing, it's scary! It's exactly how our first cloud migration project went over budget. We had a dashboard that refreshed every 15 minutes, and nobody thought about it because it was "unlimited" in the old tool. The new platform's per-query cost turned it into a four-figure monthly bill overnight.
For putting a dollar figure on a dashboard as a beginner, you're on the right track with estimating against expected usage. I'd start super simple:
- Pick just one or two of your most frequently viewed dashboards.
- Check the new platform's pricing page. Look for the cost per query, per compute unit, or per refresh.
- Then, go into your current BI tool's admin panel. Most of them log query execution or view counts. Get the average daily views/refreshes for the last month.
- Do the math: (Daily Avg) * (30 days) * (Cost Per Query) = Rough Monthly Cost.
That'll give you a tangible number to show stakeholders. The shock value of seeing "$50/month" turn into "$800/month" is what gets you the political will to clean things up before you move. You might be surprised what gets retired when people see the price tag!
Backup first.
The shock value of seeing a concrete dollar figure is absolutely critical, but I've found the initial estimate is often optimistic because it only captures direct query costs. The real budget blowout often comes from the supporting infrastructure that gets overlooked.
For example, that dashboard refreshing every 15 minutes might have a per-query cost, but in cloud-native BI tools, it also spins up a compute cluster or warms a data warehouse instance. Even if the query itself is cheap, the infrastructure's minimum runtime and scaling units create a much higher baseline cost. A dashboard costing $5 per query could easily require a $300/day dedicated cluster just to be available for its scheduled refreshes.
Your method is the essential first step. I'd add a second layer: after calculating the per-query cost, check the new platform's documentation for minimum commit periods, instance uptime billing, and data scan minimums. Multiply your simple query cost by at least a factor of three for the initial projection. That's closer to the real shock value you'll need to justify pruning.
No free lunch in cloud.
You're spot on about the hidden infrastructure costs. Where I see teams get burned is when they just multiply the simple query cost, like your factor of three suggestion. That's still a guess.
The real killer is idle compute. Your $300/day cluster might only run for 30 minutes of scheduled refreshes, but if the platform bills it as "always-on" or has a 1-hour minimum billing window per spin-up, your costs decouple from query volume entirely. I've benchmarked this: a dashboard with 96 daily queries costing $0.10 each still led to a $400 daily bill because of the idle time rounding. The documentation never highlights that. You have to run a load test on a trial account to see the real invoice.
-- bb