Migration and modernization

Assessing and selecting workloads

• Migration phases (AWS Cloud Adoption Framework and Prescriptive Guidance): assess, mobilize, migrate and modernize. Assessment sets business case, readiness and the portfolio plan. Mobilize builds the landing zone (Control Tower), skills, and security baseline.
• AWS Application Discovery Service collects server inventory, configuration, performance and network dependencies. Agentless collector (for VMware vCenter) gives configuration and utilization; the Discovery Agent on each server adds running processes and network connections for dependency mapping. Data goes to Migration Hub, and exports to Athena.
• AWS Migration Hub is the central place to track discovery and migration progress across tools, with strategy recommendations and Migration Hub Refactor Spaces for incremental refactoring behind a proxy (strangler fig pattern). Migration Hub orchestrator provides workflow templates.
• Migration Evaluator (formerly TSO Logic) builds a right-sized TCO and business case from on-premises utilization data, for a quick cost comparison before any migration.
• Pricing Calculator estimates AWS cost; the Cloud Adoption Framework and migration readiness assessment cover people and process.
• Portfolio assessment: list every application, owners, dependencies, technologies, licence terms, compliance, criticality and end-of-support dates. Group related servers into waves. Early waves hold small, low-risk, loosely coupled apps to build skills; later waves take complex, tightly coupled or high-risk ones; shared dependencies (databases, identity, DNS) must migrate with or before their dependents.
• TCO: compare on-premises total (hardware, facilities, power, licences, staff, refresh cycles, existing contracts) against AWS (compute, storage, transfer, support, migration cost). Savings often come from rightsizing, licence changes, and reduced operations, not raw unit price. Include one-time migration cost, parallel-run cost and productivity gain.

The seven Rs

• Pick rehost for speed or deadlines (data centre exit, lease end), replatform for quick managed-service gains, refactor when scalability or agility justify the cost. Many questions test choosing the lowest-effort strategy that meets the stated goal.
• AWS Transform (the newer agentic service family) assists with .NET, mainframe and VMware transformation; AWS Mainframe Modernization supports replatforming (Micro Focus runtime) and automated refactoring of COBOL to Java.

Server and application migration

• AWS Application Migration Service (MGN): the standard rehost tool, successor to CloudEndure Migration and Server Migration Service. Install the replication agent on each source server (physical, VMware, Hyper-V, other clouds); it continuously replicates block-level to a staging area (low-cost EC2 replication servers and EBS in a staging subnet). When ready, launch test instances then cutover instances (minutes of downtime), using launch templates and post-launch actions. An agentless option for vCenter uses snapshot-based replication. It requires network access from sources to the Regional replication endpoints (port 1500 to replication servers, 443 for the service), either over the internet, a VPN or Direct Connect.
• VM Import/Export converts and imports a single VM image into an AMI (one-off, no continuous sync) - the manual approach.
• AWS Elastic Disaster Recovery uses the same technology for DR rather than migration.
• App2Container (A2C) containerizes existing Java and .NET applications for ECS or EKS without code changes, producing images and deployment artifacts (retiring in favour of AWS Transform; treat as a replatform-to-containers option).
• Containers and serverless targets belong to the replatform and refactor Rs.
• Windows and SQL Server licensing: bring your own licence with License Manager, Dedicated Hosts for per-socket or per-core licences, License Included instances, AWS Optimization and Licensing Assessment to cut licence cost, RDS Custom for SQL Server or Oracle when you need OS access.
• VMware: VMware Cloud on AWS (relocate with HCX) or Amazon Elastic VMware Service (EVS) keep VMware tooling and IPs.

Data migration

Decide with this table, starting from data size and available bandwidth.

• Time math: 100 TB over a 1 Gbps link at full speed takes about 9 days, so with typical efficiency of 70-80 percent and shared links, Snowball is often faster. For recurring deltas after a bulk load, use DataSync or DMS CDC.
• Hybrid approach: ship Snowball for the bulk, then DataSync or replication for the delta since the snapshot, then cut over.
• Security of migration tools: encrypt in transit (TLS; DataSync, DMS endpoints with SSL), encrypt at rest with KMS (S3, EBS, RDS targets), private connectivity (Direct Connect, VPN, VPC endpoints for DataSync), IAM roles with least privilege for each tool, source and target security groups limited to the replication ports, Snow device encryption and chain-of-custody tracking, CloudTrail logging of migration API calls, and S3 bucket policies on the landing bucket.
• Large objects and uploads: multipart upload for objects over 100 MB (required above 5 GB; maximum object 5 TB), S3 Transfer Acceleration, parallel threads, S3 Batch Operations for bulk actions on existing objects.

Database migration

