Every few years, a platform decision lands on someone's desk. Tableau to Power BI. Tableau Server to Tableau Cloud. Power BI Report Server to the service. On-prem to Fabric. Cognos or Business Objects to anything modern. The business case writes itself: lower licensing, less infrastructure to maintain, better integration, AI features the old environment will never get. The vendor demos go well. A timeline gets locked in. Then the migration starts, and the trouble starts with it.

The trouble is rarely the new platform. The new platform usually works fine. The trouble is that most teams treat a BI migration as a tooling project when it is really a foundation project wearing a tooling project's clothes.

Same-tool moves — Tableau Server to Tableau Cloud, Power BI on-prem to the service — get the worst of this. The surface looks identical, so leadership scopes the project as a "host change" and budgets accordingly. Underneath, almost everything that matters is different: how content is organized, how permissions work, how data refreshes, how gateways and extracts behave, how users sign in. The work is real. The plan rarely reflects it.

"A migration is a rare excuse to fix what you've been working around for years. Most teams waste it rebuilding the workaround in a different tool."

The Lift-and-Shift Trap

The instinct is understandable. Users have hundreds of reports, leaders have favorite dashboards, and the path of least resistance is to recreate everything as-is in the new platform. Same charts, same filters, same logic. Get to parity, declare victory, move on.

The problem is that "everything you have today" usually includes years of accumulated workarounds. Reports built around a missing field. Filters that exist because two source systems disagree. KPIs whose definitions have quietly drifted from what the spec said five years ago. Replicating that mess in a shinier tool gives you the same mess with a new logo and a fresh bill.

Five Mistakes That Sink Most BI Migrations

The patterns repeat across organizations and across tools. The names change, the platforms change, the mistakes don't.

Migration Failure Modes
The five we see on almost every project
Treating it as a tool swap
A migration touches the data model, the semantic layer, security, refresh schedules, and how analysts work day to day. Scoping it as "rebuild the reports" misses everything underneath.
Migrating everything
Most BI environments have an 80/20 problem. A small set of reports does the real work. The rest are duplicates, abandoned, or built for one person who left two years ago. Migrating them all is how a six-month project becomes an eighteen-month one.
Re-implementing the same logic, badly
Tableau calculated fields don't translate one-to-one to DAX. Cognos filters and Power BI row-level security work differently. Copy-paste rebuilds produce numbers that look right and aren't, which is the worst possible failure mode for a BI tool.
No parity testing plan
If the new dashboard's revenue number is off by two percent from the old one, no one is going to use it. Getting to identical numbers, end-to-end, is harder than it sounds and rarely budgeted for.
Skipping enablement
Power BI is not Tableau is not Looker. Analysts who were fluent in the old tool become slow and frustrated in the new one. Without training and a clear pattern library, adoption stalls and shadow reporting comes back in spreadsheets.

None of these are technical surprises. They are scoping decisions. The teams that get migrations right make different decisions early, before the rebuild starts.

What a Good Migration Actually Looks Like

The shape is consistent across tools. Three phases, in this order, every time.

1
Inventory and Triage
Before rebuilding anything, catalog what you have. Usage, owner, business value. Most environments have 30 to 50 percent of reports that no one opens. Those don't migrate. They retire. The smaller the migration scope, the better the migration.
2
Rebuild the Foundation, Not Just the Reports
Use the migration to consolidate sources, redefine the metrics that have drifted, and rebuild the semantic layer cleanly in the new tool. Reports built on a clean model are easier to migrate, easier to maintain, and far less likely to disagree with each other.
3
Parity, Then Improve
Run old and new side by side. Reconcile the numbers until they match exactly. Only then ship the new versions and turn off the old ones. Once trust is established, use the new platform for the things the old one couldn't do, instead of trying to do both at once.

This sequencing matters more than any individual decision in it. Teams that try to inventory and rebuild and modernize at the same time end up with a half-finished migration and a fully-finished invoice.

"Parity first, then progress. Try to do both at once and you'll get neither."

Where to Start

If a migration is already on the roadmap, the highest-leverage thing you can do before any rebuild begins is the inventory. Pull usage data from the existing platform. Sit with the people who actually use the reports. Find the 20 percent of dashboards that drive 80 percent of decisions. That list, not the full report catalog, is your migration scope.

From there, the work is unglamorous but linear. Define the metrics. Build the model. Rebuild the priority dashboards on the new foundation. Reconcile the numbers. Train the people. Retire the old environment on a real date, not "eventually."

The migrations that quietly fail try to skip the unglamorous parts. The ones that pay off lean into them. The new tool is the easy part. The rest is the work.