Migrating Data to the Cloud: Governance Before You Migrate
Migrating data to the cloud without governance is like moving house without knowing what is in each box. The result is predictable: duplicate data, orphaned tables, PII exposed in environments that do not meet regulatory requirements, broken dependencies, and months of post-migration cleanup that could have been avoided.
This guide proposes a different approach: establishing the foundations of governance before migrating, not after. The pre-migration inventory, dependency mapping, and sensitive data classification are steps that most organizations discover they needed only when it is too late. Doing them beforehand reduces risk, cost, and migration time.
Why Governance Before Migration, Not After
The main reason is that migrating data without knowing it amplifies existing problems. If you do not know which tables are obsolete, you will migrate obsolete tables. If you do not know which fields contain PII, you will expose PII in a cloud environment that may be more accessible. If you do not know the dependencies between tables, you will break downstream pipelines you did not know existed.
The cost of cleaning and organizing data after migration is 3 to 5 times greater than doing it beforehand. In the cloud, every stored table has a cost (storage), every query has a cost (compute), and every poorly migrated piece of data generates correction work in a new environment where the team is still learning. Migrating with governance means migrating only what you need, well documented and correctly classified.
Moreover, cloud platforms (BigQuery, Snowflake, Redshift, Databricks) offer native governance capabilities (labels, access policies, audit logs) that are much easier to configure correctly during migration than retroactively. If you arrive in the cloud with a clean inventory and sensitivity classifications, you can take advantage of these capabilities from day one.
Pre-Migration Inventory: What You Have and What You Need
The pre-migration inventory answers three questions: What data do we have? Which of it is necessary? And which can we leave behind? A data catalog connected to your on-premise sources automatically extracts the metadata of all your tables: name, schema, volume, last update, columns, and relationships.
With the complete inventory, classify each asset into one of three categories. "Migrate": active assets with known consumers and business value. "Archive": historical assets needed for compliance but not for operations (move them to cold storage in the cloud). "Delete": obsolete assets with no consumers or retention requirements. In a typical migration, between 20% and 40% of assets can be archived or deleted, reducing the scope and cost of migration.
For each asset classified as "migrate," document: the responsible owner, known consumers (teams and dashboards), freshness requirements (does it need to be updated in real-time, daily, weekly?), and security requirements (does it contain PII? What is the confidentiality level?). This documentation guides architectural decisions in the cloud.
Dependency Mapping with Lineage
Data lineage is critical before a migration because it reveals non-obvious dependencies. A table that seems unimportant may be feeding 15 views and 3 executive dashboards. If you migrate that table incorrectly or with a schema change, 15 downstream processes break without warning.
Pre-migration lineage is built by analyzing the SQL queries executed against your data sources, view definitions, ETL jobs, and BI tool connections. The result is a dependency graph that shows, for each table, what feeds it (upstream) and what consumes it (downstream). This graph is the basis for planning the migration order.
The migration order should follow the dependencies: first the source tables (with no upstream dependencies within the migration scope), then derived tables that depend on them, and finally consumers (dashboards, reports, APIs). Migrating in reverse order creates time windows where downstream processes point to a source that no longer exists or has a different schema.
Classifying Sensitive Data Before Migration
Migrating data to the cloud without classifying its sensitivity is a direct regulatory risk. PII data that was protected in an on-premise environment by the corporate network perimeter is exposed to a different access model in the cloud. Access, encryption, and retention policies must be defined before data arrives in the new environment.
Pre-migration classification identifies every field containing personal data (name, email, national ID, phone number, IP address), sensitive financial data, health data, or other regulated data. For each classified field, define: sensitivity level (public, internal, confidential, restricted), access policy (which roles can view it), encryption policy (at rest and in transit), and retention policy (how long it is kept).
Automated PII detection tools can scan the entire inventory and automatically flag fields containing personal data. This turns a manual process of weeks (reviewing every column of every table) into a scan of hours. The result is a sensitivity map that guides the configuration of access policies in the cloud environment from the very first moment.
Migration Plan with Integrated Governance
A migration plan with integrated governance has four phases. Phase 1 (weeks 1-2): inventory and classification. Connect a data catalog to your on-premise sources, extract complete metadata, classify assets (migrate/archive/delete), identify PII, and assign owners. Result: migration scope defined and documented.
Phase 2 (weeks 3-4): dependency mapping and order planning. Build lineage for all in-scope tables, identify critical dependencies, define the migration order (sources first, derived tables next, consumers last). Validate with domain owners that the plan is correct. Result: validated migration sequence.
Phase 3 (weeks 5-8): migration in waves. Migrate in waves following the lineage order. For each wave, verify: correct schema at destination, complete data (record counts), quality rules passing, access policies configured, and downstream pipelines reconnected. Use the catalog as the source of truth for the status of each asset.
Phase 4 (weeks 9-10): validation and decommission. Run quality rules in parallel (on-premise vs. cloud) to verify consistency. Confirm with consumers that dashboards and reports are working correctly. Disconnect on-premise sources only when validation is complete. Document the final architecture in the catalog.
Post-Migration: Monitoring and Continuous Governance
Migration does not end when data arrives in the cloud. The post-migration period (first 3-6 months) is critical for detecting problems that did not appear in initial validation: queries slower than expected, compute costs exceeding projections, quality rules failing intermittently, and new data being created without governance.
Set up active monitoring for the first months: data quality alerts on migrated tables, storage and compute cost monitoring by domain, automatic detection of new undocumented tables or columns, and tracking of the actual usage of migrated assets (to identify tables that were migrated but nobody consumes).
Establish the governance process for the new environment from day one. Every new table must have an owner, a description, and a sensitivity classification before going to production. Quality rules must be configured as part of the pipeline, not added afterwards. The data catalog must be the first stop for anyone who wants to find, understand, or use data in the new cloud environment.
Migrating data to the cloud with governance is not a luxury: it is the most efficient way to do it. The pre-migration inventory reduces scope (and cost) by eliminating obsolete assets. Dependency mapping prevents incidents by defining the correct order. Sensitivity classification ensures compliance from day one. And post-migration monitoring detects problems before they impact the business.
Organizations that integrate governance into their migration plan report 30-40% fewer post-migration incidents, 20-30% reduction in storage costs (by not migrating obsolete data), and significantly shorter time-to-value because teams can find and use data from day one in the new environment.