AWS Migration Checklist for Tech-Led Businesses

A migration checklist is not a guarantee of success. It is a record of the decisions and configurations you have deliberately made, so that when something breaks, you know what was intentional and what was not.

Use this as a working document, not a ceremonial one. Tick items when they are actually done, not when someone assumes they are done.

Phase 1: Pre-Migration (Before Anything Moves)

Discovery and inventory

[ ] Application inventory complete: every workload in scope listed with owner, description, and technology stack
[ ] Dependency map produced for each workload (what it calls, what calls it, what databases it uses)
[ ] Network flow analysis run to validate dependency maps against actual traffic
[ ] Data classification complete: personal data, regulated data, and public data identified per workload
[ ] Compliance scope determined: which workloads are in scope for UK GDPR, FCA, PCI DSS, DORA, or sector-specific frameworks
[ ] Third-party software licensing reviewed: any licences that do not transfer to cloud or require Bring Your Own Licence treatment
[ ] Workloads earmarked for retirement rather than migration identified and signed off

Migration strategy

[ ] Migration pattern decided per workload: rehost, replatform, refactor, or retire
[ ] Migration wave plan produced: workloads sequenced by risk and complexity
[ ] Non-production environments allocated to Wave 1
[ ] Target region decided (eu-west-2 London is default for UK data residency requirements)
[ ] Multi-AZ requirements confirmed for production workloads
[ ] Estimated AWS costs produced per workload using AWS Pricing Calculator or Migration Evaluator
[ ] Budget approved for migration period including any overlap costs

Business continuity and compliance

[ ] Rollback plan documented for each workload: how to revert to on-premise if migration fails
[ ] RTO and RPO requirements confirmed per workload
[ ] Compliance and legal sign-off obtained for any workloads with data residency constraints
[ ] Security and risk team informed and engaged
[ ] Vendor or third-party notification obligations reviewed (some contracts require notification of infrastructure changes)

Phase 2: Landing Zone Setup

Account structure

[ ] AWS Organisation created with management account separate from workload accounts
[ ] Account structure decided: per-environment (dev/staging/prod), per-team, per-workload, or hybrid
[ ] AWS Control Tower deployed or equivalent landing zone automation in place
[ ] Service Control Policies (SCPs) defined and applied at the organisation or OU level
[ ] AWS Config enabled in all accounts and all regions in use
[ ] CloudTrail enabled across all regions, logs delivered to central S3 bucket with integrity validation on

Networking

[ ] VPC design finalised: CIDR ranges chosen with future growth in mind, no overlap with on-premise ranges
[ ] Subnet layout defined: public, private, and isolated tiers per AZ
[ ] Connectivity to on-premise established: Direct Connect or Site-to-Site VPN tested end to end
[ ] DNS architecture configured: Route 53 Resolver rules for on-premise hostname resolution
[ ] Network ACLs and Security Group baseline policies applied
[ ] VPC Flow Logs enabled

Identity and access

[ ] AWS IAM Identity Center (formerly SSO) configured and connected to identity provider
[ ] Permission sets defined for human roles (read-only, developer, operator, admin)
[ ] Break-glass root account access secured: MFA enabled, credentials stored in secrets management, never used for day-to-day operations
[ ] Service account (machine identity) strategy defined: IAM roles rather than IAM users with access keys
[ ] Permission boundaries applied where teams will self-serve IAM
[ ] IAM Access Analyser enabled

Security baseline

[ ] AWS Security Hub enabled with relevant standards (CIS AWS Foundations, AWS Foundational Security Best Practices)
[ ] Amazon GuardDuty enabled across all accounts
[ ] Amazon Macie enabled in accounts handling personal data
[ ] KMS key strategy defined: which keys are AWS-managed, which are customer-managed
[ ] S3 Block Public Access enabled at organisation level
[ ] Default EBS encryption enabled

Observability baseline

[ ] Observability platform decided (Datadog recommended for unified infrastructure, application, and log monitoring)
[ ] Infrastructure monitoring agent deployment method agreed: SSM, user data, or configuration management
[ ] Log forwarding architecture designed: CloudWatch Logs to Datadog, or direct agent log tailing
[ ] Baseline dashboards and alert policies defined before first workload arrives
[ ] On-call runbooks written for the AWS environment

