Power BI Migration - Creating and Validating Content That People Will Trust

The create content stage of a Power BI migration is where most projects quietly go wrong. Not with a big dramatic failure, but with a slow loss of trust. The new reports go live, a regional manager notices their sales figure is $14,000 different from the old Cognos or Tableau report, and from then on every number in Power BI is "the new system's number". People keep running the old reports on the side. Two years later you're still paying for both.

Microsoft's migration guidance breaks the process into stages, and the one covering content creation is Create content for Power BI migration. It's a solid outline. We've written about the earlier stages before, including requirements gathering and the proof of concept. This post is about the build itself, and specifically about validation, because that's where the trust gets won or lost.

Don't migrate, redesign

The single most common mistake we see is treating migration as a like-for-like port. Someone takes a 40-page SSRS report or a Tableau workbook with 25 tabs and rebuilds it pixel for pixel in Power BI.

That's a waste of Power BI and usually a waste of money. Legacy reports are full of things that only existed because the old tool couldn't do better. Five near-identical reports filtered for each state, because the old system had no slicers. A huge tabular export, because users wanted to pivot in Excel. Calculated fields duplicated across 30 reports, because there was no shared semantic layer.

Microsoft's guidance makes the same point: use the migration as a chance to rethink. I'd go further. Before you rebuild any report, ask who actually uses it and what decision it supports. On one migration for a logistics client, about a third of the 200-odd legacy reports had not been opened in over six months. We didn't rebuild them. Nobody noticed. That cut weeks off the project.

Build the semantic model first

The order matters. Build the semantic model, validate it, then build reports on top. Not the other way around.

In older BI tools, logic often lives inside the report: calculations, filters, business rules buried in the report definition. In Power BI the right pattern is a shared semantic model that holds the relationships, measures and business logic once, with thin reports connected to it.

A few things we've learned building these models:

Star schema, always. Fact tables for transactions, dimension tables for the things you slice by. If you're importing a wide flat table from the old system's extract because it's easier, you'll pay for it in performance and DAX complexity later. Every time.

Name measures for business people. "Total Revenue ex GST" beats "SumAmt_v2". The semantic model is increasingly what people (and Copilot) query directly, so the names matter more than they used to.

Put the hard business rules in the model and document them. How do you count active customers? Does revenue include credit notes? Which date does a sale belong to, order date or invoice date? These rules were usually buried somewhere in the old system, and often nobody remembers them. Digging them out is slow, unglamorous work, and it's most of the job.

Plan for reuse. If three departments need sales data, build one sales model they all connect to, not three copies. That's the whole point of moving to a shared model.

Then build reports

Once the model is validated, the report building goes quickly. A few practical suggestions:

• Agree on a report template and theme early. Consistent layout, colours, fonts and navigation across reports helps people trust the system as a whole. It also stops every developer inventing their own style.
• Fewer visuals per page. Legacy dashboards are often crammed. Aim for one clear question per page, with drill-through for detail.
• Paginated reports where they're actually needed. For invoice-style, print-ready, or regulatory reports, Power BI paginated reports are the right tool. Don't force those into interactive reports. And don't use paginated reports for everything just because the old system was SSRS.
• Get early feedback from real users. Show a work-in-progress report to two or three of the people who'll use it daily. They'll spot problems in 10 minutes that you wouldn't spot in a week.

Validation is where trust is won

This is the part I'd spend the most time on, and it's the part most project plans squeeze when deadlines slip.

Microsoft's guidance talks about validating data accuracy, security, functionality and performance. All four matter, but data accuracy is the one that decides whether people adopt the new system.

Data accuracy

Reconcile the new numbers to the old system for the same period, filters and definitions. Not just at the grand total, but at the levels people actually look at: by month, by region, by product category, by customer.

What tends to happen is the totals match, but a breakdown doesn't. And the reason is almost always a business rule difference. The old system excluded internal transfers. Or it used a different fiscal calendar. Or it handled a customer who moved state by assigning all history to the new state. You only find these by reconciling at detailed levels.

Some things that help:

• Build a reconciliation report. Literally a Power BI page that shows old system value, new value and variance side by side for key measures across key dimensions. It's quick to build and gives everyone a shared view of where things stand.
• Agree on tolerance up front. Is a 0.1% variance acceptable due to rounding? Agree before testing starts, not after someone finds a difference.
• Remember the old system might be wrong. This happens more often than you'd think. On one finance migration we found the legacy report had been double counting a category of adjustments for years. Proving that took a few days and some awkward conversations, but the new system was right. Document these findings properly, because someone will ask again in six months.

Security

If the old system had row-level security, so a state manager only sees their state, test that it works identically in Power BI. Test with real user accounts, or use "View as" with roles in the service. Test the edge cases: a person with access to two regions, a person who changed roles, a contractor. Getting security wrong in a migration is the kind of problem that ends up in front of the board.

Functionality

Do drill-throughs go to the right place? Do bookmarks and buttons work? Do filters carry across pages as expected? Does the export to Excel button produce what finance needs? This sort of testing is tedious but it's what users will judge.

Performance

Test with realistic data volumes and realistic concurrency. A report that loads in 2 seconds in development against a sample might take 25 seconds against five years of production data during month-end when 80 people open it at once. Use Performance Analyzer in Power BI Desktop to find slow visuals, and look at your DAX and model design before reaching for a bigger capacity.

Who does the testing

Developers shouldn't validate their own work alone. You want business users doing user acceptance testing, ideally the people who know the old reports best and will notice when something's off. Give them a clear test script for the key scenarios, plus time to explore freely.

The thing nobody budgets for: these people already have day jobs. If UAT is meant to happen "alongside BAU", it'll happen badly or late. Get time formally allocated, even if it's just a few hours a week for a month.

Running in parallel

For anything important, run old and new in parallel for at least one full reporting cycle, and for finance that usually means a month-end close. It costs a bit more, but it gives people confidence and catches the issues that only show up with real, live data.

Then set a firm date to switch off the old reports, and stick to it. If you don't, people will keep using them indefinitely. This is change management more than technology, and it's where a lot of migrations stall.

Where we fit

We've helped organisations work through Power BI migrations from SSRS, Cognos, Tableau, Qlik and plenty of Excel-based reporting, and the technical rebuild is honestly the more predictable part. The hard parts are pinning down business rules, reconciling to legacy numbers and getting people to let go of the old system.

If you're planning a migration or you're stuck partway through one, our Power BI consultants can help with the model design, validation and rollout. And if the migration is part of a bigger move to Fabric, have a look at our Microsoft Fabric consultants page or get in touch.