a law firm's data team that owns a fabric build they didn't build.
A small data team inside a global law firm - strong in SQL and SSRS, with no Fabric between them - and a specialist consultancy moving the Power BI model that had outgrown its refresh onto Microsoft Fabric. Their lead's worry was simple: if his team didn't get to grips with Fabric, they'd come out of the migration dependent on the contractors who built it.
the short version
A consultancy built their Fabric model; the team came out owning it. By handover they were tracing wrong numbers back through the new stack themselves.
- who: a small data team inside a large international law firm - strong in SQL and SSRS, some Power BI, no Fabric yet
- where they were: their Power BI model had grown past refreshing reliably, so a specialist consultancy was moving it - and the pipeline behind it - into Microsoft Fabric; the reporting stayed in Power BI
- the worry: if the team didn’t understand Fabric, they couldn’t take ownership of the model when it was handed over - and off-the-shelf Fabric training hadn’t stuck
- what I did: joined on a done-with-you retainer running alongside the migration, so the team could understand and own the Fabric model themselves
where they started
When their head of data first got in touch, he was partway through a decision. His team - a handful of people inside a global law firm’s IT - ran the firm’s reporting on an SSRS estate built up over a decade, with a lot of the business logic buried in the report code. On top of that sat a Power BI model carrying some of the firm’s most sensitive numbers. It had grown too big: it wasn’t refreshing reliably, and he’d find out days later that the figures were stale. Adding anything to it was slow and painful.
A specialist consultancy pitched the fix: move that model, and the pipeline feeding it, into Microsoft Fabric. They knew the source data, so they would do the build - his team had no Fabric experience to do it with. The reporting itself would stay in Power BI; everything underneath it would change.
That’s when he came to me. If the model was moving into Fabric, his team needed to understand Fabric too - otherwise the migration would end with the firm’s numbers on a platform only the contractors could safely change. His people knew the data inside out from the SSRS days; the gap was the platform it was all landing on. And he’d been here before: off-the-shelf “Fabric in a day” training hadn’t stuck, because there was no live model to practise on.
So what he wanted was simple to say and harder to do: whatever the consultancy built, his team had to come out able to own it.
the turn
The starting point was getting to know the team: a skills assessment and a confidential one-to-one with everyone, to understand the dynamics and work out how to position the learning so the team could actually absorb it. The worry the lead had named was real, and the one-to-ones turned up more underneath it: the team had quietly split into two halves, the SQL people and the Power BI people, with too much knowledge sitting in too few hands.
a team can’t own what it didn’t build and was never shown.
Having the consultancy build it was getting the platform stood up, but it left the people who’d have to live with it on the outside. So the fix was hands-on - getting the team into their own Fabric ecosystem, on their own data, until it stopped being a black box and started being theirs.
what the team did
The shape was a done-with-you retainer running in parallel to the migration, on the team’s real data, with clear lines: the consultancy built and migrated the platform, and I stayed out of the build. My job was to hear the team’s problems and guide them to solving those problems themselves, with a safety net under them while they did. Fabric brought genuinely new ways of working - a dev workspace and a production one, knowing where a change can safely be made and how to back one out - and the only way that stops feeling foreign is doing it yourself. I didn’t do things for the team, because that isn’t how know-how moves across.
they ran their own diagnostics
During handover - the stage where you expect to be shaking things out - a year-to-date number looked wrong. The easy move was to hand it straight back to the consultancy: that number’s wrong, please fix it. Instead the team used it as a way into the stack, with me alongside, and followed the number all the way down:
a year-to-date number looks wrong
test visuals prove the hunch
down through the reporting layer
into the gold tables
through the silver tables
into the bronze tables
to a stored procedure, quietly dropping the right rows and keeping the empty ones
the source: year-opening values a separate app had been writing into specific rows - a quirk the team knew all about
they knew where to look
By user acceptance testing they were comfortable enough in Fabric to follow an issue in the outputs back through the pipeline and arrive saying: here’s the error, and here’s where we think it’s coming from - because they could tie the new build back to years of knowing how and why the original reports worked.
Behind that sat the technical groundwork: showing them how their own Fabric build was put together - the bronze, silver and gold layers, Direct Lake’s trade-offs - calculation groups for the time intelligence, and a reusable pattern for the firm’s custom P&L subtotals that let them drop a paid third-party visual while keeping free Excel export for the whole firm. All of it recorded into a library the team owns.
where I said no
The part I’m most quietly pleased with on this one is the handful of times I argued against doing more. When the team wanted to rebuild some balance-sheet labelling with clever DAX, I told them not to: it was a training and change-management question, and solving it with calculation logic would have added complexity, a maintenance burden, and a new way to be wrong, for a cosmetic gain. I held the line on not making production changes myself, even when it would have been quicker, because the quick version would have left them depending on me.
where they got to
From a team wary of touching a Fabric build they hadn’t made and calling for help on minor changes, to a team running its own diagnostic sessions and going back to the consultancy with the likely cause, rather than taking the build on trust. The migration is fully handed over now, and they manage the Fabric model themselves. The engagement was extended past its original run, and the firm offered to introduce me to heads of data at peer firms.
This is the sort of work I do embedded with a team, month to month. what working together looks like - shape, rhythm, price ▸