By the Cycloid Platform Engineering team, practitioners building and operating enterprise IDPs since 2015.
Direct Answer. The main solutions for cloud migration fall into four categories: (1) native cloud tools (AWS Migration Hub, Azure Migrate) for inventory and lift-and-shift, (2) dedicated migration platforms (AWS Application Migration Service, Carbonite, Zerto) for workload replication, (3) IaC-driven frameworks (Terraform, OpenTofu, Pulumi) for reproducible provisioning, and (4) IDP-native platforms (Cycloid) that govern the migrated estate from day one – combining self-service provisioning, cost visibility, and multi-cloud governance in a single platform.
Cloud migration is one of the most expensive engineering initiatives an organisation undertakes. Gartner analysts have consistently reported that 60% of cloud migration projects go over budget, and roughly 40% miss their delivery deadline. The root cause is rarely the migration itself – it is what happens after. Native migration tools handle the lift-and-shift; they do not solve the governance, cost visibility, and drift problems that emerge in the first 90 days on the new cloud.
This guide covers the four main solutions for cloud migration in 2026, why 60% of projects blow their budget, how an IaC-driven approach reduces that risk, what MSPs need for repeatable multi-client migrations, and where an IDP like Cycloid fits alongside (not instead of) the native migration tools.
The 4 Main Cloud Migration Solutions
Four distinct categories cover the market. Most enterprise migrations combine two or three of them; picking the wrong category as the anchor is the fastest way to blow the budget.
1. Native Cloud Migration Tools
AWS Migration Hub, Azure Migrate, and GCP Migrate for Compute Engine are the provider-supplied migration tools. They handle three things well: discovery of the source estate (typically via lightweight agents on VMs), dependency mapping (what talks to what), and lift-and-shift migration of workloads to the target cloud.
Strengths: no additional cost (bundled with the target cloud), tight integration with the destination provider, first-party support.
Weaknesses: single-cloud only (Azure Migrate does not migrate to AWS), lift-and-shift bias (does not encourage refactor), no governance layer for the migrated estate. Once workloads land in the new cloud, the platform team is on their own.
2. Dedicated Migration Platforms
AWS Application Migration Service (formerly CloudEndure), Carbonite Migrate, Zerto, and similar platforms handle workload replication with block-level or continuous data protection. They deliver near-zero downtime cutovers, which is why regulated industries and mission-critical workloads prefer them.
Strengths: minimal downtime, cross-hypervisor and cross-cloud support in some cases, strong for physical-to-cloud migration.
Weaknesses: focused on replication, not governance. Post-migration, the source-of-truth is still the source infrastructure, not a declarative target.
3. IaC-Driven Migration Frameworks
Terraform, OpenTofu, and Pulumi are the industry-standard IaC tools. In a migration context, they define the target-state cloud environment declaratively. Combined with pipeline automation, this produces reproducible, version-controlled migrations – the same Terraform code that migrates production can migrate staging, and both stay in sync.
Strengths: reproducible, auditable, cloud-agnostic, becomes the standard operating model after migration completes. Reverse-engineering tools like Inframap and TerraCognita can bootstrap Terraform from existing cloud estates, reducing manual template authoring.
Weaknesses: IaC alone does not run the migration – it defines the target. It also does not enforce policy or estimate cost without additional tooling. Platform team owns pipeline maintenance forever.
4. IDP-Native Cloud Migration Platforms
An Internal Developer Platform sits above the IaC layer, exposing self-service templates through a portal. Cycloid runs the IaC (Terraform, OpenTofu, Pulumi, Helm), enforces InfraPolicies at the pipeline layer, surfaces pre-deployment cost estimates, and provides real-time infrastructure visibility across AWS, Azure, GCP, and on-prem through InfraView.
Strengths: governance and cost visibility from day one of the migrated estate, self-service provisioning ready for developers post-cutover, multi-tenancy for MSPs, IaC-agnostic execution.
Weaknesses: IDP-native platforms do not replicate workloads or handle the discovery phase – use alongside native migration tools, not instead of them. The IDP owns everything after the workload lands in the new cloud.
For a broader view of the IDP category itself, see our 2026 best internal developer platforms analysis. For Azure-specific migration coverage, see our Migration Tools for Azure guide.
Cloud Migration Challenges: Why 60% of Projects Go Over Budget
The pattern is consistent across enterprise migrations we have observed. Three root causes recur:
Inconsistent environments between on-premises and cloud. Source infrastructure was built organically over a decade; target infrastructure needs to be defined in a way that maps to cloud-native concepts. This translation gap – what the on-prem VM does versus what the cloud VM should do – is where scope creeps first. Teams that skip IaC in favour of “we’ll clean it up later” almost always land in over-budget territory.
Manual provisioning at scale. Migrating 500 workloads with hand-crafted scripts works until the 200th workload, when the platform team hits the wall. Every environment needs the same tags, the same RBAC, the same monitoring hooks – and every one of them looks slightly different because a human wrote it. IaC-driven provisioning is the discipline; IDP-native provisioning takes the discipline further by removing the platform team from the critical path.
Governance gaps discovered only after go-live. Cloud costs run 40% higher than the pre-migration business case in the first quarter of most projects. Flexera’s 2026 State of the Cloud Report put average IaaS and PaaS waste at 29%, driven partly by AI workload sprawl. Tagging is inconsistent, ownership is unclear, and untagged resources show up in the CFO’s monthly report. The teams that catch this at day one (through FinOps solutions integrated into the migration pipeline) do not have this problem.
IaC-Driven Cloud Migration: The Scalable Approach
The core of a scalable migration is treating the target environment as code. The migration itself becomes a Terraform (or OpenTofu, Pulumi) apply against the target cloud; the source-of-truth moves from the on-prem infrastructure to the Git repository.
Four steps for an IaC-driven migration framework:
- Discover the source estate. Use native tools (Azure Migrate, AWS Migration Hub) or third-party discovery to inventory VMs, databases, network topology, and dependencies. Output: a mapped source-of-truth.
- Reverse-engineer to Terraform where possible. Tools like TerraCognita scan the source cloud (if the migration is cloud-to-cloud) and emit Terraform code. For on-prem source, the templates need to be written; discovery data feeds the schema.
- Provision the target through a pipeline. Every apply runs through CI/CD with policy checks (Policy as Code) and pre-deployment cost estimation. See our Terraform compliance audits guide for the audit-log setup.
- Cut over workloads via a dedicated migration platform. AWS Application Migration Service or Zerto handles the actual data replication and cutover. IaC-defined target environment receives the workload.
The migration finishes. The IaC framework does not. Post-cutover, the same Terraform templates become the day-to-day provisioning mechanism. Migration becomes the moment the platform team standardises the operating model – if they use IaC properly, they inherit self-service provisioning and drift detection alongside the migrated workloads.
Cloud Migration for MSPs: A Repeatable Framework
Managed Service Providers running 5-20 migrations per year face a variant of the problem native tools were not built for: repeatability across clients.
Every migration is technically different – different source environments, different target clouds, different compliance requirements – but the framework does not have to be. The MSP-scalable stack has three layers:
- Discovery and replication: AWS Application Migration Service or Azure Migrate. Native tools per target cloud. Client-specific configuration but consistent tools.
- IaC target-environment definition: parameterised Terraform modules that accept per-client inputs (VPC ranges, IAM role structures, tagging conventions). Cycloid Stacks package these as reusable templates the MSP applies across engagements.
- Post-migration governance: IDP with multi-tenancy. Cycloid Child Organizations provide per-client isolation of catalog, cost, and RBAC out of the box. Each client sees only their own resources; the MSP platform team sees the aggregate.
The economic case: an MSP that reuses 60-70% of the migration framework across clients turns migration engineering from a per-project cost into a productised offering. See our Managed Service Providers solutions page for the wider MSP context.
FAQ
What are the best solutions for cloud migration?
The best cloud migration solutions in 2026 fall into four categories. Native cloud tools (AWS Migration Hub, Azure Migrate, GCP Migrate for Compute Engine) handle inventory and lift-and-shift within one provider. Dedicated migration platforms (CloudEndure, now AWS Application Migration Service; Carbonite; Zerto) handle workload replication. IaC-driven frameworks (Terraform, OpenTofu, Pulumi) produce reproducible target environments. IDP-native platforms like Cycloid govern the migrated estate from day one with self-service, drift detection, and cost visibility.
What is the difference between cloud migration tools and cloud migration platforms?
Cloud migration tools are typically point solutions for one part of the migration – workload replication, inventory discovery, or database migration (AWS Application Migration Service, Azure Migrate). Cloud migration platforms are broader products that combine multiple tools with orchestration, project tracking, and cost modelling. IDP-native platforms go a step further by governing the migrated estate day-one – self-service provisioning, drift detection, and cost visibility persist long after the initial lift-and-shift finishes.
How do you migrate to the cloud with IaC?
IaC-driven migration works in four steps. (1) Discover the source estate using tools like Azure Migrate or CloudEndure. (2) Write Terraform or Pulumi templates for the target-state infrastructure. (3) Provision the target environment through a pipeline with policy enforcement and cost estimation. (4) Cut over workloads. Cycloid’s TerraCognita (open source) can reverse-engineer existing cloud environments into Terraform code, which speeds step 2 significantly. Post-migration, IaC-driven provisioning becomes the standard operating model.
What is the best cloud migration solution for MSPs?
MSPs running cloud migrations for multiple clients need a repeatable, IaC-driven framework with per-client isolation. The typical stack: native migration tools (AWS Application Migration Service, Azure Migrate) for the lift-and-shift phase; an IaC layer (Terraform, OpenTofu) for target environment definition; and an IDP with multi-tenancy (Cycloid Child Organizations) to govern the post-migration estate per client. This combination replaces bespoke migration engineering with a repeatable template applied per engagement.
How does Cycloid help with cloud migration?
Cycloid is the IDP layer above the migration – not a lift-and-shift replacement. Its role: provide Terraform, OpenTofu, and Pulumi templates for the target environment; run self-service provisioning during and after migration; enforce InfraPolicies from day one; provide cost visibility (Cloud Cost Management) and drift detection (InfraView) on the migrated estate; and handle multi-tenancy for MSPs running migrations across clients. Use Cycloid alongside AWS Application Migration Service or Azure Migrate, not instead of them.
Planning a cloud migration? See how Cycloid governs the migrated estate from day one – alongside your existing AWS or Azure native migration tools.
Book a demo
