Most post-mortems on failed Power BI migrations focus on the wrong phase. Teams blame the cutover, the training, or the "change resistant" business users. In reality, by the time anyone drags the first legacy report into Power BI Desktop, the project has usually already failed. The damage was done weeks earlier, during discovery and planning, when nobody stopped to map what they were actually migrating away from.

This is not a generic "communication and planning matter" argument. It is a breakdown of the specific technical and organizational gaps that sink these projects before a single visual gets rebuilt, and it is exactly the gap that experienced Power BI migration services are built to close. Whether the work is handled in-house or through a Power BI migration partner, the same foundational questions have to be answered before rebuild work starts.

The Real Failure Point Is the Discovery Phase, Not the Cutover

When a company decides to move off Tableau, Qlik, SSRS, or a legacy Excel reporting stack, the instinct is to start rebuilding dashboards immediately. That instinct is the first mistake.

A migration only succeeds if someone has already answered three questions that have nothing to do with Power BI itself: what does each legacy report actually query, who has access to what data and why, and what business logic is buried inside calculated fields, set analysis expressions, or stored procedures that nobody has touched in three years. Skipping this step doesn't make the migration faster. It just moves the discovery work into the middle of the project, where it is far more expensive to fix, because by then people, budget, and executive patience are already committed to a timeline that assumed none of this friction existed.

Teams that succeed treat discovery as its own project phase with its own deliverable: a data source and logic inventory, signed off before any rebuild work starts. This is also the phase where the difference between a rushed internal effort and proper Power BI migration services shows up most clearly, since a good migration partner will not let rebuild work start until this inventory exists.

Five Foundational Gaps That Kill Power BI Migrations Before They Start

These are the specific failure points that show up again and again, regardless of industry or company size.

  1. No data source inventory. Nobody has a full list of every database, API, flat file share, and SaaS connector that legacy reports pull from. Reports get rebuilt against "the obvious" source, and three weeks in, someone discovers a report actually blends four different systems through a manual Excel staging step that one analyst maintains by hand.

     
  2. Capacity and licensing sized after the fact. Teams pick Power BI Pro licenses or a small Premium capacity based on user count alone, without modeling dataset size, refresh frequency, or concurrent query load. This gets discovered when the first large dataset hits the 1 GB Pro limit or refreshes start timing out on a shared capacity.

     
  3. Security model never mapped to row-level rules. Legacy tools often handle row-level security through folder structures, separate report copies per region, or database views. Power BI expects this to be expressed as RLS roles and DAX filter expressions. Nobody maps the old model to the new one until a regional manager reports they can see another region's revenue numbers.

     
  4. Business logic treated as a rebuild task instead of a translation task. Set analysis in Qlik, calculated fields in Tableau, and stored procedure logic behind SSRS reports encode real business rules, not just formatting choices. Rebuilding "the same chart" without extracting that logic first produces a report that looks the same but calculates differently.

     
  5. Gateway and connectivity readiness assumed, not tested. On-premises data gateway installation, service account permissions, and firewall rules for cloud connectivity get treated as an IT ticket to file later. Later usually means during UAT, when the whole project stalls waiting on a network change request.

     

Any one of these gaps is recoverable. Two or three of them together, undiscovered until midway through the project, are usually what kills the timeline and the stakeholder confidence that came with it.

The Licensing and Capacity Trap Nobody Budgets For

This deserves its own section because it is consistently underestimated. Power BI licensing is not a single decision, it is an architecture decision disguised as a procurement decision.

Per-user Pro licensing caps individual datasets at 1 GB and relies on shared, unpredictable compute. Premium or Fabric capacity licensing (F64 and above, or the older P-SKUs) removes that dataset ceiling and gives dedicated compute, but it has to be sized against actual workload: how many datasets refresh concurrently, how large the biggest fact tables are, and how many users will hit paginated or large-model reports during peak hours. Organizations that size capacity off headcount alone, rather than workload, routinely end up either overpaying for idle capacity or hitting throttling and refresh failures within the first quarter.

The practical fix is to run a workload estimate before licensing is purchased, not after. Pull the row counts and refresh schedules of the largest three or four legacy reports, estimate the equivalent dataset size in Power BI's compressed VertiPaq format (typically a fraction of the source database size, but not always, depending on cardinality), and size capacity against that, with headroom for growth. This single step avoids most of the "why is our refresh failing" tickets that show up in month two.

Why Legacy Report Logic Doesn't Translate Cleanly

A report that looks identical after migration can still be wrong, and this is where trust in the new platform erodes fastest. This is also where the gap between a Tableau to Power BI migration, a Qlik to Power BI migration, and an SSRS to Power BI migration becomes obvious, since each source tool hides its business logic in a different place.