Cost management

[ ] Tagging strategy defined and documented: mandatory tags (environment, owner, workload, cost-centre) applied via SCP or AWS Config rule
[ ] AWS Budgets configured with alerts for each account and the consolidated billing account
[ ] AWS Cost Explorer enabled
[ ] Cost allocation tags activated in billing console

Phase 3: Workload Migration (Repeat Per Wave)

Pre-migration for each workload

[ ] Detailed migration runbook written for this workload
[ ] Migration window agreed with stakeholders
[ ] Rollback trigger criteria defined: what will cause you to revert rather than continue
[ ] Database backup taken immediately before migration begins
[ ] Monitoring and alerting confirmed active in target environment
[ ] Smoke test plan written: what will you check after migration to confirm the workload is healthy

Rehost (lift and shift) specific

[ ] AWS Application Migration Service (MGN) agent installed and replication started
[ ] Replication lag monitored: delta should be near zero before cutover
[ ] Test instance launched and smoke-tested in AWS before production cutover
[ ] Security groups applied to target instances
[ ] IAM instance profile attached (replaces any hard-coded credentials)
[ ] CloudWatch agent or Datadog agent installed on target instances

Replatform specific (example: database to RDS)

[ ] RDS instance created in correct VPC, subnet group, and security group
[ ] Encryption at rest enabled using KMS key
[ ] Multi-AZ enabled for production instances
[ ] Parameter group configured to match source database settings
[ ] AWS Database Migration Service (DMS) replication instance created
[ ] DMS replication task running in full-load-and-CDC mode, replication lag near zero
[ ] Application connection strings updated to target RDS endpoint
[ ] Application tested against RDS in staging environment
[ ] Read replicas created if required

DNS and traffic cutover

[ ] New DNS records created in Route 53 pointing to AWS resources
[ ] TTL reduced 24-48 hours before cutover to minimise propagation delay
[ ] Traffic shifted during low-traffic window
[ ] Traffic confirmed hitting AWS environment via monitoring
[ ] DNS TTL restored to normal value after cutover is stable

Post-migration validation

[ ] All smoke tests passing
[ ] Error rates at or below pre-migration baseline
[ ] Response times at or below pre-migration baseline
[ ] No unexpected costs appearing in AWS Cost Explorer
[ ] Logs flowing to observability platform
[ ] Alerts firing correctly on test
[ ] Old on-premise resource scheduled for decommission (do not leave both running indefinitely)

Phase 4: Post-Migration Closeout

[ ] Migration retro conducted: what went well, what did not, what to change for the next wave
[ ] Runbooks updated to reflect how the workload is now operated
[ ] On-premise resources decommissioned or scheduled for decommission
[ ] Final cost comparison: AWS cost vs on-premise cost for migrated workloads
[ ] Security Hub findings reviewed and remediated
[ ] IAM Access Analyser findings reviewed
[ ] Tagging audit: any untagged resources identified and tagged
[ ] Backup and DR tested in AWS: recovery from backup confirmed working
[ ] Compliance evidence collected if required (CloudTrail logs, Config compliance reports, Security Hub findings)

Common Items That Get Missed

Monitoring the old environment after cutover. Teams often shut down on-premise monitoring before the AWS monitoring is fully proven. Keep both running for at least two weeks post-cutover.

Hard-coded IP addresses in application config. On-premise infrastructure often uses static IPs. AWS infrastructure uses private DNS names and changes IPs on restart. Applications referencing hard-coded IPs break silently.

Security group rules that replicate on-premise firewall rules verbatim. On-premise firewall rules accumulate over years. Migrating them wholesale brings the debt with them. Use migration as an opportunity to audit and tighten.

IAM role permissions scoped too broadly. The first working configuration is usually over-permissioned. Scope down before go-live using IAM Access Analyser's policy recommendations.

Backup verification. AWS Backup and RDS automated backups run automatically, but automated backups are only worth something if restores have been tested.

Where Critical Cloud Comes In

Working through this checklist for the first time, across multiple workloads and waves, while keeping production stable throughout, takes more operational bandwidth than most engineering teams have spare. Critical Cloud runs AWS migrations for tech-led businesses as a structured engagement, with the landing zone, observability platform, and compliance controls established correctly from the start. See how it works.