This category runs both ways. Adoption (on-prem → cloud) buys elasticity, managed services, and opex. Repatriation (cloud → on-prem / private cloud) is an increasingly common move when steady-state workloads turn out to cost more in the cloud than on owned hardware. The right direction depends on workload shape, and the answer is often “it depends,” which is exactly what the calculator is for.
The cost reality
For steady-state workloads, cloud run-cost frequently exceeds amortized on-prem hardware + power + ops, so repatriation can save meaningfully. For spiky or unpredictable demand, the cloud’s elasticity usually wins. Egress, inter-AZ/region transfer, and managed-service premiums are what tip steady workloads toward repatriation. Model both with your real utilization, not list rates.
The decision is workload-shaped, and the answer is usually “some of each.” Owned hardware is cheapest when it runs near capacity around the clock, because the amortized cost per useful hour is low and no meter is running. The cloud is cheapest when demand swings, because you pay for what you use instead of provisioning for a peak you rarely hit. The trap in both directions is a blanket decision: teams that lift everything into the cloud are surprised by the steady-state bill, and teams that repatriate everything are surprised by the capacity limits and ops load they took back on. Decide per workload, not per estate.
Adoption (on-prem → cloud)
Build the cloud landing zone, establish connectivity, then replicate servers with AWS MGN / Azure Migrate / Google Migrate to VMs and databases with the cloud DMS. Re-platform IaC and map each on-prem service to a managed equivalent. Sync storage, validate, and cut over DNS. Classify workloads with the 6 Rs first, and be willing to Retain the flat, high-utilization systems that cost more on metered cloud than on amortized hardware, since rehosting everything blindly is the classic way a cloud bill balloons.
Repatriation (cloud → on-prem)
Stand up the target hypervisor/private cloud + storage and network, sized for the workloads coming back plus N+1 headroom. Export/replicate VMs (VM Import/Export, Veeam, or V2V) to your hypervisor, rehydrate object/database data (aws s3 sync, etc.), rebuild networking and managed-service equivalents, then validate and cut over DNS, keeping the cloud environment as fallback. The VMs are the easy part: the friction is the proprietary managed services with no on-prem equivalent, where you take back DBA work, host your own object storage, and re-architecture around anything that ran on serverless or managed queues. Capacity planning returns too, since you cannot burst beyond the hardware you bought, and so does the operational load that managed services quietly absorbed.
Signing off, whichever way you moved
Functional + integration tests per app, performance and cost validation versus the source, failover/DR resilience, and a DNS-cutover rehearsal with rollback.
Prove the case before you commit capacity
Baseline steady-state cost vs the source to confirm the business case, replicate a pilot in the intended direction, and verify the data-rehydration path and capacity before scaling. In either direction, prove the cost case per workload before committing hardware or reserved-capacity spend, since both are commitments that are awkward to unwind. Egress is a one-time cost that belongs on its own line, not folded into the steady-state comparison. Keep the source environment as a fallback through hypercare until the target is validated on function, performance, and cost.
Use the TCO calculator to model a per-vCPU comparison.