Tableau calculated fields and Qlik set analysis expressions are procedural in a way DAX is not. In a Tableau to Power BI migration, calculated fields that reference table calculations or level-of-detail expressions need to be re-derived as DAX measures with the correct filter context, not copied as formulas. In a Qlik to Power BI migration, a set expression like excluding the current selection and applying a fixed date range behaves differently from a DAX measure using CALCULATE with explicit filter arguments, because DAX's filter context propagation follows different rules than Qlik's associative model. An SSRS to Power BI migration carries its own risk: SSRS reports often lean on stored procedures that apply business rules directly in SQL, logic that has to be either pushed into the Power BI data model, kept in a SQL view, or rebuilt as DAX, and each choice has different performance and maintainability consequences.

The failure pattern is consistent: someone rebuilds the visual layer, the chart looks right in the demo, and three weeks after go-live finance flags that a number doesn't match the legacy system. Nobody can explain why, because nobody documented what the original calculation actually did before they replaced it.

The fix here isn't more testing at the end, it's logic extraction at the start. Every calculated field or set expression in a report scheduled for migration should be documented in plain language (what business rule it enforces) before anyone touches DAX. That document becomes the acceptance criteria for the rebuilt measure, not the visual similarity of the chart.

A Practical Pre-Migration Checklist

Before any report gets rebuilt, these items should be closed out, not scheduled for "later in the project."

  1. Full inventory of data sources per report, including undocumented manual steps (Excel staging files, manual CSV drops, personal database credentials).
  2. Workload-based capacity sizing, not headcount-based licensing decisions.
  3. Row-level security model mapped from the legacy tool's access pattern to explicit Power BI RLS roles, tested with at least one user per access tier.
  4. Business logic extracted into plain-language documentation for every calculated field, set expression, or stored procedure feeding a report in scope.
  5. Gateway installation, service account permissions, and firewall rules validated in a test environment, not assumed to work in production.
  6. A source-of-truth decision for any report that currently pulls from more than one system, since Power BI's data model may need a different join strategy than the original tool used.
  7. A rollback plan for the cutover window, since running legacy and new reports in parallel for a short period catches discrepancies before they reach end users.

None of these steps require Power BI expertise to complete. They require someone willing to do unglamorous discovery work before the "real" project starts, which is exactly why they get skipped.

When an In-House Team Should Bring In Power BI Migration Services

Not every organization has the bandwidth to run the discovery work above while also keeping the lights on for existing reporting. That gap is exactly what dedicated Power BI migration services exist to fill, and it is worth recognizing the signs early rather than after the timeline has already slipped.

  • The legacy environment spans more than one BI tool, and no single person on staff understands all of them well enough to document the underlying logic.
  • Nobody in-house has sized a Premium or Fabric capacity before, and the licensing decision is being made on a guess rather than a workload estimate.
  • Row-level security in the legacy system is enforced through something informal, like separate report copies or manual access lists, with no documentation of the actual rule set.
  • The internal team's Power BI experience is limited to building reports, not to data modeling, DAX performance tuning, or gateway and capacity architecture.

A capable Power BI migration partner brings a repeatable discovery framework and has usually seen the same Tableau to Power BI migration or Qlik to Power BI migration failure patterns on other engagements, which shortens the time it takes to surface the risks described earlier. That does not mean every migration needs outside help. It means the decision to handle it internally should be based on an honest read of internal capacity and experience, not on the assumption that Power BI itself is simple enough that the surrounding architecture work will take care of itself.

What to Do Instead

Treat the first two to three weeks of any Power BI migration as a discovery sprint with its own deliverable, not as pre-work that eats into the "real" timeline. That deliverable is the inventory, the logic documentation, and the capacity plan described above. Only after that sprint produces a signed-off inventory should report rebuilding start.

Migrate in waves, starting with one low-risk, low-complexity report end to end, including RLS, refresh scheduling, and stakeholder sign-off on the numbers. This surfaces gateway, licensing, and logic-translation problems on a small scale, where they're cheap to fix, instead of on the twentieth report, where they're not.

Run legacy and rebuilt reports in parallel for at least one full reporting cycle before decommissioning the old system. A parallel run is the only reliable way to catch the quiet calculation mismatches that visual inspection misses.

The organizations that get this right don't have better Power BI developers. They have a discovery process that treats the legacy environment as something to be understood before it's replaced, not something to be guessed at while the new dashboards are already being built. Whether that discipline comes from an internal team or from a Power BI migration services provider, it is the actual predictor of whether the project lands on time and on budget, not the visual polish of the first rebuilt dashboard.