What This Template Is For
Cloud migrations fail when teams treat them as a simple lift-and-shift exercise. Moving workloads to a cloud provider involves dependency mapping, network reconfiguration, security posture changes, cost modeling, and operational readiness work that most teams underestimate by 2-3x. Without a structured plan, teams discover critical dependencies mid-migration, blow past cost projections, and end up running expensive hybrid environments indefinitely.
This template gives you a structured approach to planning cloud migrations from scoping through post-migration validation. It covers workload assessment, dependency mapping, migration wave planning, cost modeling, security controls, and operational readiness checklists. Whether you are moving a handful of services or an entire data center footprint, the template forces you to answer the hard questions before writing any Terraform.
The data migration template covers the data movement layer in detail if your migration includes database transfers. For evaluating cloud provider options, the Technical PM Handbook walks through infrastructure decision frameworks. The risk assessment matrix helps you score migration risks before committing to a wave plan. Understanding availability is critical for defining your migration success criteria.
When to Use This Template
Use this template when moving on-premises workloads to AWS, Azure, GCP, or another cloud provider. Use it when consolidating multi-cloud environments into a single provider. Use it when re-platforming legacy applications for cloud-native architectures. Use it when a data center lease expiration forces a physical-to-virtual migration. Use it when compliance requirements demand moving workloads to a specific geographic region.
How to Use This Template
- Inventory all workloads and dependencies. List every application, service, database, and integration that will be affected. Include upstream and downstream consumers. Missing a single dependency can block an entire migration wave.
- Assess each workload for migration strategy. Decide whether each workload gets a rehost (lift-and-shift), replatform (minor modifications), refactor (rearchitect for cloud-native), or retire treatment. This decision drives timeline and cost.
- Group workloads into migration waves. Cluster tightly coupled services into the same wave. Start with low-risk, low-dependency workloads to build confidence. Save the complex, high-traffic systems for later waves.
- Model costs for both current and target states. Cloud costs are structured differently than on-premises. Factor in compute, storage, egress, managed services, and reserved instance commitments. Compare against current total cost of ownership.
- Define rollback criteria for each wave. Before executing any wave, document exactly what triggers a rollback, how long rollback takes, and who has authority to make the call.
The Template
Migration Overview
- ☐ Project name and identifier
- ☐ Business case summary (why migrate to cloud)
- ☐ Source environment (on-premises, colocation, other cloud)
- ☐ Target cloud provider and region(s)
- ☐ Migration timeline (start date, target completion)
- ☐ Migration owner and cloud architect
- ☐ Executive sponsor
- ☐ Budget allocation and cost ceiling
Workload Inventory
| Workload Name | Type | Current Host | Dependencies | Data Volume | Traffic (RPM) | Migration Strategy | Wave |
|---|---|---|---|---|---|---|---|
| Example: Auth Service | Microservice | On-prem DC1 | PostgreSQL, Redis, API Gateway | 50 GB | 12,000 | Rehost | 1 |
Migration Strategy per Workload
- ☐ Rehost candidates (lift-and-shift, no code changes)
- ☐ Replatform candidates (minor modifications for managed services)
- ☐ Refactor candidates (rearchitect for cloud-native)
- ☐ Retire candidates (decommission during migration)
- ☐ Retain candidates (keep on-premises for now)
- ☐ Strategy rationale documented for each workload
Dependency Map
- ☐ Service-to-service dependencies documented
- ☐ Database dependencies per workload identified
- ☐ External API integrations cataloged
- ☐ Shared storage and file system dependencies mapped
- ☐ Network topology documented (VPNs, firewalls, load balancers)
- ☐ Authentication and identity provider dependencies confirmed
- ☐ Monitoring and logging pipeline dependencies listed
Wave Plan
| Wave | Workloads | Duration | Start Date | Rollback Window | Risk Level | Go/No-Go Owner |
|---|---|---|---|---|---|---|
| Wave 1 | Auth Service, Static Assets | 2 weeks | YYYY-MM-DD | 48 hours | Low | [Name] |
| Wave 2 | ||||||
| Wave 3 | ||||||
| Wave 4 |
Cost Model
- ☐ Current monthly infrastructure cost (on-premises)
- ☐ Projected monthly cloud cost (steady state)
- ☐ Migration execution cost (tooling, consulting, overtime)
- ☐ Dual-running cost during transition period
- ☐ Reserved instance or savings plan recommendations
- ☐ Egress cost estimates for data transfer
- ☐ Break-even timeline calculation
Security and Compliance
- ☐ Identity and access management (IAM) policies defined
- ☐ Network security groups and firewall rules documented
- ☐ Encryption at rest and in transit requirements confirmed
- ☐ Compliance frameworks applicable (SOC 2, HIPAA, GDPR, PCI)
- ☐ Vulnerability scanning approach for cloud resources
- ☐ Key management strategy (KMS, HSM, or equivalent)
- ☐ Security review sign-off obtained
Operational Readiness
- ☐ Monitoring dashboards created for target environment
- ☐ Alerting thresholds configured for cloud metrics
- ☐ Runbooks updated for cloud-specific operations
- ☐ On-call rotation trained on cloud tooling
- ☐ Backup and disaster recovery procedures tested
- ☐ Performance baselines established in target environment
- ☐ DNS cutover plan documented with TTL considerations
Post-Migration Validation
- ☐ Functional smoke tests passed
- ☐ Performance benchmarks met or exceeded on-premises baselines
- ☐ Data integrity verified (record counts, checksums)
- ☐ Security scan completed on target environment
- ☐ Cost actuals compared to projections
- ☐ Decommission plan for source infrastructure documented
- ☐ Stakeholder sign-off obtained
Filled Example
Migration Overview
- ☑ Project name and identifier: Project Nimbus (CLOUD-2026-Q2)
- ☑ Business case summary: Data center lease expires October 2026. Migrating to AWS reduces infrastructure cost by 30% and enables auto-scaling for seasonal traffic spikes.
- ☑ Source environment: Equinix DC2, Chicago (48 servers, 3 racks)
- ☑ Target cloud provider and region(s): AWS us-east-1 (primary), us-west-2 (DR)
- ☑ Migration timeline: April 1 to August 15, 2026
- ☑ Migration owner and cloud architect: Sarah Chen (Engineering Lead), Marcus Rivera (Cloud Architect)
- ☑ Executive sponsor: VP Engineering, David Park
- ☑ Budget allocation and cost ceiling: $340K migration budget, $28K/month target run rate
Workload Inventory
| Workload Name | Type | Current Host | Dependencies | Data Volume | Traffic (RPM) | Migration Strategy | Wave |
|---|---|---|---|---|---|---|---|
| Auth Service | Microservice | DC2-APP-01 | PostgreSQL, Redis | 12 GB | 15,000 | Rehost | 1 |
| Static CDN | File Server | DC2-WEB-03 | S3 bucket (new) | 800 GB | 45,000 | Replatform | 1 |
| Order Service | Monolith | DC2-APP-04/05 | PostgreSQL, RabbitMQ, Payment API | 340 GB | 8,000 | Replatform | 2 |
| Analytics Pipeline | Batch Jobs | DC2-DATA-01 | Kafka, Redshift (new) | 2.1 TB | N/A (batch) | Refactor | 3 |
| Legacy Reporting | Desktop App | DC2-APP-02 | Oracle DB | 90 GB | 200 | Retire | N/A |
Cost Model
- ☑ Current monthly infrastructure cost: $42,000/month (colocation + hardware amortization)
- ☑ Projected monthly cloud cost: $28,500/month (after reserved instances)
- ☑ Migration execution cost: $180,000 (tooling licenses, contractor support, overtime)
- ☑ Dual-running cost during transition: $22,000/month for 4 months
- ☑ Reserved instance recommendations: 1-year RI for production compute (saves 38%)
- ☑ Egress cost estimates: $4,200 for initial data transfer
- ☑ Break-even timeline: Month 11 post-migration
Security and Compliance
- ☑ IAM policies: Role-based access with SSO via Okta. Service accounts use IAM roles, not keys.
- ☑ Network security: VPC with private subnets. Public access only through ALB. VPN to office network.
- ☑ Encryption: AES-256 at rest (EBS, S3, RDS). TLS 1.3 in transit.
- ☑ Compliance: SOC 2 Type II. AWS Config rules enforce compliance controls.
- ☑ Vulnerability scanning: AWS Inspector weekly. Snyk for container images in CI/CD.
- ☑ Key management: AWS KMS with customer-managed keys. Key rotation every 90 days.
- ☑ Security review: CISO sign-off obtained March 15, 2026.
Key Takeaways
- Map dependencies before grouping waves. Tightly coupled services must migrate together. Discovering a hidden dependency mid-wave forces rollback or creates a fragile hybrid state.
- Model costs with dual-running periods included. Teams often compare on-premises cost to cloud cost and forget they will pay for both during the transition. Budget for overlap.
- Start with low-risk workloads to build confidence. Early wins teach the team cloud operations patterns before they tackle the high-traffic, high-risk systems.
- Define rollback triggers quantitatively. "If error rate exceeds 2% for 15 minutes" is actionable. "If things look bad" is not.
- Test DNS cutover separately from application migration. TTL propagation issues can cause hours of partial outages. Practice the DNS flip in staging first.
- Decommission source infrastructure on a schedule. Without a firm decommission date, teams keep legacy environments running "just in case" and pay double indefinitely.