Cloud migration strategies for data platforms

Moving a data platform to the cloud is rarely a single project. It is a series of decisions, made workload by workload, about how much to change along the way.

The common strategies

• Rehost — move as-is to cloud infrastructure. Fast, but carries over existing problems and often costs more than expected.
• Replatform — move to managed services with modest changes, such as a managed database or managed Spark. A common sweet spot.
• Refactor or rebuild — redesign for cloud-native services, such as a lakehouse on open table formats. Highest effort, highest long-term value.
• Retire — switch off what nobody uses. Every migration should find some of these.

Start with an inventory

List every database, pipeline, report and integration, with owners, volumes, dependencies and how often each is used. Dependencies are where migration plans most often go wrong.

Build the landing zone first

Before moving workloads, put a secure, governed foundation in place: account structure, networking, identity, logging, encryption defaults and cost tagging — all as code. Retrofitting these later is far more expensive.

Migrate in waves

Group workloads into waves by dependency and risk. Start with something meaningful but low-risk, prove the pattern, then accelerate. Each wave needs a tested cut-over plan and a rollback path.

Plan for cost from day one

Cloud bills surprise people who did not plan for them. Tag everything, set budgets and alerts, and review spend with owners every month. Right-size after migration, once you see real usage.

Do not forget security

A migration changes your attack surface. Review identity and permissions, storage exposure and network paths before go-live. A cloud security posture review at the end of each wave catches the misconfigurations that cause most cloud incidents.

Our cloud solutions team plans and runs migrations like this across AWS, Azure and Google Cloud.