DCF Research

Cloud Data Platform Migration: Target, Phases and Partners

By DCF ResearchEdited by Peter KorpakPublished · Updated

Choose the migration target in two layers: the cloud that hosts the data (AWS, Azure or Google Cloud) and the data platform on top of it (a native service such as Redshift, Fabric or BigQuery, or a cross-cloud platform such as Snowflake or Databricks). Base the decision on where your data and applications already run, your skills and BI tools, your cloud contracts, workload fit and cost, then run the move as a phased program that starts with a pilot.

This guide is part of our platform modernization research. For warehouse-specific work such as code conversion and validation, see our legacy data warehouse modernization guide.

What are your target options on AWS, Azure and Google Cloud?

Each cloud has a native analytics stack, and Snowflake and Databricks run on all three. The choice is between your cloud's integrated services and a platform that spans clouds.

LayerAWSAzureGoogle Cloud
Object storageAmazon S3; S3 Tables store Apache Iceberg tablesAzure Data Lake Storage and OneLakeCloud Storage
Native warehouseAmazon RedshiftFabric Data WarehouseBigQuery
Open table formatsIceberg through S3 Tables, queried by Athena, Redshift and SparkDelta Lake and Iceberg in OneLake through metadata virtualizationIceberg tables in the Lakehouse runtime catalog, readable by BigQuery and open source engines
Cross-cloud platformsSnowflake, DatabricksSnowflake; Azure Databricks, a first-party service billed by MicrosoftSnowflake, Databricks

Three details affect the shortlist:

Our data platform TCO guide explains how each option is priced.

How do you choose between the clouds and platforms?

Weigh seven criteria, with weights set before vendor meetings, then test the top two options on your own workload.

CriterionAskEvidence to collect
Data gravity and transferWhere do source systems, consumers and partners run? How much data crosses regions or clouds each month?Monthly volume per path times transfer rate. As of October 2026, Snowflake lists $0 within a region and $90 per TB to another cloud or the internet (AWS US East); AWS lists $0.09 per GB to the internet
Skills and BI toolsWhich engines, languages and BI tool does the team already use?A skills inventory and a count of BI users. On Fabric, report viewers need Power BI Pro licenses on capacities below F64 (Microsoft, as of October 2026)
Contracts and commitmentsDo you hold a cloud spending commitment, and can the platform draw it down?Microsoft lists Fabric capacity as eligible for Azure Consumption Commitment drawdown. Snowflake says marketplace purchases on AWS, Azure and Google Cloud are eligible for drawdown. Databricks order terms list separate AWS Marketplace, GCP Marketplace and Azure commit types. Terms and caps vary by contract
Workload fitIs the work mostly SQL and BI, or also streaming, ML and unstructured data? What concurrency and latency do you need?Proof-of-value results on your own queries and pipelines
Openness and exitCan other engines read your tables? What would leaving cost?Support for Iceberg or Delta; exit-fee waivers; the EU Data Act ban on switching charges from 12 January 2027
Compliance and regionWhich regions, certifications and residency rules apply?Provider and platform region lists, attestations, data residency requirements
Total costWhat is the three-year total, not the unit price?The model in our TCO guide, filled with measured usage

A starting rule of ours: when most data and applications already run on one cloud and the team knows its tools, that cloud's native stack is the option to beat. Cross-cloud platforms earn their place when you operate on several clouds, want one engine across them, or need something the native service lacks. Multi-cloud for its own sake adds transfer cost and skills overhead. AWS, Google Cloud and Microsoft each waive internet egress fees for customers that move off, but the UK Competition and Markets Authority found their programs do not cover ongoing multi-cloud use.

What phases does the migration program follow?

