The Cloud Migration Checklist We Use With Every Client

Cloud migrations are not technically difficult. They fail for organizational and planning reasons, not because someone misconfigured a VPC. After leading migrations for companies ranging from 10-person startups to enterprises with hundreds of servers, we have distilled the process into a checklist that consistently prevents the most common mistakes.

Phase 1: Discovery and Assessment

Before you move anything, you need a clear picture of what you have and where it is going.

Inventory Everything

• Catalog all applications with their dependencies, data stores, and integration points
• Map network architecture including firewalls, load balancers, DNS, and VPN connections
• Document data volumes and growth rates for each application
• Identify compliance requirements (HIPAA, SOC 2, PCI-DSS) that affect architecture decisions
• List all third-party integrations and confirm they work in the target environment

The discovery phase is where most teams underinvest. Every hour spent here saves a day during migration.

Classify Your Workloads

Not every application migrates the same way. Use the 7 Rs framework to classify each workload:

1. Rehost (lift and shift) -- move as-is to EC2
2. Replatform -- minor modifications, like moving to RDS instead of self-managed databases
3. Refactor -- re-architect for cloud-native services
4. Repurchase -- replace with SaaS (e.g., Exchange to Microsoft 365)
5. Retire -- decommission applications nobody uses
6. Retain -- keep on-premises for now
7. Relocate -- move to a different cloud region or provider

Our recommendation: Start with rehost for 70% of workloads. Replatform databases and caching layers. Refactor only the applications where cloud-native architecture provides a clear, measurable benefit.

Phase 2: Foundation Setup

Your AWS foundation determines how painful the next three years will be. Get this right.

Account Structure

Organization Root
├── Security OU
│   ├── Log Archive Account
│   └── Security Tooling Account
├── Infrastructure OU
│   ├── Shared Services Account
│   └── Network Hub Account
├── Workloads OU
│   ├── Production Account
│   ├── Staging Account
│   └── Development Account
└── Sandbox OU
    └── Developer Sandbox Accounts

• Set up AWS Organizations with a multi-account strategy from day one
• Enable AWS Control Tower for guardrails and account provisioning
• Configure SSO with your identity provider (Okta, Azure AD, Google Workspace)
• Set up centralized logging in a dedicated log archive account
• Enable CloudTrail in all accounts, all regions

Networking

• Design your VPC architecture with separate VPCs per environment and account
• Plan CIDR ranges that do not overlap with on-premises networks
• Set up Transit Gateway for inter-VPC and hybrid connectivity
• Configure Direct Connect or VPN for hybrid connectivity
• Implement DNS with Route 53 private hosted zones

# Example: VPC module with Terraform
module "vpc" {
  source  = "terraform-aws-modules/vpc/aws"
  version = "5.0.0"

  name = "production"
  cidr = "10.0.0.0/16"

  azs             = ["us-east-1a", "us-east-1b", "us-east-1c"]
  private_subnets = ["10.0.1.0/24", "10.0.2.0/24", "10.0.3.0/24"]
  public_subnets  = ["10.0.101.0/24", "10.0.102.0/24", "10.0.103.0/24"]

  enable_nat_gateway   = true
  single_nat_gateway   = false
  enable_dns_hostnames = true

  tags = {
    Environment = "production"
    ManagedBy   = "terraform"
  }
}

Phase 3: Migration Execution

With the foundation in place, you can start moving workloads.

Migration Order Matters

Migrate in this sequence to minimize risk:

1. Development environments first -- lowest risk, builds team confidence
2. Independent applications with no upstream or downstream dependencies
3. Application clusters -- migrate entire dependency chains together
4. Databases -- use AWS DMS for minimal downtime migrations
5. Customer-facing production workloads last, during maintenance windows

Database Migration Specifics

Databases are the highest-risk part of any migration. Follow these steps:

• Set up AWS Database Migration Service (DMS) replication instances
• Run a full load plus CDC (change data capture) to keep source and target in sync
• Validate data integrity with row counts, checksums, and application-level tests
• Plan the cutover window -- even with DMS, expect 5-15 minutes of downtime for the final switchover
• Keep the source database running for at least 72 hours post-cutover as a rollback option

Cutover Checklist

For each workload cutover:

• Confirm all data is synchronized
• Update DNS records (use low TTLs in advance)
• Verify application health checks pass
• Run smoke tests from the runbook
• Monitor error rates and latency for 30 minutes
• Notify stakeholders of successful migration
• Document any deviations from the plan

Phase 4: Post-Migration Optimization

Migration is not done when the servers are running in AWS. The real value comes from optimization.

• Right-size instances based on actual CloudWatch metrics (not the on-premises specs)
• Implement auto-scaling for variable workloads
• Enable backups with AWS Backup across all accounts
• Set up monitoring with CloudWatch dashboards, alarms, and anomaly detection
• Review security posture with Security Hub and GuardDuty
• Purchase Savings Plans once you have 30-60 days of usage data
• Decommission on-premises infrastructure once rollback windows have passed

Common Mistakes We See

After dozens of migrations, these are the mistakes that keep coming back:

Skipping the proof of concept. Always migrate one non-critical workload end-to-end before committing to a timeline. You will discover networking issues, permission gaps, and process bottlenecks that do not show up in planning.

Underestimating data transfer time. Moving 10TB over a 1Gbps connection takes about 24 hours in theory and 48 or more in practice. For large datasets, use AWS Snowball or set up Direct Connect weeks before the migration.

Ignoring the people side. Your ops team needs training. Your developers need updated workflows. Your security team needs new tools. Budget time and money for this.

Trying to optimize during migration. Migration and modernization are separate projects. Get everything running in AWS first, then optimize. Trying to do both at once doubles the timeline and triples the risk.

---

Planning a cloud migration? Contact SoftStackers for a migration readiness assessment. We will review your environment, identify risks, and build a migration plan tailored to your business.