Migration to Power BI: A Practical Guide

What "BI migration" actually means

People use "migration to Power BI" to describe two very different projects. The first is a like-for-like port: rebuild the same reports the business already has, in the new tool. The second is a redesign: take the migration as the chance to fix the underlying data model, retire dead reports, and consolidate metrics that have drifted.

Most projects start as the first and get pulled toward the second the moment somebody opens the existing report library and sees how many duplicates there are. That's not failure scope creep — it's the migration doing its job. But you should decide which project you're running before you scope it, not after.

The four migration patterns

How you sequence the work depends mostly on appetite for risk and parallel cost.

1. Full replacement (cutover)

You rebuild everything in Power BI, validate it, then switch users over on a fixed date. The old tool is decommissioned shortly after. Lowest ongoing cost, highest cutover risk. Works when the report estate is small or the old tool's licence is genuinely about to expire.

2. Parallel run

Old and new tools both serve users for a defined period — usually 4–12 weeks. You compare numbers report-by-report and only retire the old tool once the business confirms parity. Highest licence cost during the overlap, lowest cutover risk. The default approach for any migration touching board-level reporting.

3. Hybrid (long-term)

Some reports stay on the old platform indefinitely — usually because they're embedded in a workflow that nobody wants to disturb, or because the old tool does one specific thing better. Pragmatic, but a "hybrid" that drags on three years usually means the migration was never really finished.

4. Greenfield (rebuild from data, not from reports)

Ignore the existing report library. Start from the source data, model it cleanly in Power BI / Fabric, and build the reports the business actually needs today — not the ones built in 2018 and never deleted. Most disruptive, best long-term outcome, hardest to sell internally because the value is invisible until reports start landing.

What to assess before you migrate

Six things matter, in roughly this order:

1. The report inventory. Pull a list from the source platform of every published report, who owns it, when it was last opened, and how often it's run. Half of what's there will be dead. Migration scope is the live half.
2. The data sources behind those reports. Where does each one pull from — a warehouse, a flat file, a direct database query, an API? This is what determines how long the rebuild takes far more than the visuals do.
3. Metric definitions. Find the top 10 KPIs and ask three different report owners how they're calculated. If the answers differ, you have a metric reconciliation problem to solve before you build anything in Power BI.
4. Refresh patterns and data volume. Hourly intraday refreshes on a 200M-row fact table need a different architecture than daily refreshes on 5M rows. This drives whether you land on Import, DirectQuery, or Direct Lake.
5. Security model. Row-level security and object-level security in the old tool need to be reproduced — not assumed. Audit who currently sees what before the cutover, not after.
6. Licensing reality. Power BI Pro per user, Premium Per User, Premium capacity, Fabric capacity — the right answer depends on user count, data volume, and whether you're using AI / Copilot features. Get this wrong and the project lands over budget on month one.

Rebuild the semantic model. Don't port it.

This is the single biggest decision in any Power BI migration, and the one most often skipped. The semantic model — the relationships, the calculated columns, the measures — is where Power BI either pays off or quietly turns into a slow, brittle copy of the old system.

If you import the old tool's data model directly, you inherit every accumulated workaround that made sense in 2019 and now doesn't. Calculated columns that should be measures. Bidirectional relationships papering over a missing dimension table. Measures that reference other measures that reference DAX from a custom extension that no one remembers writing.

Build a fresh model from the underlying source data. Let the old reports inform what the business needs, not how it should be expressed in Power BI.

"The semantic model is where Power BI either pays off or quietly turns into a slow, brittle copy of the old system."

Reproducing reports — the part that takes longer than you think

Migration timelines blow up on report rebuilds, not on infrastructure. The reasons are predictable:

• Visuals that exist in Tableau or MicroStrategy don't always have a 1:1 equivalent in Power BI. Sometimes you replace one custom visual with a combination of two native visuals; sometimes you accept a slightly different look.
• Pixel-perfect parity is the wrong goal. The right goal is "the user gets the same answer to the same question, at least as fast." Stakeholders sometimes need to be talked out of demanding identical layouts.
• Reports built by power users in the old tool tend to contain undocumented business logic. Rebuilding them surfaces that logic, which usually triggers a "wait, that's not how we calculate revenue" conversation. Budget time for that.

A useful rule of thumb: a competent BI developer rebuilds 1–3 reports per week, depending on complexity. Multiply by your live report count, add 30% for stakeholder review cycles, and you have a realistic timeline.

Cutover and adoption

The technical cutover — flipping users from the old tool to Power BI — is usually the easy part. The hard part is the few weeks after, when users hit edge cases that didn't surface during testing.

• Have a named owner for "this report doesn't look right" tickets, with clear SLAs. Without that, complaints route directly to whoever is most senior, and the project loses credibility fast.
• Plan three rounds of training, not one. Initial walkthrough at cutover, follow-up after 2 weeks (when the easy questions have come up), and a deeper session at 4–6 weeks for the genuinely advanced workflows.
• Don't decommission the old tool the day of cutover. Give yourself a 30–60 day window where it's still accessible read-only, in case something is broken in the new build that nobody noticed during UAT.

A realistic timeline

For a mid-market company with 30–80 active reports, two or three source systems, and a single semantic model:

Phase                      Typical duration
─────────────────────────────────────────────
Assessment & inventory     2–3 weeks
Semantic model build        3–6 weeks
Report rebuild              6–12 weeks (in parallel)
Parallel run / UAT          4–6 weeks
Cutover & adoption          2 weeks
─────────────────────────────────────────────
Total elapsed (typical)     14–24 weeks

Migrations that aim for <8 weeks usually achieve it by drastically narrowing scope — one critical report area, one source system, fixed-price. That's the model behind Frogsbyte's Fabric Fast-Track: deliberately constrained scope, predictable timeline, the rest of the estate handled in subsequent waves.

---

The pattern that most often makes a Power BI migration succeed isn't a tool, a methodology, or a vendor. It's deciding upfront whether you're porting reports or rebuilding the BI estate — and being honest about which one you actually have appetite for.