Back to Blog

What Real Power BI Migrations Teach You - Lessons From the Field

May 11, 2026•10 min read•Michael Ridland

Most Power BI migration projects fail in places nobody warns you about. The technology bit is usually the easy part. It is the people, the change management, the inevitable political fights over which reports get rebuilt, and the slow realisation that half the legacy reports nobody actually uses. I have run a few of these and watched a few more from the outside, and the patterns are remarkably consistent.

Microsoft published a guide that summarises lessons learned from two large customer migrations to Power BI. It is genuinely useful reading because the official guidance for these projects often glosses over the hard parts. I want to walk through what the real lessons are, what the official write-up gets right, and what is still missing for an Australian business looking at the same kind of project.

Phased migration is not optional

The Microsoft case study describes an international consumer goods company that started using Power BI in 2017 alongside their existing BI tool. They did not declare Power BI the standard until 2018, after content authors and IT had time to build skills. The formal migration of legacy content did not begin until late 2019.

That timeline looks slow if you have not run one of these projects. It is actually about right. Trying to do "we are turning off the old platform on a fixed date and rebuilding everything in Power BI" almost never works at any reasonable scale. The pattern that works is to introduce Power BI as a parallel option, let it earn credibility through one or two successful early projects, declare it the preferred platform once people have experienced the value, then formally migrate the legacy content.

The phase nobody likes is the parallel one. Two BI platforms means two licence costs, two sets of training, and two sets of support questions. Finance teams hate it. But trying to short-circuit it by mandating a hard cutover is how you get a Power BI rollout that everyone resents for the next five years.

We have worked with Australian organisations where the parallel phase ran for eighteen months. That is fine. It is cheaper than the alternative.

Communication is the actual job

The Microsoft guide notes that "communication with leadership teams throughout the business units was critical" during their migration. That is correct but the framing makes it sound like a side activity. It is not. In the migration projects I have run, the communication work is the bulk of the project. The technical work is the easier part.

Different business units have made different investments in the legacy platform. The team that spent three years building expertise in your old reporting tool is not going to be excited when you tell them they have to throw that away. They have valid concerns about timeline, budget, and the perceived risk of breaking reports the business already trusts.

The communication pattern that works:

  • A clear "why" statement from the executive sponsor, repeated more than feels necessary
  • Concrete milestones with dates that people can plan around
  • Honest acknowledgment of what is being lost as well as what is being gained
  • A named person business units can talk to about their specific concerns
  • Regular updates that include both wins and problems

The communication pattern that fails is the one where the central IT team sends out a project plan and then goes quiet for six months while they "execute". By the time they come back to the business units, the business units have built their own informal solutions and the migration is doomed.

Do not faithfully replicate every report

The Microsoft case study is honest about this and it deserves the same honesty from anyone running one of these projects. "Not every individual report could be faithfully replicated in Power BI". That is correct and it is a feature, not a bug.

When you move BI platforms you are also taking the opportunity to fix the things that were wrong with the old reports. Most legacy report estates have accumulated a layer of weirdness over years of small change requests. A column added here. A filter that nobody remembers why. A formatting choice that made sense in 2014. Migration is a chance to clean some of that up.

The trap is that some users will demand exact replicas because that is what they recognise. Most of those demands are not real requirements. They are familiarity. The work is to have the conversation: "this report's purpose is X, and here is the cleanest way to do X in Power BI, which is different to how it looked before but better." Sometimes the user is right and the original design was good. Often they are not.

The other side of the trap is that some reports are exactly the right design and rebuilding them differently is a waste. The judgement call is which is which. There is no substitute for a senior person who can have that conversation with the business and be trusted to make the call.

For our clients we usually run this as a structured workshop early in each report's rebuild. It takes two or three hours per report and saves weeks of rework. It is one of the higher-value activities in a Power BI consulting engagement.

Assess priorities ruthlessly

The Microsoft case study highlights that of thousands of published reports on the legacy platform, only about half had been used in the previous year. Of those, only half were deemed to deliver significant value. That is a 4:1 ratio of "reports that exist" to "reports worth migrating".

That is consistent with what I see in Australian organisations. Most legacy BI estates have 60 to 80 percent of content that could disappear tomorrow with nobody noticing. Migration is the cheapest opportunity you will ever have to delete it.

The decision tree we use:

  1. Has anyone opened this report in the last 90 days? If not, archive it and tell the original owner you are going to retire it unless they object within two weeks
  2. Of the reports that are used, is the use frequent or sporadic? Sporadic-use reports should be candidates for self-service alternatives, not for full rebuilds
  3. Of the reports that are used frequently, do they actually drive decisions or are they just being opened out of habit? This is the hardest conversation but it is worth having

