Moving a data warehouse to the cloud without surprises

Moving an on-premises data warehouse, whether SQL Server, Oracle or another platform, to the cloud is less about technology than about trust. The reports people open every morning need to tell the same story the day after cutover as they did the day before. Our approach rests on a simple rule: nothing old is switched off until the new system has been proven, phase by phase, and signed off by the people who use it.

Before we propose anything, we catalogue what exists today: databases, tables, views, stored procedures, scheduled jobs, ETL packages, linked servers, and every report or extract that depends on them. For each item we note who uses it, how often, and what breaks if it goes away. We also flag what has quietly gone stale. This assessment is where surprises tend to surface, which is exactly why it comes first.

From the inventory, we write down what moves, what gets retired, and what stays out of scope for now. The work is split into phases, and each phase has a clear list of objects and reports plus acceptance criteria agreed in advance. When something new comes up, and it usually does, it goes through a simple change process instead of slipping in quietly. A fixed scope protects the timeline and keeps everyone honest about what done means.

We build the cloud warehouse and run it in parallel with the legacy system, fed from the same sources on the same schedule. That way differences show up during normal daily operation, when there is time to understand them, rather than on cutover day. The legacy system stays the system of record until a phase is signed off.

Matching row counts is a start, not a finish. We reconcile rows, aggregates and reports. At row level, counts and keys match table by table. At aggregate level, totals, sums and distinct counts match across the dimensions that matter, such as period, location and line of business, within tolerances agreed up front. At report level, the reports and dashboards people actually use return the same answers from both systems. Every difference is logged, explained, and either fixed or formally accepted by the data owner. Nothing moves to cutover while a difference is still open.

The people who rely on the data run user acceptance testing with their own questions and their own reports. When a phase meets its acceptance criteria, the business owner signs off in writing. Cutover for that phase happens only after sign-off. Legacy components for that phase are shut down only after the cutover is confirmed stable, never on the strength of a test plan alone, and with legacy data retained as agreed.

After each cutover we stay close for an agreed support period, often called hypercare. We watch load jobs and run times, answer questions, fix issues quickly, and track each one to closure in a shared log. Hypercare ends when the open list is clear and the team who will run the platform day to day is comfortable owning it.

• A complete inventory of the legacy warehouse and its dependencies
• A written scope and phase plan with acceptance criteria for each phase
• Row, aggregate and report level reconciliation results for every phase
• User testing records and a signed approval for each phase before cutover
• A cutover and legacy shutdown plan tied to those sign-offs
• A hypercare issue log and handover notes for your team

Our team brings 90  years of combined experience across many technologies. Tools we often use include: SQL Server, SSIS, Azure Data Factory, Microsoft Fabric, Snowflake, AWS, dbt, Power BI.

A good migration is a quiet one, and we plan every step to keep it that way.

Many dashboards that go unused were not built badly. They were built before anyone agreed what the numbers meant. When reports give different answers to the same question, people stop trusting them and go back to their spreadsheets. Our approach starts with shared definitions and ends with people who know how to use what we built and who own it going forward.

Before anything is drawn on a screen, we sit down with the people who will use the dashboard and agree on the measures that matter. For each one we write a plain definition, the formula, the source, any exclusions, and who owns it. Questions like when a visit counts as a readmission, or which date defines a month, get settled here. The result is a metric dictionary that everyone can read and point to.

Each metric is defined in a single place, a shared data model, and every report draws from it. That means a measure shows the same value whether it appears on an executive summary or an operational drill-down. It also means a definition change is made centrally and flows everywhere, instead of being patched report by report.

We sketch early and show it to users before it is polished. A rough prototype with real data shapes, even on a whiteboard, surfaces the questions people actually ask and the decisions they actually make. We watch how they look for answers and adjust the layout to fit their work, not the other way around.

We deliver in small pieces, review each one with users, and adjust. Each iteration adds a page or a set of measures, checked against the metric dictionary and against the numbers people already trust. Feedback shapes the next round. This keeps the work grounded and avoids a big reveal that misses the mark.

A dashboard is only useful if people open it. We run short training sessions built around real questions from each team, write a simple guide to what is on each page and how to read it, and set up a clear place to ask questions after launch. We also look at usage once it is live, so we can see which pages help and which need rethinking.

Metrics change as the organization changes. We help set up light governance: a named owner for each metric, a simple process for requesting a change, a record of what changed and why, and a regular review of the metric dictionary. This helps keep definitions stable and trusted after we step back.

• A metric dictionary with plain definitions, formulas, sources and owners
• A shared, documented data model behind every report
• Prototypes and iteration notes shaped by user feedback
• Dashboards built and checked against agreed definitions
• Training sessions and a short user guide for each audience
• A governance process for changing and reviewing metric definitions

Tools we often use include: Power BI, SQL Server, Azure, Microsoft Fabric, Excel.

We build dashboards around the questions people ask, and we make sure the answers mean the same thing to everyone.

