Migrating from Excel to Power BI: where to start

Why most migrations take longer than expected

The most common mistake is starting where it seems most logical, opening the spreadsheet and rebuilding every formula in Power BI, sheet by sheet. It looks like the direct path, but a spreadsheet that's been running for years isn't just a set of calculations, it's also the patches someone added for specific cases, the columns nobody uses anymore but nobody deleted, and the odd formula that was quietly compensating for an error somewhere else.

Copying all of that into Power BI doesn't move the report; it moves the patches too, now inside a tool where they're harder to find and fix.

The report matters more than the file

Before opening Power BI, the question isn't "what does this spreadsheet contain?" but "what decision does someone make with this number?" The goal isn't to migrate a file. It's to migrate one specific report you already know gets used, the one opened every Monday, the one sent at every close.

That deliberately leaves out the tabs nobody looks at, the old versions kept "just in case," and the calculations built once for a one-off question. If it isn't clear what a part of the spreadsheet is for, that's the sign it doesn't need migrating.

What you take with you, and what you leave behind

You take the business logic, that is, how margin is calculated, what counts as a closed sale, how spend gets split across departments. Those rules don't change just because the tool does.

You leave behind the logic that only exists because that's how Excel works, things like helper columns for sorting, formulas split into several steps because one cell ran out of room, or tricks to make a chart look right. Power BI solves those problems differently, and dragging the old fix along only adds complexity that isn't needed anymore.

The order that avoids doing the work twice

Data model first, visuals second. It's tempting to start with the charts, because they're what's visible and what you can show early, but a poorly thought-out data model forces you to rebuild reports the moment the first unplanned question shows up.

The order that works is this. First, which tables are needed and how they relate to each other; then, what each figure actually measures and under what name; and only then, how it looks. Changing a report already built on a solid model is quick. Changing the model after ten reports are built on top of it isn't.

What to do with the formulas nobody remembers the reason for

Almost every multi-year spreadsheet has one. The question to ask isn't "how do I translate this?" but "can anyone explain, today, why this exists?" If the answer is no, it's a candidate to be left out of the migration, and reviewed separately, because a formula nobody understands was already a risk before anyone touched it.

What to do with this

Migrating from Excel to Power BI isn't a translation task, it's a chance to keep only what the report actually needs. Order matters more than speed. What matters is defining which report, with what logic, on what model, before building anything visual.

I automate exactly this kind of migration, always starting with that upfront work. The first meeting is one hour, free of charge. It's there to see what you have today and whether it's worth it, before you commit to anything.