Power BI Migration - How to Gather Requirements Properly

Most Power BI migrations we get called into are already in trouble. The team has been told to "move the reports to Power BI", they've started rebuilding things, and three months in the business is complaining that the new reports don't do what the old ones did.

The fix is almost always upstream of the build. It's in the requirements phase, which gets compressed or skipped entirely because everyone wants to see progress on screens.

This is the playbook we use when we're brought in to do migrations properly. It maps to Stage 1 of Microsoft's migration guidance, but I want to give you the version that's been pressure-tested on real projects.

Why requirements are the bit that breaks

A Power BI migration is not a technology project. It's a chance to fix the reports that have accreted over a decade. The old SSRS, Cognos, Tableau, or Excel files in your environment encode every workaround, every "Sharon needs this extra column", every "we tried to fix this but it broke another report". If you just port them across, you've moved your mess to a new tool.

Requirements done well are the opportunity to fix that. Done badly, they're the place the project starts to die quietly.

A real Australian example. We worked on a migration where the previous team had inventoried 340 reports. The plan was to rebuild all 340 in Power BI. We spent four weeks doing actual requirements work. Result: 89 reports got rebuilt, 122 got consolidated into 31 better ones, and the rest got binned because nobody had opened them in two years. The project shipped in half the original time and the business preferred the result.

That's not magic. That's what requirements gathering is supposed to do.

Start with the inventory, but interrogate it

You've probably got a list of existing reports somewhere. That list is the input, not the requirement.

For every report on the list, you need to know:

Does anyone actually use it? Server logs, usage analytics, or a quick survey will tell you. We routinely find 30-40% of reports in legacy environments have zero recent views.

Who owns it? Not "who built it" but "who would notice if it stopped working tomorrow". If nobody, it's a candidate for retirement.

Is it doing something the new platform should do? A 15-page PDF dump might be replaced by an interactive Power BI report. An Excel file that gets emailed every Monday might become a Teams subscription.

Don't migrate the form. Migrate the function.

What to actually gather

Microsoft's official guidance lists about ten categories of report requirements. They're all valid. The ones that matter most in practice are the ones we'll cover here.

Purpose, audience, and expected action

What decision is this report supposed to support? Who makes that decision? When?

If you can't answer those three questions, the report is decoration. We've sat in requirement workshops where the answer to "what action does this trigger?" was a long silence. That's data worth knowing. It means the report either needs a real purpose or it shouldn't be rebuilt.

How consumers actually use the report

The fastest way to halve your rebuild work is to watch people use the current report. Not ask them, watch them.

We've done this on dozens of engagements. The patterns are consistent. People export the report to Excel and then do four more steps that the report could have done for them. People filter to one region every single time. People ignore three of the five charts on the page.

Sitting with users for half a day per critical report costs you a day. It saves you weeks of building the wrong thing.

Data sources and latency

For each report, where does the data come from and how fresh does it need to be?

This is where most Australian organisations have a moment of honest reckoning. The reality is usually: "We don't really know, but it comes out of the warehouse, and we think it's daily, but actually for some tables it's weekly, and the marketing data is pulled manually by Steve on a Tuesday."

Document what's actually happening. Don't paper over it. The new Power BI model is your chance to either fix the data pipeline or design around its real characteristics. If marketing data is pulled by Steve on Tuesdays, the report should probably show "Data as of last Tuesday" rather than pretending it's live.

For most of our engagements, this is where the conversation expands. Migrating reports often surfaces that the underlying data platform needs work too. That's normal. Our Microsoft Fabric consultants and Data Factory work usually picks up from here.

Security and row-level security

This is the one that catches teams out late in the project.

Who's allowed to see what? In legacy reporting tools, security was often handled by giving different people access to different reports. In Power BI, you'll likely want one report with row-level security (RLS) so the same dashboard shows different data to different people.

Get the security model documented before you start building. We've had projects where this was an afterthought and we ended up rebuilding the entire data model because the security pattern didn't fit. Painful and avoidable.

Specifically, gather:

• Which users or groups see which subsets of data
• Whether there are exceptions (executives who see everything, contractors who see one customer's data only)
• Where the mapping between user and data lives (Active Directory groups? A SQL table? A spreadsheet?)

Calculations, KPIs, and business rules

This is the most underestimated category. Every report has hidden logic. Definitions of "active customer", "billable hours", "fiscal year-to-date excluding intercompany transactions". These accumulate in the report itself, in stored procedures, in the head of the person who built it.

Get them out. Document them centrally. They become the basis for your DAX measures in the new model. If two departments define "revenue" differently, surface that now and have the argument before you build, not after.

For a deeper dive into how these calculations live in Power BI, our guide to measures and DAX walks through the patterns we use.

Printing and exporting

Sounds boring. Isn't.

Power BI reports are interactive-first. They're not great at producing the print-ready, paginated, "looks the same on A4 every time" output that some legacy tools handle by default. If a report is genuinely being printed and distributed, you may want a Paginated Report rather than a standard Power BI report. They're different beasts.

The question to ask: is this report being looked at on a screen, or is someone going to print it and bring it to a meeting? Different answers, different builds.

Risks, concerns, and the backlog

Always ask: "What's annoying about the current report?"

You'll get gold. "It takes 40 seconds to load." "We can't filter by region and product at the same time." "The numbers don't match the finance team's report." Each of these is a requirement for the new version. None of them would have been captured if you only looked at the current report's screenshots.

Also ask what's been requested but never built. There's usually a backlog of "wouldn't it be nice if...". Some of that goes into the new build. Most goes into a parking lot for later. Either way, having it written down means the business knows you've heard them.

Ranking what matters

Not every requirement is equal. We use a simple two-bucket classification: must-have or nice-to-have. Then within must-haves we order by business impact.

The reason this matters: business stakeholders, given the chance, will list everything as must-have. Force the conversation. "If we could only deliver half of these, which half?" The answers tell you what the project actually needs to ship with.

Keep the nice-to-haves visible. Park them in a backlog the business can see. Otherwise people feel ignored and will quietly add their nice-to-haves to the must-have list when you're not looking.

What this looks like in practice

For a typical migration we'd run, the requirements phase is:

Week 1: Inventory review and triage. Which reports stay, go, or get consolidated. Output is a prioritised list of reports to rebuild.

Week 2: Deep-dive interviews with top-priority report owners and consumers. Output is detailed requirement docs per report.

Week 3: Data source mapping, security model design, calculation library compilation. Output is the technical foundation the new model will sit on.

Week 4: Review with stakeholders, get sign-off, finalise the build backlog.

That's four weeks before any visuals get built. It feels slow. It produces projects that ship on time with a happy business.

The honest bit

Requirements gathering is unglamorous work. It involves a lot of meetings, a lot of asking the same question slightly differently to get a useful answer, and a lot of saying "tell me more about that". It's not what people imagine consulting to be.

It's also the single most valuable activity in a migration. Skip it and you'll be rebuilding for two years. Do it well and you'll ship in months.

When clients ask us to come in for a Power BI project, this is almost always where we start. If you're planning a migration and you want a second opinion on your requirements approach, reach out and we'll have a look. The full Microsoft guidance on this stage is at Gather requirements to migrate to Power BI and is worth reading alongside this.