All three clouds describe the same arc: assess, build a foundation, migrate in waves, then optimize. AWS names its phases Assess, Mobilize, Migrate and Modernize. Google uses Assess, Plan, Deploy and Optimize. Microsoft's Cloud Adoption Framework runs Strategy, Plan, Ready, Adopt, Govern, Secure and Manage.

  1. Assess and decide. Inventory data sets, pipelines, consumers and compliance constraints. Build the cost model, shortlist targets, and run a proof of value on a representative workload.
  2. Build the foundation. Set up the landing zone (accounts or subscriptions, identity, network, encryption, logging), data governance (catalog, access policies, classification), cost tags and budgets, and deployment pipelines. Microsoft's framework includes a data platform scenario for preparing data for analytics and AI.
  3. Pilot one domain end to end. Include the security review, cost measurement and the support model. Use the effort you measure to calibrate the plan.
  4. Migrate in waves. Pick a transfer approach for each data set. Google's large-dataset guide lists scheduled maintenance, continuous replication, dual write and read, and a data-access service, chosen by data volume, change rate, tolerance for downtime and consistency needs. It suggests testing with a sample of the data, typically 3 to 5%, before the full transfer.
  5. Cut over and decommission. Agree exit criteria first, keep a fallback period, then retire sources and end the contracts.
  6. Optimize and govern. Review spend against the cost model each month, revisit commitments once usage is steady, and settle the operating model.

Treat each wave as a mini-program with its own acceptance test. The legacy data warehouse guide covers validation, parallel runs and report repointing in detail.

How do you select a cloud data migration partner?

Match the partner to your target and your source system, then verify credentials with the vendors and with customers. Use the cloud providers' partner programs and the platform vendors' directories as filters, not as proof of delivery quality.

ProgramWhat it shows
AWS Partner NetworkSelect, Advanced and Premier services tiers. The Migration and Modernization Competency requires Advanced or Premier tier; the Data Competency has an analytics category
Microsoft partner specializationsSolutions Partner for Data & AI (Azure), plus specializations such as Analytics on Microsoft Azure and Data Warehouse Migration to Microsoft Azure. Analytics on Microsoft Azure requires $15,000 of Azure consumed revenue over three months from at least three customers, five certified individuals and an audit
Google Cloud Partner NetworkSelect, Premier and Diamond tiers, and competencies such as Data & Analytics
Snowflake partner directorySelect, Premier and Elite badges, shown per listing, so a firm's regional entities can differ
Databricks partner directoryConsulting and system integrator partners with regions and solution areas, not Select, Premier or Elite badges

Examples of what the directories show (checked October 2026): Snowflake's directory lists Capgemini, Quantiphi, phData and Tiger Analytics with an Elite badge, and all four also appear in Databricks' directory as consulting partners. Some firms concentrate on one cloud: SADA, a long-time Google Cloud specialist, now operates as part of Insight. Read the published requirements before leaning on a badge, and remember that DCF Research has not audited any firm's client work.

Ask every candidate for the following:

  1. Two references with your source system and target, from customers you can call.
  2. Named people for the target, with the relevant certifications, and what happens if they leave.
  3. The partner's migration method, mapped to the cloud provider's own phases.
  4. A landing zone and governance design, not only a data copy plan.
  5. A proof-of-value plan on your workload with measured units, as described in the TCO guide.
  6. Commercial terms by phase, with acceptance tied to evidence, a cost-handover plan and clear ownership of accelerators.

Our RFP template turns these into questions. For Snowflake-specific partners, see our Snowflake consultants research.

Frequently asked questions

Do we need a different partner for each cloud?

Not necessarily. What matters is whether the people assigned to your project have delivered on your target. Ask for named engineers with certifications on it, and for references. A single partner can cover several clouds if those people hold the right skills.

How do we limit lock-in?

Keep data in open table formats where the workload allows (see our lakehouse guide), model exit costs in the business case, and read the commit terms before signing. The EU Data Act bans switching charges from 12 January 2027, and in the meantime allows only cost-based charges.

How should we move very large volumes?

Compare transfer time over your network with any offline transfer option your cloud provider offers, test with a 3 to 5% sample as Google suggests, and move in waves rather than one cutover. Choose replication or scheduled transfer by how often the data changes and how much downtime you can tolerate.

Sources

More in Platform Modernization

← Back to Insights