The Problem
When I inherited the analytics environment, it was a patchwork of tools that had grown organically over years: a mix of Excel reports scheduled by hand, a handful of Power BI workspaces with no consistent naming, and several ETL pipelines that only one person understood. Nobody knew what was production vs. ad hoc. Nobody owned the lineage. When something broke, the first question was always “who touched this last?”
The business needed a consolidated view — literally. Leadership wanted one place to go for corporate metrics. The data teams wanted a roadmap they could trust. The operations teams wanted dashboards that didn’t lag.
The solution was Microsoft Fabric. The challenge was getting there without stopping the work that kept the business running.
The Approach
1. Map Before You Move
The first thing I did was inventory what existed. Not just the tools — the actual reports, the refresh schedules, the owners, and the dependencies. I spent three weeks in interviews with each team, walking through their current flow and identifying what they couldn’t afford to lose.
What I found:
- 14 separate Power BI workspaces with no consistent naming convention
- ~40 manually triggered Excel reports scheduled via Windows Task Scheduler
- 6 ETL pipelines maintained by a single person with no documentation
- No single source of truth for any corporate metric
I documented everything in a dependency map. This became the migration roadmap — not a technology roadmap, but a business continuity map.
2. Run Dual Systems in Parallel
The biggest risk in a migration like this is the cutover moment — when you flip from old to new and something breaks. To eliminate that risk, I ran both systems in parallel for 8 weeks before decommissioning anything.
Every report had a counterpart in the new Fabric environment. Every morning, both systems ran. Every afternoon, I compared outputs. Where they diverged, I traced the discrepancy before moving on.
This added time to the project. It also meant that when we went live, nobody noticed.
3. Segment the Migration by Domain, Not by Team
Migrations often fail because they try to move team by team, which creates hard cutover dependencies. Instead, I segmented by data domain — customer, operations, financial — and migrated each domain’s entire pipeline end-to-end before moving to the next.
This meant one domain at a time was fully live in Fabric while the others continued on legacy. It made rollback trivial (if domain C had an issue, domains A and B were unaffected), and it gave each team a clear, bounded scope to learn.
4. Build the Governance Layer First
One of the most valuable things I did before migrating any data was to establish the metric governance framework. Before any table entered Fabric, it had to have:
- A clear owner (data producer)
- A definition (what it measures, how it’s calculated, when it refreshes)
- A consumer list (who relies on it)
This took longer upfront. It meant that when the migration landed, the new environment was cleaner than the old one — not just a copy.
5. Document Like You’re Leaving Tomorrow
One of the risks with institutional knowledge is that it’s held by individuals, not systems. I documented everything as I went: architecture decisions, pipeline logic, known failure modes, and the “why” behind each choice.
The documentation lived in the same repo as the Fabric workspace definitions, so it moved with the work. New team members could come up to speed without needing to find the one person who built it.
The Outcome
Timeline: 6 months from inventory to full decommission of legacy environment.
Stakeholders impacted: 150+ across 4 business units.
Key metrics:
- Reporting latency: from weekly batch to sub-15-minute refresh
- KPI coverage: 40+ corporate metrics governed under the new framework
- Report ownership: from 1 person who “kind of knew” to a documented owner for every metric
- Dashboard uptime: went from undocumented SLA to 99.9% tracked availability
What didn’t break: Not a single operational process. The dual-system approach meant the business never went without reporting capability, even during the peak of the migration.
What I’d Do Differently
More workshops, fewer 1:1s. I did most of the knowledge transfer in small group sessions. In hindsight, building a hands-on “Fabric for Analysts” workshop with real data scenarios would have built muscle faster across the team.
Formalise the rollback threshold earlier. I had a mental threshold for when to roll back a domain if things diverged. Making that explicit and documented before starting would have reduced decision friction during the parallel run.
Automate the comparison checks. During the parallel run, I manually compared outputs between the legacy and new systems. I should have built the diff tooling first — it would have caught discrepancies faster and freed me to focus on the harder problems.
Key Takeaways
- Migration is a change management problem first. The technology is the easy part. Getting teams to trust a new system while keeping the old one running is where the real work lives.
- Run parallel before you cut over. No amount of testing replicates the reality of live data flowing through a new system. Dual-track operations are worth the time.
- Governance is not optional. Migrating messy data into a clean environment is still migration — and it still creates technical debt. Define ownership and definitions before you move anything.
- Documentation is a product, not a phase. Treat it like part of the deliverable, not a nice-to-have at the end.
This case study is a deliberately anonymised walkthrough of the migration patterns I apply in analytics transformation work. If you’re evaluating a similar project or want to discuss approach, reach out via LinkedIn.