• AWS Database Migration Service (DMS): replication instances (or DMS Serverless) read from a source endpoint and write to a target endpoint. Task types: full load, full load plus CDC (change data capture, ongoing replication for minimal downtime), CDC only. Supports homogeneous (Oracle to Oracle, MySQL to Aurora MySQL) and heterogeneous (Oracle to PostgreSQL) migrations, plus S3, Kinesis, Redshift, DynamoDB and others as targets. The source stays online. Validation checks data after load; premigration assessments flag issues. A replication instance in Multi-AZ provides resilience.
• AWS Schema Conversion Tool (SCT) and DMS Schema Conversion convert schema, stored procedures and application SQL for heterogeneous migrations (Oracle or SQL Server to PostgreSQL or Aurora), and report the manual work remaining. Use SCT first, then DMS for the data. The SCT data extraction agents move big warehouse data (Teradata, Oracle, Netezza) into Redshift, using Snowball when required.
• Native tools for homogeneous moves: backup and restore for SQL Server to RDS (native backup to S3), Oracle Data Pump, MySQL mysqldump, Percona XtraBackup from S3 into Aurora MySQL, PostgreSQL logical replication or pg_dump, Aurora read replica of an RDS MySQL or PostgreSQL instance then promote (simple low-downtime path into Aurora), RDS blue/green deployments for upgrades.
• Babelfish for Aurora PostgreSQL lets SQL Server applications connect with T-SQL and TDS with minimal code changes.
• Choosing the mechanism:

• Networking for migrations: DMS needs connectivity from the replication instance to the source (VPN or Direct Connect or public endpoint with allow lists) and to the target (same VPC or peered). Plan DNS cutover with low TTL, and Route 53 weighted routing for gradual shift.

Networking, identity and governance for the migration

• Connectivity: VPN for quick start, Direct Connect for sustained throughput and latency, both for resilience; Transit Gateway for many VPCs; hybrid DNS with Route 53 Resolver; plan CIDRs that don’t overlap with on premises.
• Identity: extend Active Directory with AWS Managed Microsoft AD (trust to on-premises, or standalone), AD Connector (proxy to on-premises AD, no cache), Simple AD (basic, legacy), IAM Identity Center for workforce access to AWS accounts using the corporate IdP. Domain-join EC2 with Systems Manager. For hybrid workloads authenticating against on-prem AD, keep a trust and DNS forwarding or deploy domain controllers on EC2.
• Governance: build a landing zone with Control Tower before moving workloads; separate accounts for production, non-production, shared services, network, log archive and security; SCPs for guardrails; Config conformance packs; Service Catalog; tagging standards; central logging. Use the Cloud Foundations approach so each wave lands into a governed environment.

Choosing target architecture for existing workloads

• Compute:

• Containers:

ECS task roles, ALB per-service targets, service discovery with Cloud Map or ECS Service Connect, Fargate Spot for cheap interruptible tasks, EKS IRSA or Pod Identity.

• Storage:

• Databases:

Modernization

• Decouple components: put SQS between producers and consumers, SNS for fan-out, EventBridge for event routing between services and SaaS, Step Functions for orchestration instead of code-driven workflows, Kinesis or MSK for streams, API Gateway or VPC Lattice for service interfaces. Decoupling lets tiers scale and fail independently and enables buffering of spikes.

• Serverless opportunities: Lambda for event-driven code, API Gateway or ALB in front, Step Functions for workflows, Fargate for containers, Aurora Serverless v2 for variable relational load, DynamoDB on-demand, S3 plus CloudFront for static sites, Cognito for authentication, AppSync for GraphQL, Athena for ad hoc queries, Glue for ETL, Kinesis Firehose for delivery. Benefits: no servers to patch, scale to zero, pay per use. Limits to check: 15-minute Lambda, cold starts, 29-second API Gateway timeout, and long-lived connections (use WebSockets through API Gateway or ALB).
• Containers vs serverless: choose containers for existing containerized apps, long-running services and Kubernetes portability; choose Lambda when the code is event-driven and short.
• Purpose-built databases: split one big relational database into stores that fit each pattern - DynamoDB for sessions and carts, ElastiCache for leaderboards and hot reads, Neptune for relationships, OpenSearch for search, Timestream for metrics, Redshift for analytics. Use DMS as the data bridge.
• Strangler fig approach: put an API Gateway or ALB (or Refactor Spaces) in front of the monolith and route one function at a time to new services. Event-driven integration helps the old and new systems coexist during the move.
• Integration selection: workload queue SQS; broadcast SNS; routing by event content EventBridge; stateful multi-step Step Functions; high-throughput ordered streams Kinesis or MSK; protocol compatibility Amazon MQ.
• Data lake and analytics modernization: S3, Glue Data Catalog, Lake Formation, Athena, EMR, Redshift Spectrum, QuickSight.