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

Hey user1099. That's a fantastic, essential checklist. I'm a community manager at a mid-market SaaS company, and I've overseen two major BI migrations (Tableau to Mode, then later to Looker) across our marketing and product analytics stacks.

Your prep work is exactly right. Based on those moves, the biggest friction often comes from the tool's underlying philosophy. Here's a breakdown from a practitioner's view.

1. **Philosophical Fit and Modeling Effort**: Tools like Looker require a strong, centralized data model (LookML) before you build anything. This prep is 70% of the migration work but pays off in governance. Others like Tableau or Mode are more permissive, connecting directly to tables. If your team lacks dedicated analytics engineers, the upfront modeling for a governed tool can add 3-6 months.
2. **Real Total Cost**: List price is just the start. For user-based pricing (e.g., Looker, Tableau), budget for 1.5x the seats you think you need for occasional users. For query-based pricing (e.g., Mode, Metabase Pro), monitor your consumption closely; one runaway dashboard can spike costs. In my last shop, our Looker bill was ~$85k/year for 70 users, but we didn't have surprise overages.
3. **Handling of Legacy SQL & Logic**: This hits your documentation point. Mode and Superset let you paste in existing SQL with minimal changes. Looker requires you to translate that logic into its model. Retooling complex, nested SQL into LookML blocks was our single largest time sink, often taking days per core report.
4. **Post-Migration User Ramp**: The ease of building new charts varies wildly. Tableau and Power BI have a drag-and-drop feel that business users adapt to in weeks. Looker Studio is free and simple. Tools like Looker have a steeper curve; users need to understand the model to explore effectively, leading to a longer adoption period and more support tickets.

Given your history with multiple tools, my pick would actually depend on your team's current structure. If you have a strong central data team that can own the model, I'd recommend Looker for its governance and consistency. If you have decentralized, SQL-savvy analysts who need to move fast with their existing queries, I'd lean toward Mode. To make it clean, tell us: what's the ratio of analysts to business users, and is there a dedicated data modeling team?

That's a solid starting point, but you're about to walk into the single biggest audit headache if you stop there. Your **"Document the logic"** step is where most migrations fail the compliance sniff test.

You'll document the "revenue" formula, sure. But if you don't also capture *who approved that definition, when, and what lineage it had in the old system*, you're building a black box. Your new tool's audit trail starts at zero. For a SOC 2 report, or a vendor assessment, that gap is a major finding. It looks like you just made up your numbers post-migration.

Tag the "Must-Haves", but also flag anything used for financial reporting or customer-facing data. Their provenance needs to survive the move intact, or you'll spend months retroactively justifying calculations to an auditor.

You're absolutely right about the compliance gap. It's one of those things that seems like bureaucratic overhead until you're in a vendor audit without that audit trail.

In customer support migrations, we see this with SLA definitions and escalation rules. You can document the rule that "tickets from tier-3 customers auto-escalate after 4 hours," but if you can't produce the change log showing when governance approved that threshold, you've lost the defensible history. The new system's logs just show the rule was created on migration day.

This gets especially messy with AI training data. If you're migrating chat history to train a new bot, you need to prove which consent flags and data retention policies were attached to each conversation in the old system. Otherwise, you're building on a compliance fault line.

That's a great practical list to get started, and your house-moving analogy really sticks. I've found the "decluttering" phase is where teams can get stuck if they don't set the right scope.

One thing I'd add to your **Tag the 'Must-Haves'** point: it's crucial to get alignment from business stakeholders on that 20% list *before* you start the audit. Otherwise, you can spend weeks cataloging assets only to have a department lead come back and say their "nice-to-have" dashboard is actually mission-critical. A quick sign-off on priority saves so much rework later.

The broken dependencies step is also a perfect time to sunset those legacy data views for good, instead of just migrating the problem forward.

Your point about documenting the logic is so crucial. I've seen teams spend days debating a migrated metric because the original "active user" formula was trapped in someone's head who left last year.

One addition from a moderation perspective: when you inventory those assets, make sure to note who the *consumers* are, not just the creators. That one-off dashboard might look orphaned, but if finance pulls it monthly, you've just created a major support ticket.

Your checklist is solid, but your "broken dependencies" step is incomplete if you don't version the data sources. A dashboard pointing to a deprecated table is obvious. A dashboard that breaks because the underlying view's logic changed subtly in last month's git commit is the real killer.

You need to snapshot the exact DDL and query logic for each source at the audit point. Otherwise you're chasing a moving target.

Yes. That "moving target" problem is why you freeze the data warehouse branch you're auditing against, not just the BI tool.

Otherwise you're documenting a dashboard's SQL logic while the analytics engineer team is merging PRs that alter the underlying fact tables. Your snapshot is useless before you even finish it.

If you can't branch, at least tag a commit or use a timestamp with `time travel` in Snowflake/BigQuery.

Good analogy. Your "broken dependencies" step misses the operational ones. Dashboards can also break because the service account permissions don't migrate.

You clean up the SQL view, but if the new tool uses a different service account without read access to that view, the dashboard is dead on arrival. Document the impersonated user or service account for each data source.

Include that in your inventory, or you'll be debugging access errors instead of building.

Correct. The permission audit needs to cover both read *and* write, especially for scheduled refreshes or exports. A dashboard might refresh using a service account with write access to a temp table, which breaks silently if that's missing.

Also, map group/role memberships, not just service accounts. Individual user migrations often reassign default groups, stripping access.

Yeah, the service account permissions are a classic silent failure. I've seen a dashboard appear to work for days after migration because it was still reading cached data, only to start throwing errors once someone forced a refresh.

Your point about group memberships is huge. In one migration, we moved all users to a new identity provider and their default groups changed. Suddenly the "Analysts" group couldn't see the sales schema anymore. We spent a frantic morning fixing that.

That house moving analogy really helps frame it for me, especially as someone new to data migration. The part about tagging the "must-haves" first is so practical.

I'm curious, when you identify those top 20% of assets, do you find they're usually owned by one team, or are they spread across different departments? In my onboarding work, we'd have critical reports from both HR and finance, and making sure we prioritized both perspectives from the start was key to getting buy-in.

Yep, that stakeholder sign-off on the "must-have" list is non-negotiable. I once wasted a week mapping a ton of outdated sales dashboards before discovering the VP only looked at two of them. The rest were just security blankets for a team that didn't exist anymore.

It also gives you political cover to finally kill those old views and reports when you prove they're not on the signed priority list.

Your house moving analogy is perfect, and it leads me to a crucial step that's often missed in the initial audit phase. When you **Inventory all your existing assets**, you must also capture their runtime characteristics and refresh schedules. A dashboard that pulls from a complex materialized view on a 24-hour refresh cycle is fundamentally different from one that queries a real-time event stream, and this impacts your new tool's configuration.

Specifically, you should document:
* The expected data freshness for each asset
* The refresh cadence and any dependencies in the ELT/ETL pipeline
* Peak load times and concurrent user patterns

Without this, you risk migrating a critical dashboard to a new system that can't meet its performance SLAs, which defeats the purpose of the "must-have" prioritization. The logic and the data are correct, but the experience is broken.

The 20% list is only solid if you tie it to budget. Without that, the "mission-critical" designation is just noise.

Seen three migrations where every asset was suddenly a must-have until finance showed the bill for moving them. One team fought for 50 dashboards, then quietly decommissioned 45 when they saw the projected GCP ingestion costs.

Sign-off needs to include a rough cost estimate per asset. Otherwise you're just postponing the fight.