The Power BI Migration POC - What to Actually Test Before You Commit

The Power BI proof of concept stage is one of those things that either saves a project or kills it slowly. I've seen both. The difference is usually about what people choose to test, not how hard they work at it.

If you're migrating from a legacy BI platform (Tableau, Qlik, SAP BO, Cognos, or a homegrown SQL Server Reporting Services setup), there's a window early in the project where you can validate the hard stuff cheaply. Once you skip that window, you're committed. You're building production reports against assumptions that may or may not hold up. By the time you find out something doesn't work the way you expected, you've spent months and budget.

Microsoft's migration guidance calls this Stage 3. I just call it the part where you find out what you don't know.

This is the post I wish I could send to clients before we kick off these projects. What follows is what I've learned about running a useful Power BI migration POC, based on having watched dozens of them go well and quite a few go sideways.

What a POC actually is

The classic mistake is treating the POC like a demo. Pretty visuals, a small dataset, a happy path that shows the tool works. This proves Power BI exists. It doesn't prove anything else.

A useful POC is targeted at the things you're uncertain about. It might not look impressive. It might be ugly. But it answers the questions that matter for the actual migration.

These questions are usually some combination of:

• Can we connect to our actual data sources reliably
• Does the data model we have in mind actually perform at our data volumes
• Does row-level security work the way we expect with our identity setup
• Can we refresh through a gateway from on-premises sources without breaking
• Does single sign-on work with DirectQuery against our data warehouse
• Can we replicate the calculations from the legacy platform with equivalent results

None of these is about whether Power BI is good. They're all about whether your specific environment will work with Power BI. That's the question worth answering.

Take it from start to finish

The single biggest mistake I see in POCs. People build something in Power BI Desktop, look at it, declare success, then never deploy it to the service.

This is a problem because most of the failure modes in Power BI happen at the service layer, not Desktop. Gateway connectivity, scheduled refresh, capacity sizing, row-level security under real authentication, sharing and permissions. None of these are tested by a PBIX sitting on someone's laptop.

When we run a POC, we always go end-to-end. Build it in Desktop. Publish to a development workspace. Set up the gateway. Configure scheduled refresh. Apply RLS. Have a real user (not the developer) log in and view it. Only after all that has worked do we say the POC has answered its question.

This adds maybe a day or two of effort. It catches issues that would otherwise show up six weeks into production build, when fixing them is significantly more expensive.

Use real data, even if it's a subset

Don't use sample data. Don't use generated data. Don't use last year's data because this year's data is "complicated".

Use real production data. If volume is a concern, take a representative slice (one month, one region, one product line). But it has to be real data with real shape, real quality issues, real edge cases. Otherwise you're not testing whether Power BI handles your data. You're testing whether Power BI handles ideal data, which we already know.

Real data exposes things that sample data hides. Null values where you didn't expect them. Date fields that turn out to be strings. Categorical fields with seventeen different spellings of the same value. Numeric columns that contain "N/A" in 3% of rows. These are the things that break models in production. Catch them in the POC.

This is particularly important when migrating from a legacy platform. The legacy reports probably have years of accumulated workarounds for data quality issues. The original SQL has CASE WHEN statements that handle the weird stuff. The cubes have calculated members that filter out the noise. When you build the Power BI equivalent, you need to either replicate those workarounds or fix the underlying data issues. Either way, you only know what's needed if you're working with real data.

Validate the data model design

Microsoft's guidance includes a caution about something I've seen go wrong on many migrations. People who are used to relational reporting tools tend to think in terms of joining tables together at query time. They take that mental model into Power BI and end up with non-star-schema models that perform badly.

If you're migrating from a tool that uses SQL queries as its data source (SSRS, custom reporting frameworks, even some Tableau deployments), there's a strong temptation to keep the same approach in Power BI. Just point Power BI at the same SQL views and call it done.

This can work in DirectQuery mode, where Power BI passes queries down to the underlying database. But for Import mode, where Power BI loads data into its own engine, this is almost always the wrong approach. You want a star schema. Fact tables in the middle, dimension tables around the outside, relationships flowing inward. Power BI's engine is optimised for this pattern. Anything else and you'll see performance issues that get worse as data grows.

