On-Prem Datacenter to AWS Blueprint
A phased program to exit an on-prem datacenter for AWS. It pairs a Control Tower landing zone and Terraform-coded networking with wave-based rehosting via AWS MGN and selective re-platforming, then optimizes cost and refactors high-value apps.
What and Why
This blueprint moves workloads from a self-run on-premises datacenter to Amazon Web Services (AWS). The drivers are usually expiring hardware leases, datacenter exit deadlines, and the need for elastic capacity. A pure lift-and-shift is rarely optimal, so this plan combines rehosting with targeted re-platforming using the AWS 7 Rs framework (rehost, replatform, repurchase, refactor, retire, retain, relocate).
Phases
Discovery. Build a complete inventory with a tool such as AWS Application Discovery Service or Migration Evaluator. Capture servers, dependencies, network flows, and licensing. Group applications into migration waves and assign each a disposition under the 7 Rs.
Landing zone. Stand up a multi-account AWS Organizations structure with Control Tower. Define the network topology (Transit Gateway, VPCs, Direct Connect or Site-to-Site VPN back to on-prem), centralized logging, guardrails (SCPs), and IAM Identity Center. Codify everything in Terraform so it is reproducible.
Migration waves. Use AWS Application Migration Service (MGN) for block-level replication and rehosting of VMs. Replatform databases to Amazon RDS or Aurora where feasible. Validate each wave in a staging account before cutover, keeping continuous replication so cutover windows stay short.
Optimization. After workloads stabilize, right-size instances, adopt Savings Plans or Reserved Instances, move static assets to S3 and CloudFront, and refactor the highest-value applications toward managed and serverless services.
Decommission. Power down on-prem hardware only after a defined soak period and verified backups, then formally exit the datacenter.
Key Risks and Mitigations
- Hidden dependencies break applications mid-wave. Mitigate with dependency mapping in discovery and wave grouping that keeps tightly coupled systems together.
- Bandwidth limits slow replication. Use AWS Snowball for bulk data seeding and Direct Connect for ongoing sync.
- Cost overrun from oversized rehosted VMs. Enforce tagging, set budgets, and run Cost Explorer reviews each wave.
- Skills gap in cloud operations. Pair migration with enablement and an internal landing-zone runbook.
Recommended Tooling
AWS MGN and DMS for replication, Control Tower and Organizations for governance, Terraform for infrastructure as code, CloudWatch and a third-party observability stack such as Datadog, and AWS Backup for data protection.
Success Metrics
Track migration velocity (servers cut over per wave), realized cost reduction versus the on-prem baseline, application availability through cutover, and mean time to recovery in the new environment.
Prerequisites
A signed datacenter exit timeline, a complete CMDB or discovery dataset, network connectivity (Direct Connect or VPN), a funded landing zone, and executive sponsorship for the wave schedule.