Milestone
Microsoft Fabric implementation
I led an organisation's migration to Microsoft Fabric. The outcome wasn't a new platform: it was consolidating around 2,000 reports into 300 and knowing again which number is the right one.
What it solves
- From around 2,000 reports down to 300: fewer reports, but one version of every number.
- Role-based access control on the platform, instead of files circulating by email.
- Power BI stopped being one team's tool and became available across the organisation.
- Governance and self-service delivered in the same migration, though they're usually framed as opposites.
This isn’t a project with a deliverable you can open in a tab. It’s a milestone: the migration to Microsoft Fabric of the organisation I work for, which I led, and whose most visible result was taking things away rather than adding them.
The problem wasn’t the tooling
Every organisation that grows on reports accumulates the same problem. Each area builds its own, each with its own logic and its own slice of reality. Given enough time there are three reports answering the same question with three different numbers, and nobody knows which one to bring to the meeting.
Buying a platform doesn’t fix that. Deciding which number is correct fixes it, and that’s an organisational conversation, not a technical one.
From 2,000 reports to 300
The metric I’m proudest of is a subtraction: around 2,000 reports were consolidated into 300.
It sounds like a cut and it’s the opposite. What happened was an exercise in curation: identifying which reports were genuinely the source of truth, consolidating the ones duplicating logic, and retiring the ones that existed only because someone asked once. What remains is a small set of official reports, and that word is what changes the game: it means there’s an institutional answer to each question, not one answer per analyst.
The hard part of business intelligence at scale was never building reports. It was deciding which ones are true.
Security: from circulating files to role-based access
Before Fabric, a good deal of sensitive information travelled the way it always travels: email attachments, local copies, versions surviving in the downloads folder of someone who has since changed roles.
Fabric moves that control to where it belongs. Access is defined by role on the platform, and the information stops existing as loose copies. The practical difference is that the question shifts from “who has that file?” to “who is allowed to see this data?”, which is a question you can actually answer and audit.
Democratising Power BI without losing control
This usually gets framed as a trade-off: either you govern the information, or you let people explore it freely. The migration was designed not to choose.
On a governed foundation (certified models, clear permissions, a single source) Power BI stopped being a specialist team’s tool and became available across the organisation. Someone in operations can build their own view without booking anyone’s time, and without risk of inventing a new number, because they start from the same model as everyone else.
Self-service isn’t opposed to governance. It depends on it: you can only open up access once there’s a foundation people trust.
What I took from it
Leading a migration like this is mostly a job of conversations. Configuring the platform is the part that has documentation. Agreeing on which report is the official one, and holding that decision when it’s inconvenient for someone, is the part that determines whether the migration achieved anything or just changed tools.
Confidential project. The organisation and its internal architecture are not detailed.