On-Prem to Cloud Migration in 2026: A Practical Playbook
Datacenter leases are expiring, VMware licensing costs have jumped, and hardware refresh cycles keep landing at the worst possible time. If 2026 is your year to move to the cloud, here is the vendor-neutral playbook — six phases from discovery to cutover — and how to run it visually instead of in a hundred spreadsheets.
Why 2026 is a migration year
Three forces are converging. Virtualization licensing changes have made "just keep it on-prem" materially more expensive. AI workloads want GPUs and managed data services that are painful to run in your own racks. And the tooling to migrate — infrastructure as code, live cloud discovery, AI-assisted architecture — has finally matured to the point where a mid-size estate can move in months, not years. The bottleneck is no longer technology. It is planning, sequencing, and keeping everyone looking at the same picture.
The six phases
Every successful migration, regardless of cloud, follows the same arc:
Phase 1 — Discover & inventory
You cannot migrate what you cannot see. Pull an inventory from vCenter (RVTools), System Center, or a discovery tool like Azure Migrate or AWS Application Discovery Service. Capture, for every asset: CPU/memory/disk, OS, the application it belongs to, and — critically — its dependencies. The dependency graph is what later turns into your wave plan. Shadow IT and undocumented integrations are where migrations go to die, so over-invest here.
Phase 2 — Assess with the 6 R’s
The industry-standard framework (used by both AWS and Azure migration methodologies) sorts every workload into one of six strategies:
- Rehost — lift-and-shift to cloud VMs. Fast, low-risk, minimal benefit.
- Replatform — swap a component for a managed equivalent (SQL Server → managed database). The sweet spot for most workloads.
- Refactor — re-architect for cloud-native (containers, serverless). Highest effort, highest payoff.
- Repurchase — drop the workload for a SaaS product.
- Retire — decommission what nobody uses (usually 10–20% of an estate).
- Retain — keep on-prem for now (latency, compliance, or a pending decision).
We wrote a deep dive on the 6 R’s with worked examples if you want to go further.
Phase 3 — Design the target state
This is where migrations become real — and where most teams stall, because the target architecture lives in someone’s head or a stale Visio. Draw it. Each workload needs a home: the network it sits in, the identity model, the data services, the compute. This is exactly what a visual cloud designer is for. In CloudForge you can drag the target resources onto a canvas, or describe the workload to Vani — the AI architect — and let it propose the cloud-native shape ("a Windows app tier behind an Application Gateway, SQL Server replatformed to a managed database, blob storage for assets").
Phase 4 — Model the cost
The board approved this migration on a business case. Protect it. Before committing a workload to a design, compare its current on-prem run-rate (hardware amortization, power, cooling, licensing, ops) against the projected cloud cost of the target design. CloudForge estimates cost as you design, so an over-provisioned "lift-and-shift" VM shows its true monthly number before it ever ships. See our TCO calculation guide for the full model.
Phase 5 — Plan the waves
Big-bang migrations fail. Instead, group workloads into waves ordered by dependency and risk: foundational shared services first (identity, networking, the landing zone), then low-risk / low-dependency apps to build muscle, then the crown jewels. Each wave is a self-contained project with its own cutover and rollback plan. The dependency graph you captured in Phase 1 tells you what can move together.
Phase 6 — Generate IaC and cut over
The target design should not be re-typed by hand into Terraform — that is where drift and errors are born. Generate it. CloudForge turns the target-state diagram into production-ready Terraform (or Pulumi, ARM, Bicep, or CloudFormation), runs a security scan and a plan diff, and waits for human approval before applying. Deploy the landing zone, migrate the workloads wave by wave, validate against the design with drift detection, and decommission the on-prem originals only once each wave is confirmed healthy.
Doing it visually, end to end
The thread running through all six phases is a single shared picture. When discovery, target design, cost, and IaC all live in the same tool, the migration stops being a relay race between spreadsheets and becomes one continuous flow: design the target, see the cost, generate the code, deploy, verify. That is the workflow CloudForge is built for — and it is free to start.