The POC is the right time to test this. Build the star schema version. Load it with real data. Measure query times. If you can't get acceptable performance on a representative subset, you won't get it on the full dataset either.

We help clients work through these data architecture decisions as part of our Power BI consulting engagements, because getting this wrong upfront cascades into months of remediation work later.

Dashboards are not what you think they are

Microsoft's guidance flags a vocabulary trap that catches almost every client. In the broader BI industry, "dashboard" means a single-page view of key metrics. In Power BI specifically, "dashboard" is a specific feature in the Power BI service that pins visuals from one or more reports.

When you're migrating, you have to decide whether each legacy "dashboard" should become a Power BI report or a Power BI dashboard. The answer is almost always report. Power BI reports are richer, more flexible, support more visual types, and work in both Desktop and the service. Power BI dashboards are a specific service-only feature mostly used for combining content from multiple reports into one view.

The POC is a good time to make this decision and stick with it. Don't call your reports "dashboards" in their names. Don't promise stakeholders "dashboards" if you mean reports. This sounds pedantic but it causes endless confusion when you're trying to explain to a user that the "dashboard" they're using is actually a "report" in Power BI terms.

Don't try to replicate every visual exactly

The other recurring trap. Stakeholders who have used the legacy BI platform for years have strong opinions about how reports should look. The bar chart should be exactly this width. The colours should be exactly these. The footnote should appear at exactly this position. The drill path should work exactly the way it does now.

Some of these requests are reasonable. Most are not. Power BI has different visual idioms from legacy tools, and trying to force pixel-perfect parity costs a fortune and produces ugly reports.

When you're running the POC, focus on the business questions the reports answer, not the exact visual layout. If the goal of the report is "show monthly sales performance by region", then a Power BI report that answers that question is succeeding, even if the chart type is different from the legacy version.

Get stakeholder buy-in to this principle during the POC. If they sign off on "the same business questions answered with Power BI native visuals", you've saved yourself an enormous amount of grief during the production build. If they insist on exact visual replication, that's a different (more expensive) project and you need to know that upfront.

Test the things that can't be undone easily

Some things are easy to change later. Visual styling. Page layouts. Calculation definitions. If you get these wrong in the POC, you fix them in production with minimal cost.

Other things are very hard to change later. Data model design. Workspace structure. Identity and security configuration. Gateway architecture. Refresh patterns. If you get these wrong, you might have to start over.

Spend POC time disproportionately on the hard-to-change things. The visual stuff can be iterated. The architectural stuff has to be right before you start building real content.

We work with clients on this kind of architectural validation when running data and AI strategy work, and it's almost always money well spent. The cost of fixing a data model decision after twelve reports have been built against it is not linear. It cascades.

When to skip the POC

Microsoft's guidance hints at this but I'll say it directly. Not every migration needs a formal POC.

If you've done multiple Power BI migrations before, you know the tool, your team is experienced, and the new environment is similar to what you've worked with, you can probably skip the formal POC. Skip straight to incremental delivery of real content with frequent feedback loops.

If you're new to Power BI, migrating from a fundamentally different platform, or working with unusual data sources or security requirements, the POC is worth it. Two to four weeks of focused validation can save months of remediation.

The middle case (your team is somewhat experienced but the environment has some new elements) is where most clients live. Run a lightweight POC focused on the specific unknowns. Two weeks. Not three months. Don't gold-plate it.

What success looks like

A good Power BI migration POC produces a small, working solution. Real data. Real connectivity. Real security. Deployed to a real workspace. Used by a real user. Answers the questions you weren't sure about.

It's not pretty. It's not feature complete. It's not ready to show the CEO. But it's an honest answer to "can we actually do this with Power BI in our environment". If the answer is yes, you've got the foundation for production work. If the answer is no, you've found out cheaply, before committing real budget.

The Microsoft article that triggered this post has the official framework. It's a useful reference. The practical bit is the part they can't really write down. The discipline to focus your POC on the things you don't know, not the things you do.

If you're starting a Power BI migration in 2026 and want a sounding board for the POC design, that's exactly the kind of conversation we have with Australian organisations starting these projects. Worth a thirty-minute call before you commit to a direction.