Migrating a Healthcare BI Platform Without Breaking Clinical Reporting

Every morning at a Medicare Advantage primary care organization, clinical leaders open dashboards. They check appointment fill rates, no-show trends, AWV completion progress, care gap closures, and panel coverage metrics. Those numbers drive the daily huddle. They decide which patients get called, which providers need support, and which clinics are behind.

If those dashboards go down, even for a day, operations feels it immediately. Scheduling decisions get made on gut feel. Care gap outreach loses its targeting. The quality team flies blind.

So when I decided to replace our legacy BI platform with a custom analytics platform, the constraint was not technical. It was operational. I had to migrate the entire reporting stack across five clinics, roughly 30 providers, and over a hundred daily users without a single day of reporting gaps.

We completed the sunset with zero reporting gaps. Here is how.

The Core Principle: Dual Run, Not Switch-Over

The biggest mistake in BI migrations is the switch-over approach. You build the new platform, test it, pick a cutover date, and turn off the old one. In healthcare, that approach fails because you always discover something you missed after cutover. A dashboard that nobody mentioned but someone uses every Tuesday. A metric calculation that worked differently in the old platform. A filter that the clinical team depends on but never documented.

I used dual run instead. Both platforms ran in parallel for the entire migration period. Every report that existed in the legacy platform had to exist in the new platform, produce the same numbers, and pass user validation before the legacy version was even eligible for sunset.

This costs more in the short term. You are maintaining two platforms, two data pipelines, and answering questions from two sets of dashboards. But it eliminates the risk of discovering a missing report after you have already turned off the old system. In healthcare, that insurance is worth the cost.

Starting with the Metric Layer

The reason most BI migrations produce different numbers is that the metric definitions live in the reporting layer. Each dashboard calculates the metric slightly differently. When you rebuild the dashboard in the new platform, you have to reverse-engineer the calculation, and you get it wrong.

I solved this by moving metric definitions into a governed semantic layer before the migration. Instead of calculating "AWV completion rate" inside a Tableau workbook, the metric is defined once in a dbt semantic layer. The BI platform, whichever one it is, reads from that semantic layer. The calculation lives in one place.

This means the migration was not about rebuilding calculations. It was about pointing the new platform at the same governed metric definitions. If the old platform and the new platform both read from the same semantic layer, they produce the same numbers. That is the whole game.

The semantic layer has over 500 models. It includes governed metric registries, automated data contracts, and column-level definitions. When a KPI changes, the contracts, seeds, and metric views all update together. This prevents the silent breakage that happens when someone changes a definition in one place but not in the downstream reports.

Migration in Priority Order, Not All at Once

I did not try to migrate everything simultaneously. I categorized every report by criticality and migrated in waves.

Wave 1: Operational spine. The reports that clinical operations depends on every morning. Appointment fill rates, no-show rates, cadence metrics, next-visit projections, AWV completion. These went first because they had the highest validation priority and the most users depending on them.

Wave 2: Quality and care gap reporting. HEDIS measures, care gap closures, quality metric performance. These are important but have different cadence. They are reviewed weekly or monthly, not daily. The slightly lower urgency gave more validation time.

Wave 3: Specialty and program dashboards. Heart program monitoring, referral management, transitional care management. These are domain-specific and have smaller user bases, which means fewer validation cycles but also lower risk if timing slips.

Wave 4: Ad hoc and legacy reports. Reports that one person uses, or that have been superseded by better versions in the new platform. Many of these were retired rather than migrated.

Each wave followed the same process: build in the new platform, validate against the old platform number-for-number, get user sign-off, then mark the old version for sunset.

Embedded AI Dashboards

One of the reasons for the migration was to move beyond static reporting into interactive, AI-assisted analytics. The new platform includes embedded AI/BI dashboards that let users ask questions in natural language and get answers grounded in the same governed metric layer.

This is where the semantic layer pays off a second time. AI dashboards are only as good as the metric definitions they query. If the AI can ask "what is our AWV completion rate for the south clinic this month?" and get an answer grounded in the governed definition, the result is trustworthy. If it is calculating on the fly from raw tables, it will hallucinate.

By front-loading the semantic layer migration, I gave the AI dashboards a solid foundation. The AI features were a benefit of the new platform, but they worked because the metric governance was already in place.

The Sunset: Proving Zero Gap

The sunset itself was the final validation. I did not turn off the legacy platform until every user confirmed they were working exclusively in the new platform and every report had been validated.

I tracked sunset eligibility per report. Each report had a status: building, validating, validated, sunset-ready, sunset. No report moved to sunset-ready until the user who owned it confirmed the numbers matched and the new version met their needs.

The legacy platform was turned off only after every report was either sunset-ready, migrated, or intentionally retired. And even then, I kept the legacy data available for read-only historical comparison for a transition period, because someone always asks "what did this number look like last year in the old system?"

What I Would Do Differently

The migration worked, but there are things I would adjust:

Document the undocumented reports earlier. Every organization has shadow reports that nobody officially owns but somebody uses. I found several of these late in the process. An earlier inventory would have caught them sooner.

Involve the clinical users in validation sooner. The IT team can validate that the numbers match, but only the clinical users can validate that the report is actually usable in their workflow. Number-matching is necessary but not sufficient.

Budget more time for the semantic layer. It was the highest-value work in the migration, but it was also the most time-consuming. If you are planning a BI migration, start the semantic layer work before you think you need it.

The Takeaway

BI migrations in healthcare fail when they are treated as technology swaps. They succeed when they are treated as metric governance projects with a technology component. The new platform is the visible deliverable, but the semantic layer is what makes it work.

Build the governed metric layer first. Dual-run both platforms. Migrate in priority waves. Validate with the users who actually depend on the reports. And do not turn off the old system until you can prove there are zero gaps.

In healthcare, clinical operations does not have time for you to figure out the reporting after cutover. Get it right before you make the switch. The dual-run approach costs more upfront. It saves you from the one thing you cannot afford: a clinical team making decisions on missing or wrong data.

Originally published on dev.to.