The reports that survive all three filters are the ones you actually migrate. Everything else is either deleted or replaced with a different solution (a workspace dashboard, a recurring email, a self-service template).

Doing this work up front means your migration scope is half what it would otherwise be. That is what makes the timeline achievable.

Estimates will be wrong

The Microsoft case study includes a specific example: a report that was estimated as 50 days of conversion work was actually completed in 50 hours. That is a 10x error, and it is normal.

Migration estimates are notoriously bad on a per-report basis. Some reports that look simple turn out to have horrendous data dependencies that take weeks to unravel. Other reports that look complex turn out to be 90% styling and the underlying logic is straightforward to recreate.

What this means in practice is that you should not give your business stakeholders per-report timelines. Give them aggregate timelines for batches of reports. "We expect to migrate this set of 20 reports between now and the end of Q2" is a reasonable commitment. "We will deliver the executive dashboard by 15 March" is a commitment you will probably miss.

The other thing it means is that you should staff the migration team with people who can absorb the variation. A team of senior consultants will deliver the 50-day estimate in 50 hours because they will spot the simple pattern. A team of junior staff following a runbook will deliver the 50-day estimate in 50 days because they will not.

If you are looking at a multi-month migration project and the proposed team is mostly juniors, push back. The economics of a senior-led team are almost always better even though the day rates look higher.

Build the internal community

The Microsoft case study describes the company setting up a Centre of Excellence and an internal Power BI community on Yammer that grew to 1,600 members. They also created a "Power BI expert network" of internal champions.

This is the difference between a Power BI rollout that sticks and one that does not. The platform gets used because the community around it is healthy. The community is healthy because the COE invests in it.

The mistake I see in Australian organisations is treating the COE as either a pure governance function or a pure support function. Neither is right on its own. A good Power BI COE does:

  • Adoption planning (what is the next workload we are targeting, who are the early adopters)
  • Governance (workspace standards, security, licensing decisions)
  • Guidance (DAX patterns, model design, visual best practice)
  • Training (formal and informal, role-specific)
  • Support (a ticket queue but more importantly a channel where people can ask "is this normal")
  • Sometimes hands-on development (especially for the harder data work)

You do not need a big team to do this. Two to three people can run a COE for an organisation of 5,000 if they are the right people. The right people are not necessarily the most technically expert. They are the most empathetic to business users while being technically competent enough to be useful.

If you are starting from scratch on this, our Microsoft Fabric and Power BI consulting team often runs the COE function for clients during the first six to twelve months of a rollout, then hands it over to internal staff once the patterns are established.

Change management for business-owned content

The Microsoft case study mentions that "additional responsibility falls to the business units when it's impractical to manage change from one central team". This is the part of Power BI governance that does not have a satisfying answer.

In any organisation above a certain size, you will have content built by central IT teams and content built by business teams. The IT content can follow proper deployment pipelines, version control, and change management. The business content cannot, because the business teams do not have the appetite for it and trying to impose it will kill the citizen development that you actually want.

The pattern that works is tiered governance. Production content used by more than one team gets the full deployment pipeline treatment. Departmental content used by one team has lighter standards. Personal content has almost no standards beyond the workspace having reasonable security.

The trap is letting personal content drift into being treated as production. A spreadsheet someone built for themselves becomes the source of truth for a board pack. This happens slowly and nobody notices until something breaks. The COE's job is to spot this drift and either bring the content into the production governance model or formally retire it.

What this all adds up to

If you are starting a Power BI migration in 2026 for an Australian organisation, the patterns from this customer case study are still the right patterns. The platform has matured but the human dynamics of migration are unchanged.

The summary I would give a CIO starting one of these projects:

  • Plan for 18 to 24 months. Anyone who tells you it can be done in six is selling you something
  • Treat communication as a project workstream, not a side activity
  • Cut the report estate ruthlessly before you start migrating
  • Get a senior-led team, not a runbook-led team
  • Invest in the COE and the community from day one
  • Accept that estimates will be wrong and aggregate accordingly
  • Decide which reports are worth migrating exactly, and which are worth redesigning

The organisations that do these things well end up with a Power BI estate they are proud of. The organisations that skip them end up with a Power BI estate that looks suspiciously like the legacy estate they were trying to leave behind.

If you would like to talk about what a migration would look like for your organisation, my team and I are happy to walk through it. Reach out via our contact page.

Reference: Microsoft Learn - Learn from customer Power BI migrations.