Moving data infrastructure to the cloud creates a specific class of analytics risk: the period during which source systems, pipelines, and consumption layers are in different states of migration. Managing analytics continuity through a cloud migration requires explicit planning that most migration programmes omit.
Moving data infrastructure to the cloud creates a specific class of analytics risk that most cloud migration programmes fail to plan for explicitly: the period during which source systems, data pipelines, and BI consumption layers are in different states of migration. A source system that has already moved may have different connection requirements. A pipeline that was rebuilt in the cloud may produce subtly different output. A dashboard that worked against on-premise data may produce different results against the cloud equivalent. Managing analytics continuity through a cloud migration requires architectural decisions and governance practices that migration project plans rarely include.
The Migration Window Problem
Cloud migrations are not instant cutovers. They unfold over months — sometimes years — with workloads migrating in phases by business unit, by system, or by risk profile. During this window, the analytics estate sits in an unstable state. Some data is in the cloud; some is still on-premise. Some pipelines have been rebuilt; some are still running against legacy sources. Some dashboards have been validated against new data; some have not.
The migration window creates three specific risks for analytics:
**Silent data drift** — the cloud equivalent of a source system produces data that is structurally identical but numerically different. This happens when migration teams correctly migrate the transactional system but do not match the business logic embedded in ETL processes, stored procedures, or extraction queries. Dashboards continue to populate; the numbers are wrong. Users may not notice for weeks.
**Broken lineage** — data pipelines that previously ran against on-premise databases need to be reconfigured for cloud endpoints. During migration, pipeline configurations may reference sources that have been moved without the pipeline being updated. Extract jobs fail silently, historical data stops updating, and dashboards show stale data without indication that anything has changed.
**Inconsistent reporting periods** — when a source system migrates mid-month, the analytics dataset for that month will have been built from two different sources. Unless the migration architecture explicitly handles this, the reporting entity for that period will be incomplete, duplicated, or split across two data stores.
The Parallel Run Architecture
The standard approach to managing analytics continuity during cloud migration is the parallel run: maintain both the legacy and cloud data pipelines simultaneously, producing output from both, and validating that results match within acceptable tolerances before decommissioning the legacy pipeline.
The parallel run architecture requires:
**Dual extraction** — extract from both legacy and cloud source systems for the same time periods. This doubles extraction load during the migration window, which requires capacity planning.
**Reconciliation layer** — a data reconciliation process that compares output from legacy and cloud pipelines at the metric level. For each key metric on each key dashboard, the reconciliation checks that cloud output matches legacy output within tolerance (typically less than 0.1% variance for exact figures; tolerance may be wider for estimated metrics). Mismatches are flagged and investigated before cutover.
**Version-controlled migration tracking** — a metadata table that tracks, for each source system, pipeline, and dashboard, whether it is running against legacy infrastructure, cloud infrastructure, or both. This makes it possible to audit the state of the analytics estate at any point during the migration.
**Explicit cutover process** — the migration is complete not when the cloud infrastructure is running, but when the reconciliation layer has validated that cloud output matches legacy output and the legacy pipeline has been decommissioned. Cutover should be a documented, scheduled event — not something that happens implicitly when the legacy system is turned off.
BI Layer Considerations
The BI layer — Tableau, Power BI, or similar — has its own migration considerations. Workbooks that use live connections to on-premise databases need to be reconfigured for cloud endpoints. Published data sources that point to on-premise extracts need to be rebuilt against cloud equivalents.
For Tableau specifically, the migration involves updating data source connection details, republishing certified data sources, and revalidating published workbooks against the new data sources. The Tableau REST API can automate parts of this — particularly the inventory of which workbooks connect to which data sources, so the migration team knows the full scope of BI assets that need to be updated when each source system migrates.
For organisations running Tableau Server, the cloud migration may also involve migrating Tableau Server itself to Tableau Cloud. This is a separate migration track — the source data migration and the Tableau platform migration — that need to be coordinated but can proceed on different timelines.
What Gets Skipped and Why It Matters
Most cloud migration projects are scoped and resourced for infrastructure migration — moving compute and storage to cloud services. The analytics and BI workstream is frequently scoped as a small part of the project (update connection strings, validate dashboards), which consistently underestimates the work required.
The underestimation comes from treating the BI layer as passive — as something that just reads data and displays it. In practice, the BI layer contains significant business logic. Calculated fields, table calculations, and level-of-detail expressions in Tableau. Measures and calculated columns in Power BI. DAX in Analysis Services. These calculations depend on the structure and grain of the underlying data, and if the cloud migration changes that structure or grain — even subtly — the calculations break.
Finding these breaks after cutover, when users are reporting wrong numbers in production dashboards, is significantly more expensive than finding them during a structured parallel run validation. The cost of the parallel run architecture is front-loaded; the cost of skipping it is tail-loaded and higher.
Our cloud engineering and managed BI practice manages analytics continuity through cloud migrations — contact us to discuss your migration programme.
A former Microsoft data architect audits your data foundation, identifies your top priorities, and sends you a written plan. Free. No pitch.
Book a Call →