Cloud migration service providers range from the hyperscaler professional services teams (AWS, Azure, GCP) to boutique shops that specialize in one stack. The right choice depends on the workload type, the team size, and whether the team needs strategy or execution.
Table of contents
- The hyperscaler professional services
- The boutique shops
- The PaaS-as-migration-shop model
- The DIY model
- The decision matrix
- The migration phases
- The data migration
- FAQ
The hyperscaler professional services
AWS Professional Services, Microsoft FastTrack, Google Professional Services. The team that picks one of these is paying for:
- Engineers who know the platform.
- Templates and reference architectures that are battle-tested.
- Direct escalation paths into the platform team.
The downside: cost ($300K-$1M for a real engagement), and the team is sometimes upsold into services they don’t need.
The boutique shops
Boutique shops specialize: one is great at lift-and-shift VMware-to-AWS, another is great at monolith-to-microservices, another is great at data-warehouse migrations. The right shop for the team depends on the migration type.
The team that picks a boutique shop is paying for a narrow expertise that the hyperscaler professional services team doesn’t have.
The PaaS-as-migration-shop model
Some PaaS providers (Heroku, Render, Railway, RunxBuild) include migration services as part of the platform fee. The team that picks this model is paying for:
- The PaaS handles the infrastructure.
- The PaaS provides migration tooling (one-click imports from Heroku, etc.).
- The team keeps the application layer.
This is the right model for the team that is migrating from a managed platform to another managed platform (Heroku to RunxBuild, Render to Railway).
The DIY model
The team that picks DIY is the team that has strong platform engineers and a willingness to spend 6-12 months on the migration. The right tools:
- Terraform for infrastructure.
- Helm for Kubernetes.
- Database replication tools for the data tier.
The downside: the team is on the hook for everything, including the things that go wrong at 3 a.m.
The decision matrix
The four questions that pick the right model:
- Is the team migrating from one PaaS to another? Use the destination PaaS’s migration tools.
- Is the team migrating from a data center? Use a hyperscaler professional services team or a boutique with data-center experience.
- Is the team migrating from one hyperscaler to another? Use the destination hyperscaler’s professional services.
- Is the team rewriting the application at the same time? Use a boutique shop with rewrite experience.
The migration phases
The four phases of a cloud migration:
- Assessment. Inventory the current estate: applications, databases, network, users. Identify what moves easily (lift-and-shift) and what needs refactoring.
- Planning. Choose the target architecture. Plan the data tier migration (often the hardest part). Plan the cutover with the right rollback strategy.
- Migration. Move applications one at a time. Validate each before moving the next.
- Optimization. Once in the cloud, take advantage of cloud-native services: managed databases, serverless, autoscaling.
The team that skips the assessment phase has surprises during migration. The team that skips the planning phase has surprises during cutover. The team that skips optimization is paying cloud prices for the same on-prem architecture.
The data migration
The data tier is the hardest part of any cloud migration. The options:
- Logical replication. Set up the cloud database as a replica of the on-prem primary. When caught up, cut over. Minimal downtime (seconds), some replication lag.
- Dump and restore.
pg_dumpon-prem, restore in the cloud. Simpler but longer downtime (minutes to hours depending on size). - AWS DMS / Azure DMS / GCP DMS. Managed migration services that handle the replication, the cutover, and the validation.
The team that uses logical replication has the lowest downtime. The team that uses dump and restore has a longer window but more predictable timing. The team that uses a managed DMS has the highest cost but the lowest operational overhead.
FAQ
How much does a cloud migration cost?
Depends. Hyperscaler professional services: $300K-$1M for a meaningful engagement. Boutique shops: $50K-$500K. PaaS-as-migration: $0-$50K (the cost is in the platform fees, not the migration services).
How long does a cloud migration take?
Lift-and-shift: 1-3 months. Refactor: 6-12 months. Rewrite: 12-24 months. The team that thinks it will be faster is the team that has not budgeted for the data tier.
What’s the biggest risk in a cloud migration?
The data tier. The team that has not tested the database migration end-to-end (with the production data volume, not a sample) is the team that gets surprised at cutover.
Should I migrate to a different cloud or stay where I am?
If the current cloud is working, stay. The team that migrates for cost reasons rarely recovers the migration cost; the team that migrates for capability reasons (a feature the current cloud doesn’t have) usually does.
How long does a typical cloud migration take?
Lift-and-shift: 1-3 months. Refactor: 6-12 months. Rewrite: 12-24 months. The team that thinks it will be faster is the team that has not budgeted for the data tier.
What’s the most common migration mistake?
Underestimating the data tier. The team that has not tested the database migration end-to-end with production data volume has surprises at cutover.
Can I migrate without downtime?
Yes, with logical replication. The team that needs zero downtime uses DMS or equivalent. The team that can tolerate a few minutes of downtime uses dump and restore.
If you are sizing the infrastructure for the kind of project this post covers, the RunxBuild hosting calculator is the right place to model the line items. The compute, the memory, the storage, the bandwidth, the database - each one is a separate number, and the team’s mental model for the platform is the sum of those numbers. The RunxBuild dashboard is where the team sees the actual usage in one place.
Useful related references: