Excel to Power BI Migration Checklist

Most spreadsheet-to-Power-BI projects fail for predictable reasons: someone rebuilds a dashboard before understanding which numbers actually matter, or ships it before confirming the totals match the workbook everyone trusts. A disciplined sequence prevents both. For the platform vendor's own framing, Microsoft's Power BI migration overview (opens in new tab) is a useful companion to the steps below. Work through them in order; each one assumes the previous is done.

Step 1: How do you inventory the Excel workbooks worth migrating?

Catalog every workbook and report your team relies on before touching Power BI. List each file, its owner, who reads it, how often it updates, and where its data comes from. This inventory is the single most skipped step, and the one that prevents nasty surprises later.

For each workbook, capture a few facts: the file name and location, the business owner and audience, the refresh cadence (daily, monthly, ad hoc), the source systems feeding it, and a rough sense of complexity — is it a flat data dump, or a tangle of VLOOKUPs, pivot tables, and macros? A simple tracking spreadsheet with one row per workbook is enough. The goal is a complete, honest picture of the spreadsheet estate so that no critical report gets forgotten and no effort gets wasted rebuilding something nobody opens.

Step 2: How do you decide what to migrate — and what to leave behind?

Not every workbook deserves a place in Power BI. Score each item on usage and value, then sort it into one of three buckets: migrate, retire, or leave as-is. Be ruthless — the best migration shrinks the reporting footprint rather than faithfully reproducing every legacy quirk.

Good candidates to migrate are reports with real readership, recurring refresh needs, or numbers that drive decisions. Good candidates to retire are duplicates, abandoned files, and one-off analyses that no longer run. Some workbooks should simply stay in Excel — lightweight personal calculators, scratch models, or genuinely ad hoc work where a spreadsheet is the right tool. Rank the migrate list by impact so you tackle the highest-value reports first and earn momentum. This is also the moment to consolidate: three near-identical regional workbooks usually become one parameterized Power BI report.

Step 3: How do you design the data model as a star schema?

The biggest mistake migrators make is copying the spreadsheet's shape into Power BI. Don't. Instead, reshape the data into a star schema (opens in new tab): narrow fact tables holding the events and measurements, surrounded by dimension tables for the descriptive attributes you filter and group by.

In practice, that means separating what Excel usually crams into one wide sheet. Transactions, sales lines, or journal entries become a fact table. Attributes like customer, product, region, and especially date become dimension tables linked to the fact by keys. Build a dedicated, gap-free date table — it is the foundation for every time-based comparison you will write later. A clean star schema is what makes Power BI fast, makes DAX measures behave predictably, and makes totals tie out. If the model is wrong, no amount of clever formula work will save the report. Sketch the relationships on paper before you build them; ten minutes of design saves hours of rework.

Step 4: How do you move the logic from Excel formulas to DAX and Power Query?

Excel logic splits cleanly into two homes in Power BI. Row-level shaping — cleaning, merging, splitting, and reshaping source data — belongs in Power Query (opens in new tab). Aggregations and business calculations — the things that respond to filters — belong in DAX measures. Sorting each formula into the right layer is the heart of the migration.

Use Power Query to replace the manual prep work that lives in helper columns and copy-paste rituals: trimming text, changing types, unpivoting cross-tab layouts, removing blank rows, and combining files from a folder. Use DAX measures to replace the SUMs, AVERAGEs, SUMIFS, and pivot-table aggregations that summarize data. A SUMIFS across a flat sheet typically becomes a single CALCULATE measure that works across every slice automatically. If you are new to the language, our explainer on DAX measures vs calculated columns covers the distinction that trips up most beginners. Resist the urge to recreate calculated columns for everything — measures keep the model lean and the numbers correct under filtering.

It helps to hold a mental map of where each familiar Excel construct lands in Power BI. The table below pairs the spreadsheet techniques most teams rely on with their Power BI equivalents, so you can see at a glance how the work is reframed rather than recreated.

Step 5: How do you validate that the numbers tie out to Excel?

This is the step that earns trust, and the one you cannot skip. Before anyone sees the new report, prove that its numbers match the workbook they replace — to the cent. Pick a set of known figures from the spreadsheet and confirm Power BI reproduces them exactly across multiple filter combinations.

Build a parity check: take grand totals, subtotals by region or month, and a few edge-case rows from the trusted Excel report, then verify Power BI returns the same values. Test the filters too — a measure can match on the grand total yet drift once you slice by quarter, which usually points to a relationship or date-table problem. Document each comparison so stakeholders can see the evidence. When numbers disagree, the cause is almost always the model or a misread filter context, not a typo in a formula. Do not move on until everything reconciles; a single wrong number erodes confidence in the whole platform, and rebuilding that trust is far harder than getting parity right the first time.

Step 6: How do you set up scheduled refresh so reports stay current?

A migrated report is only useful if it updates itself. Publish the dataset to the Power BI Service, connect its sources, and configure a refresh schedule that matches how often the underlying data changes. This is what finally ends the manual copy-paste-and-email cycle that spreadsheets demand.

If any source sits on-premises — a file share, a local SQL server, an on-prem database — you will install and configure the on-premises data gateway (opens in new tab) so the Service can reach it. Set credentials, choose a refresh frequency aligned to the source (daily for sales, monthly for finance close), and turn on failure notifications so a broken refresh reaches a human instead of silently going stale. Confirm the first few scheduled runs succeed and that the data lands as expected. Reliable, hands-off refresh is one of the clearest wins of leaving Excel behind, so it is worth getting the plumbing right rather than leaving it half-configured.

Step 7: How do you plan the rollout and train the team?

Technology rarely sinks a migration — adoption does. Plan a deliberate rollout: share the new report with a small pilot group, gather feedback, then widen access. Pair the launch with training so people know where their numbers went and how to use the new tools confidently.

Run a short pilot with the report's heaviest users; they will catch the gaps a builder misses and become your advocates. Provide focused enablement — how to filter, drill, and export, plus where to ask questions — rather than a generic Power BI course. Keep the old workbook available in parallel for a brief, defined overlap so nervous users can sanity-check the new report against the familiar one. Set a firm end date for that overlap, though, or the spreadsheet will live forever. If your team wants structured help building this skill in-house, our training and support is designed exactly for this handoff moment.

Step 8: How do you decommission the old Excel workbooks safely?

The migration is not finished until the spreadsheet stops being the source of truth. Once parity is proven and the team has adopted the Power BI report, formally retire the legacy workbook. Announce the cutover date, archive a final copy for the record, then lock or remove the original so it can no longer drift.

Decommissioning matters because parallel reports are dangerous: the moment two versions of a number exist, people quote whichever supports their argument, and the spreadsheet quietly diverges from the governed model. Communicate the change clearly, move the archived file somewhere read-only, and update any links, emails, or processes that still point to the old workbook. Confirm nobody is silently maintaining a shadow copy. A clean decommission is what locks in the value of the entire migration — one trusted, refreshing, governed report instead of a sprawl of competing spreadsheets.

What does this checklist cost, and where can you get help?

Effort scales with the model, not the visuals: a flat data dump migrates in hours, while a macro-heavy financial workbook can take weeks of modeling and validation. Budget accordingly, and weigh licensing before you commit.

If you are sizing a project, our breakdown of Power BI cost and licensing explains what really drives the total. And when you would rather hand the whole sequence above to someone who has run it many times, our migration to Power BI service takes a spreadsheet estate from inventory through decommission — with parity validation built in so the numbers tie out before anyone signs off.