How to Publish to Power BI Straight From Excel and When It Actually Helps

Plenty of Australian businesses run on Excel and quietly wish they ran on Power BI instead. The data lives in spreadsheets, somebody emails the workbook around, and there's a vague sense that the numbers should be on a dashboard somewhere that updates by itself. Then they discover Excel has a "Publish to Power BI" button sitting right there in the File menu, and the obvious question follows: does that just solve the whole problem?

Sort of. It's a genuinely useful feature, and it's underused. But like most one-click bridges between two big products, it does a couple of different things depending on which option you pick, and the gap between what people expect and what they get trips up a lot of teams. Microsoft documents the mechanics well enough in their publish to Power BI from Excel guide. What that page won't tell you is when this is the right move and when you're better off doing something else entirely. After helping a fair few clients make this exact jump, here's how I'd think about it.

What "Publish" Actually Means Here

The first thing to get straight is that there are two separate things hiding behind the same button, and they behave very differently.

The first is upload. This takes your workbook and puts a copy of it into the Power BI service, where you and your colleagues can open it and interact with it in the browser, much like you would in Excel Online. PivotTables stay pivotable, slicers still slice. It's your spreadsheet, living in Power BI, viewable by people you share it with. What it is not is a Power BI report in the proper sense. You don't get the Power BI visuals, the drag-and-drop report canvas, or the full dashboard experience. You get your Excel workbook in a different window.

The second is export. This pulls the supported parts of your workbook, mainly the data model and any tables, into Power BI as a dataset. From there you build actual Power BI reports on top of it using Power BI's own visuals and report designer. This is the option people usually want when they imagine "turning my spreadsheet into a dashboard," even though upload is the one that sounds more like what they asked for.

The naming is genuinely confusing and I've watched smart people pick the wrong one and then wonder why their shiny new dashboard looks exactly like their old spreadsheet. So: upload if you want the workbook itself available in Power BI, export if you want to build new reports on the data. Get that distinction right and most of the frustration disappears.

When This Is the Right Tool

The publish path shines in a specific situation, and it's a common one. You've already done real modelling work inside Excel. You've used Power Query to pull and shape the data, you've built a data model with relationships and measures in Power Pivot, and the workbook is genuinely doing analysis rather than just holding rows. In that case, exporting to Power BI carries all of that effort across. The queries, the model, the DAX measures, they come with you. You're not rebuilding, you're promoting work you've already done to a platform that does more with it.

That's the scenario where I'll happily tell a client to use this feature rather than start fresh. It respects the time they've already sunk into the spreadsheet, and it gives them a clean on-ramp to learning Power BI's reporting side without having to relearn the data side at the same time.

It's also a sensible first step when a team is testing the water. A finance team that wants to see whether their monthly pack works better as a Power BI report doesn't need a full project to find out. Publish the existing workbook, build a quick report on the exported model, share it with a few people, and gauge the reaction. It's a cheap experiment, and cheap experiments are how good reporting habits start. If it lands, you've got a foundation. If it doesn't, you've lost an afternoon.

Where It Falls Short

Now for the honest part, because this feature has real limits and pretending otherwise sets people up for disappointment.

Not everything in your workbook comes across. Features that don't have an equivalent in the Power BI model get left behind during export, and the list of what's supported shifts over time, so it's worth checking against the current documentation rather than assuming your exotic setup will survive. If your workbook leans heavily on cell-level formulas scattered across worksheets rather than a proper data model, there's much less for Power BI to grab onto, and you'll get a thin result.

The refresh story is the bigger gotcha. Getting the report into Power BI is the easy part. Keeping it current is where the actual work lives. If your workbook pulls from a database or a file on a network share, you'll need to set up scheduled refresh and quite possibly a gateway so the service can reach back to your data source. None of that is exposed by the publish button. The button gets you a snapshot. Turning that snapshot into a living report that refreshes on its own is a separate job, and it's the job that matters most for anything people are going to rely on. I've written more about the moving parts in our work on Power BI reporting, because this refresh-and-gateway layer is usually where reporting projects either become reliable or quietly fall apart.

And there's a strategic trap worth naming. Publishing from Excel is so easy that teams sometimes treat it as a substitute for thinking about their data properly. They publish twenty workbooks, end up with twenty disconnected datasets, and recreate the exact spreadsheet sprawl they were trying to escape, just in a new location. The feature is a bridge, not a destination. If every report in your business starts life as a separately published workbook, you don't have a reporting platform, you have a spreadsheet mess with a Power BI logo on it.

How I'd Actually Use It

Here's the approach I'd recommend for an Australian business sitting on a pile of important spreadsheets and wondering where to start.

Pick one workbook that genuinely matters and is already reasonably well built, ideally one with a real data model behind it. Use export to bring it into Power BI as a dataset. Spend a bit of time building a proper report on top, using Power BI's visuals rather than just recreating the spreadsheet view, because that's where the value lives. Then sort out the refresh properly, including a gateway if the source is on-premises, so the thing stays current without anyone touching it.

Once that one report is working and people trust it, you've learned the pattern and you can make a more deliberate call about the rest. Some workbooks will follow the same path. Others will be the prompt to move the underlying data somewhere more robust, like a database or a Fabric lakehouse, and connect Power BI to that directly instead of to a spreadsheet. That second realisation, that the spreadsheet was never meant to be the source of truth, is one of the most valuable things a team can arrive at, and it usually arrives right about here.

This is the kind of staged, no-drama modernisation we tend to favour. You don't need a six-month transformation programme to get real value out of Power BI. You need one good report that works, and a clear-eyed view of which spreadsheets deserve to graduate and which ones are telling you something bigger about your data foundations. If you want a hand working out which is which, that's a big part of what our data and AI consulting team does day to day, and it's an easy conversation to start.

The Short Version

Publish to Power BI from Excel is a small feature that punches above its weight when you use it for what it's good at. It rewards workbooks that already have a real data model, it's a great way to test whether a report belongs in Power BI, and it saves you rebuilding work you've already done. It is not a magic button that turns a tangle of spreadsheet formulas into a governed reporting platform, and the refresh setup it leaves you to handle is where the genuine effort sits.

Use it as a deliberate first step rather than a shortcut around thinking, and it'll serve you well. If you'd like to talk through whether your spreadsheets are ready for this jump, or whether they're hinting at a deeper data problem worth fixing first, get in touch. We've seen enough of these to know the difference quickly.