Moving on-premise infrastructure to AWS buys elasticity, managed services, and a shift from CapEx to OpEx, eliminating hardware refresh cycles and datacenter overhead. But cloud is not automatically cheaper: for steady-state workloads, cloud run-cost can exceed amortized on-prem hardware. The honest first step is deciding which workloads should move and how, and being willing to conclude that some shouldn’t.
Decide per workload: the 6 Rs
Don’t move everything the same way. Classify each workload:
- Rehost (“lift and shift”), replicate the VM as-is to EC2; fastest, least optimization.
- Replatform, minor changes, e.g. self-managed DB → RDS.
- Refactor, re-architect for cloud-native services (highest effort, highest payoff).
- Repurchase, move to a SaaS equivalent.
- Retain, leave it on-prem (steady-state, latency-bound, or compliance reasons).
- Retire, decommission what’s unused.
The classic mistake is rehosting everything and being surprised by the bill. Spiky, elastic, or growth workloads win in the cloud; flat, predictable, high-utilization workloads often don’t.
A useful way to sequence the 6 Rs is by risk and payoff. Retire first, because the cheapest workload to migrate is one you delete, and most estates carry servers no one has justified in years. Then rehost the low-risk, stateless services to prove the pipeline end to end. Save refactor for workloads where cloud-native services genuinely change the economics or the operability, since it is the highest-effort path and not every workload earns it. Repurchase where a SaaS equivalent removes the workload from your plate entirely. The point of classifying up front is that it forces the awkward conversations, such as which systems are latency-bound to the datacenter or bound by data-residency rules, before those constraints derail a cutover.
Landing zone and connectivity come first
Build the AWS landing zone first: accounts (Organizations), networking (VPC, subnets, security groups), identity (IAM/SSO), and guardrails. Establish connectivity, Direct Connect for sustained bandwidth or a Site-to-Site VPN for smaller estates, both for replication and for hybrid operation during the transition.
The native tooling: MGN, DMS, DataSync
- Servers: AWS Application Migration Service (MGN), block-level replication of on-prem VMs/physical servers into EC2 with minimal downtime.
- Databases: AWS DMS (full load + CDC) to keep the target current until cutover.
- Bulk data: DataSync for file shares; Snowball for very large datasets where network transfer is impractical.
Re-platform infrastructure as code (CloudFormation/Terraform) and map each on-prem service to a managed equivalent where you’re replatforming.
Data movement and connectivity
Match the transfer method to the data. Databases ride DMS with change data capture so the source keeps serving users while the target catches up, which is what makes near-zero-downtime cutover possible. File shares and unstructured data move with DataSync over your Direct Connect or VPN link, and for the largest datasets a Snowball device sidesteps the bandwidth problem entirely by shipping disks. Size the connectivity to the replication window you need, not just to steady-state traffic: an underbuilt link is the most common reason a migration slips. Where you are replatforming a self-managed database onto RDS, treat the engine version and extension compatibility as a checklist item before the pilot, not a discovery during it.
Codify the target, and keep Retain reversible
Stand up the AWS side as code, not console clicks. CloudFormation or Terraform gives you a reviewable definition of the target, a staging copy to pilot against, and a repeatable pattern so each successive workload is cheaper to land than the last. Encode the network, the IAM model, and the guardrails together so security is designed in rather than retrofitted. This is also what makes the “Retain” decision reversible later: if a workload you left on-prem eventually earns its way to the cloud, the landing pattern is already written and tested.
Pilot, cut over, then validate against the business case
- Replicate a pilot workload + database end to end and validate before scaling.
- For each group: final delta sync via MGN/DMS, freeze source writes, cut over DNS (Route 53), and validate apps, integrations, and cost.
- Run a hypercare window with on-prem as fallback; keep replication until sign-off.
The acceptance bar is functional + integration parity, performance at baseline, validated cost, and a DR/failover test, and an honest check that the cloud run-cost matches the business case. Cutover is not finished when the VMs boot: it is finished when the workload behaves correctly, costs what you modeled, and survives a simulated failure. Pilot a single low-risk workload through this whole sequence first, so the runbook and the rollback path are proven before you point production at AWS.
Model the steady-state cost honestly
Before committing, baseline each workload’s steady-state cloud run-cost against amortized on-prem (hardware + power + space + ops). Egress, inter-AZ transfer, and managed-service premiums are what tip steady workloads back toward on-prem. If the numbers don’t favor the cloud for a given workload, “Retain” is a legitimate, money-saving answer, that’s exactly what the calculator is for.
The honest recommendation
On-premise → AWS pays off for elastic, growth, and spiky workloads, and the native tooling (MGN, DMS, DataSync) makes the mechanics routine, but rehosting steady-state workloads blindly is how cloud bills balloon. Classify with the 6 Rs, lead with the landing zone, pilot before scaling, and model steady-state cost honestly. Use the per-vCPU calculator above to compare, and treat the figures as illustrative until your pilot and real utilization confirm the business case.