Claims data holds a detailed record of how care is delivered and paid for, but it rarely arrives ready to answer questions. Codes change, files arrive late, and the same person can appear under more than one identifier. Our method turns raw claims into a clear view of cost and use of care, and then into specific questions worth acting on.

We start by receiving claims, eligibility and provider files and checking them before any analysis. We confirm record counts against control totals, look for gaps in months or claim types, check that codes and dates are valid, and match paid amounts to expected totals. Every issue goes into a data quality log, so everyone knows what the data can and cannot support.

Next, we organize claims around the units people make decisions about. Members are linked across eligibility periods. Providers are rolled up to the practice or facility level using public identifiers such as the NPI. Related claims are grouped into episodes, such as an inpatient stay with its follow-up care, so cost reflects the whole course of treatment rather than single bills.

With the groupings in place, we calculate a consistent set of measures: cost per member per month, cost per episode, admissions and emergency visits per thousand members, readmission rates, and the split of spending by setting of care. Where comparisons cross regions, we use price-adjusted figures so differences reflect how care is used rather than local prices.

Variation is where the useful questions live. We compare groups against fair peers, adjust for differences in the people being served where the data allows, and flag results that sit well outside the norm. Each outlier is reviewed with people who know the work before anyone draws a conclusion, because a high number can reflect sicker patients or a coding change as easily as a real difference in care.

We close each review with a short list of findings, each tied to a specific question, an owner, a suggested next step and a measure to track. Some lead to a care management conversation, some to a contract question, and some simply to better data. We revisit the measures on a regular cycle to see what has changed.

To show the method without touching any client data, here is a short example using a public dataset published by the Centers for Medicare & Medicaid Services: Medicare Geographic Variation by National, State & County (CMS). We use the 2024 data year, all ages, which covers Original Medicare (fee-for-service) beneficiaries.

In 2024, Original Medicare paid $13,605.51 per fee-for-service beneficiary nationally, or $12,553.26 after CMS standardization removes geographic price differences. Across the 50 states and DC, standardized payments per beneficiary ranged from $8,621.85 in Hawaii to $14,679.60 in Florida. Standardization matters. Hawaii's actual, unstandardized figure was $10,613.27. Its local prices are above average, so they partly hid how low its use of care was. Without standardization, Hawaii would not even rank lowest. Emergency department visits point the same way: 506.5 per 1,000 beneficiaries in Hawaii and 620.6 in Florida, against 590.5 nationally. A review would take differences like these as a starting point for questions, not as conclusions.

Illustrative example: if one provider group in an analysis showed a cost per episode 15% above its peer median, the next step would be to check patient mix and coding first, then look at which parts of the episode drive the difference.

• A data quality log and a validated, documented claims dataset
• Member, provider and episode groupings with clear rules
• A defined set of cost and utilization measures
• A variation and outlier review with notes on context
• A short action list with owners and measures to track

Tools we often use include: SQL Server, Azure, Python, Power BI.

We help you see where cost and care vary, and ask the right questions about why.

The best sign of a well-run project is that your team can run what we built without us. From the start, we work as if we are about to hand everything over, because eventually we will. That shapes how we document, how we test, and how we spend time with the people who will own the work after we step back.

Documentation written at the end is usually thin and quickly out of date. We write it alongside the work: what each component does, why it was designed that way, where it gets its data, and what depends on it. Design decisions are recorded with the reasoning behind them, so future changes can be made with confidence. Documentation lives in your environment, in formats your team already uses.

For every scheduled process, we write a runbook covering what it does, when it runs, how to tell if it worked, what to do when it fails, and who to call. Common problems get step-by-step fixes. The aim is that someone on your team who did not build the process can still keep it running on a busy morning. We test each runbook by having a member of your team follow it while we observe, and we fix anything that was unclear or missing.

Every table, field and measure gets a plain description: what it means, where it comes from, how it is calculated, and any known limits. The data dictionary is written for analysts and business users as well as engineers, and it is kept in step with the code as the work changes. Where it helps, we link each entry to the reports that use it, so anyone can trace a number on a dashboard back to its source and see exactly how it was built.

Documents alone do not build confidence. We run a series of knowledge-transfer sessions, each focused on a single area, with time for questions and hands-on practice. Toward the end, your team takes the lead on real tasks while we watch and help, so the first time they handle an issue alone is not the first time they have seen it.

Handover follows a written checklist agreed early in the project: documentation complete and reviewed, runbooks tested, access and credentials transferred to your accounts, monitoring and alerts pointed at your team, open issues listed with owners, and knowledge-transfer sessions completed. That list includes the agreed requirements and the final data checks, and we don't hand over while any item is still open. When every item is done, your designated owner signs off. Until then, the work is not finished.

• Technical and design documentation kept in your environment
• Runbooks for each scheduled process, including failure steps
• A data dictionary written for both technical and business readers
• Recorded or documented knowledge-transfer sessions
• A completed handover checklist and a signed handover
• A list of open items and suggested next steps, each with an owner

Tools we often use include: SQL Server, Azure, Power BI, Azure DevOps or GitHub, SharePoint or Confluence.

We measure our work by how well your team runs it after we leave.