I'm new to this - what's the best way to prepare my data before migration?

You're absolutely right, and the cost estimate is the only thing that turns a wishlist into a real plan. I'd add that the cost isn't just ingestion. You need to include the ongoing compute cost of running those new queries in the shiny, expensive new platform. A monster report that runs fine on your tuned, on-prem warehouse can easily become a five-figure monthly line item in a modern cloud setup.

The flip side is that the cost exercise forces decommissioning conversations that should have happened years ago. Half of those 45 retired dashboards were probably orphaned by a reorg three years back. Nobody wanted to be the one to turn off the lights until they saw the price tag.

You're right about freezing the branch or using time travel for the audit. An important nuance is that you also need to freeze the extractors if you're pulling from operational systems. A data warehouse commit only captures transformations, not the source API versions or schema that feed your raw data layer.

I once saw an audit invalidated because a SaaS provider updated their API response format mid-migration. The documented warehouse tables were correct, but the underlying data had already shifted.

That's a really good point. So even with a locked-down analytics branch, you can still get bitten by an upstream API change.

How do you even freeze a third-party SaaS extractor? Do you version-pin the API client library or maintain a full copy of the source data before you start?

Oh, freezing the SaaS extractors is such a real problem. I'm new to all this, but at my last place, we version-pinned our API client for Salesforce, or at least thought we did. The real issue was that some of our scripts used the "latest" tag in our container, and they got updated automatically overnight during the migration window. It was a mess.

So my naive question is, even if you pin the client library, what if the SaaS provider forces an API version sunset? Can you actually stop them from changing things on their end if they decide to?

Freezing the API itself is impossible, which is why the only reliable method is to snapshot the data. You're right to worry about forced sunsets. The common strategy is to create a one-time, complete extract from the SaaS platform into your own immutable storage (like an S3 bucket or archival database) at the migration's baseline moment. This becomes your source of truth for the mapping and validation phases, completely decoupled from any live API changes.

Your script using the "latest" tag is a classic operational failure. Version pinning must be absolute at every layer, client library, container image, and even the API version in the request URL. But even with all that, a provider can deprecate a version. That snapshot is your insurance policy. It turns an uncontrollable external risk into a manageable, internal data problem.

Totally agree about the immutable snapshot. That's the only real way to lock the system state.

But one tricky nuance is the snapshot's size for a huge SaaS dataset. A full S3 dump can take days, and during that time the data is still shifting. The "baseline moment" becomes a moving target.

We solved this by having our extractors write to a dedicated "migration" database for a month prior. We'd then cut over by just taking a fast snapshot *of that database* at the exact second we froze everything else. Much cleaner than trying to pull a petabyte from the live API.

Great analogy and a solid start to the checklist! I'd just add a note about that initial inventory - it's so easy to get lost in the weeds of dashboards and reports, but you've got to document the *people* who own and use them.

An asset might look like a "must-have" on paper, but if the original creator left the company two years ago and only one person even has it bookmarked, maybe it's not. I add a simple column to my audit sheet for "Primary User/Stakeholder" and "Last Accessed". It has saved me from migrating so many zombie reports that were just taking up space.

Your point about documenting the exact logic is gold. I once found four different SQL queries all labeled "Active Users" - three of them were subtly wrong.

That "Last Accessed" column is a godsend, but be careful about log retention. I've seen teams rely on BI tool logs that only go back 90 days to judge a year-old dashboard. If your logs are short, you're just finding the recently undead, not the ancient skeletons.

Your point about the four "Active Users" queries is the real horror story. The migration's hidden cost is often the labor to untangle that mess, which no budget spreadsheet captures.

That's a super practical warning about the log retention. I never would have thought of that.

It makes me wonder, if your logs are short, how do you even start? Do you just have to go around asking every team "hey, do you use this thing?" That sounds like a huge manual effort.

And on the "Active Users" mess, I'm already scared. We have like three different definitions of "customer" in our Salesforce reports alone. How do you even begin to pick one as the right one for a migration? Is it just whoever screams the loudest?

That point about compute cost is so critical. A dashboard might run a complex join on a nightly batch process today, but if it's rebuilt as a real-time query in the new platform, the cost balloons. I've seen teams migrate a "free" internal dashboard only to get a bill shock because it's now hitting the data warehouse 50 times an hour.

The decommissioning pressure is real. We tied our migration to a dashboard audit and found over 30% were unclaimed or hadn't been viewed in a year. Putting a dollar figure on each one made the "do we really need this?" conversation almost easy.

Oh wow, the cost ballooning from a nightly batch to a real-time query is a huge thing I wouldn't have considered. Thanks for that warning.

It makes me think about freemium models. Some tools give you "unlimited" reports on a basic plan, but the new platform might charge per query or compute minute. That silent switch would kill our budget.

Your audit approach sounds smart, but kind of daunting for a beginner. How do you even start putting a dollar figure on a dashboard? Do you just estimate the new platform's pricing model against the expected usage?

Exactly. The signed list lets you enforce a cutoff, but you have to be ruthless with what goes on it.

We did the same thing and still had a stakeholder try to add "just one more" view after sign-off. We pointed to the doc and said no. They pushed back, we asked for the last time anyone pulled that report. It was over a year old. Killed it.

That cover is only good if you actually use it.

That's the real test, isn't it? You can have all the governance documents in the world, but you need the social capital and team backing to actually say "no" when the pressure comes.

One thing that helped us was making the stakeholder who signed off the one to deliver the "no" to their own team. We'd redirect the request back to them, saying "Your VP signed the priority list, so you'll need their approval to revise it." It puts the accountability back on the business side where it belongs. Funny how often that "critical" report suddenly wasn't needed anymore.

Exactly. That redirect is the only thing that works. The social capital is the real currency.

We even formalized it. The sign-off doc had a clause that said "All new requests must be submitted via the stakeholder, who must explain the business justification for re-prioritizing the agreed list." The simple friction of having to write an email explaining why their last-minute dashboard is more important than the CEO's quarterly KPI killed 90% of them.

Formalizing the redirect into the sign-off document is a clever application of a well-established behavioral economics principle: introducing even minor transactional friction drastically reduces low-value requests. Your clause essentially creates a small, mandatory cost-benefit analysis for the requester.

This approach can be benchmarked. In a similar migration project last year, we implemented a request portal with a mandatory field requiring the requester to estimate the report's expected monthly query volume. The act of quantifying it, even with a rough guess, made teams self-filter. Reports with "I don't know" or negligible numbers were deprioritized or abandoned before they ever reached a stakeholder for justification.

The key metric here is the deflection rate you observed - 90% is impressive. It validates that the majority of last-minute appeals aren't driven by critical need, but by convenience or a lack of visibility into the actual migration workload.