10 AWS Migration Best Practices for 2026: A Practical Execution Guide

AWS migration best practices are the controls that turn a move from an on-premises or other-cloud environment into a measurable AWS delivery program. The sequence matters: assess workloads, choose a migration path, build the governed foundation, validate data movement, rehearse cutover, and measure the operating result.

This guide is for CTOs, enterprise architects, and cloud program leads who need an AWS-specific execution baseline. It does not replace the cloud migration assessment checklist or the cloud migration risk assessment framework; it shows what to do with that evidence once an AWS migration is in scope.

1. How should you assess and sequence workloads for AWS?

Before a workload enters an AWS migration wave, record its boundary, owner, dependencies, performance baseline, data obligations, target path, acceptance criteria, and rollback conditions. A migration inventory becomes useful only when each field has an evidence source, collection date, and accountable owner.

Build the evidence pack before the roadmap

Use the cloud migration assessment checklist for the broader evidence gates. For an AWS workload, add the details that affect service selection and cutover:

1. Identify the application, databases, shared services, environments, repositories, business owner, and technical owner.
2. Map upstream and downstream connections, including low-frequency batch jobs, identity providers, third-party APIs, DNS dependencies, and shared databases.
3. Capture representative CPU, memory, storage, IOPS, throughput, latency, concurrency, and peak-period behavior.
4. Record data classification, residency, retention, encryption, RPO, RTO, licensing, and support requirements.
5. Define the AWS target region, account, network path, operating model, and measurable acceptance tests.

Do not approve a wave because a discovery tool produced a graph. AWS discovery tools and partner tooling reduce manual collection; workload owners still need to validate undocumented dependencies and business behavior.

Use the current AWS planning path

As of August 6, 2026, AWS documentation says that AWS Migration Hub stopped accepting new customers on November 7, 2025. Existing customers can complete in-flight projects, while new migration projects should evaluate AWS Transform, which AWS describes as the successor with migration and modernization workflows. Remove Migration Hub from new-project runbooks unless the project is already an existing customer engagement.

That tool change belongs in the assessment record. Name the discovery and planning service, the data it collects, the team that validates it, and the artifact that becomes the migration decision. A tool choice without an evidence handoff does not improve migration readiness.

2. What AWS foundation should exist before the first migration wave?

An AWS migration needs a governed account and identity baseline before application teams create production resources. Establish account boundaries, federated access, centralized logging, network controls, encryption, and policy guardrails; use AWS Control Tower when its landing-zone model fits the organization rather than treating it as a universal command.

Design the landing zone around operating responsibilities

AWS Prescriptive Guidance on Control Tower landing zones describes a pattern for automating account structure, identity, federated access, and controls. Whether Control Tower creates the baseline or your platform team implements an equivalent design, assign owners for:

• Account structure: Separate production, non-production, security, networking, and log-archive responsibilities where the organization needs isolation and independent billing.
• Identity: Use federated workforce access, short-lived elevated permissions, named workload identities, and a documented break-glass path. Avoid copying broad on-premises roles into AWS IAM.
• Logging and detection: Centralize CloudTrail and AWS Config evidence, protect log accounts from routine administrator access, and define retention and alert ownership.
• Network boundaries: Document VPC, subnet, routing, DNS, ingress, egress, and hybrid connectivity decisions. Add Transit Gateway or equivalent routing services when the connectivity pattern requires them, not because the product name appears in a checklist.
• Controls: Put preventive checks in policy-as-code or organization controls, then add detective controls for the exceptions that preventive controls cannot block.

As of August 6, 2026, AWS’s Landing Zone 4.0 migration guide describes optional service integrations. Review the version and integrations available on the date of implementation; enable the controls the workload and operating model require, and record exceptions instead of enabling every service by default.

3. How should you build the AWS migration business case?

An AWS migration business case should compare a measured current baseline with explicit target scenarios. Include one-time migration work, recurring compute and storage, licenses, data transfer, NAT and inter-AZ traffic, backup, monitoring, support, dual-running, partner services, and the modernization work needed after the first cutover.

Separate measured costs from assumptions

Use AWS Migration Evaluator to support a data-driven business case, then label every input by source, date, unit, and confidence. A credible model contains:

1. Current utilization and license costs, not only the capacity listed in a CMDB.
2. At least one AWS scenario with instance, storage, region, support, backup, observability, and data-transfer assumptions.
3. Sensitivity cases for utilization, data growth, egress, dual-run duration, licensing, and support coverage.
4. A 12- or 36-month view that separates migration spend from steady-state operating spend.
5. The metric that will prove or disprove the business case after go-live.

Treat AWS Migration Acceleration Program (MAP) support as a current eligibility and delivery-planning question, not as a fixed percentage in the model. AWS program terms and partner incentives change. Confirm the current offer, required assessment or mobilization artifacts, eligible workloads, and payment conditions with the AWS account team or participating partner before counting the support as committed funding. The AWS MAP incentives announcement is a starting point, not a substitute for current approval.

Do not promise that AWS will be cheaper because the invoice moves from a data center to a cloud account. The business case is only as strong as its utilization evidence, architecture assumptions, and post-migration measurement.

4. How should you use the AWS 7 Rs to choose a migration path?

The AWS 7 Rs—rehost, relocate, replatform, refactor or rearchitect, repurchase, retire, and retain—give each workload a decision label. The label is not the decision by itself: connect it to business value, dependency constraints, code scope, AWS service choices, licensing, data movement, and the condition that would make the team revisit it.

Map each path to an AWS delivery consequence

Path	AWS-specific consequence	Evidence to record
Rehost	Move with limited application change, often using AWS Application Migration Service; plan for later rightsizing and modernization.	Compatibility, capacity, licensing, dependency routing, rollback, and post-move backlog.
Relocate	Move an existing virtualized workload to a compatible AWS service, such as VMware Cloud on AWS, with minimal change to the application.	Hypervisor and version compatibility, network path, licensing, support model, and exit or modernization plan.
Replatform	Change a managed runtime or data service, such as moving a self-managed database to Amazon RDS, without redesigning the whole application.	Engine compatibility, service limits, data validation, performance tests, and cutover plan.
Refactor / rearchitect	Change code or replace the design to use AWS services such as containers, managed databases, or event-driven components when smaller changes cannot meet the requirement.	Code and architecture scope, test coverage, release capacity, observability, transition stages, cost model, and ownership.
Repurchase	Replace a self-managed application with a SaaS product or commercial service.	Data export/import, integrations, identity, contract, retention, and exit requirements.
Retire	Remove a workload with no continuing business or technical justification.	Owner approval, data-retention decision, decommission steps, and evidence of no remaining dependency.
Retain	Keep the workload where it is until a defined trigger makes migration worthwhile.	Reason to defer, source-environment support plan, review date, and trigger to revisit.

AWS Prescriptive Guidance notes that large migrations commonly use rehost, replatform, relocate, and retire, while strategy suitability depends on the workload. Use the 7 Rs as a portfolio vocabulary, but do not make “refactor everything” or “lift and shift everything” the default.

5. How should you validate an AWS database migration before cutover?

Use AWS DMS as a controlled migration pipeline: run a proof of concept, convert or review the schema, perform the full load, replicate changes with CDC when the workload allows it, validate source and target data, monitor task health, and resolve objects DMS does not create automatically before approving the cutover.

Plan for what DMS does not carry for you

AWS’s DMS best-practices documentation states that basic schema migration does not automatically create secondary indexes, foreign keys, user accounts, and other database objects. Treat those as explicit migration tasks. For a full-load-plus-CDC task, plan the point at which indexes, constraints, and triggers are created or enabled; the order affects both load performance and application behavior.

Use this sequence for a production database:

1. Run a small proof of concept, then a representative full-scale test to measure throughput, network latency, source load, target capacity, and large-object behavior.
2. Review source and target schemas, data types, permissions, indexes, constraints, triggers, stored procedures, and extensions. Record what requires manual creation or code change.
3. Complete the full load, enable AWS DMS data validation, and investigate mismatches rather than treating a green task status as proof of application correctness.
4. Monitor replication and table metrics in Amazon CloudWatch, including incoming and committed changes, source/target latency, rows loaded, and rejected rows. Review task logs for truncation and foreign-key errors.
5. Set a cutover threshold for lag, validation mismatches, error rate, and business acceptance. The owner who can stop or defer the cutover must be named before the change window.

Do not describe DMS CDC as real-time replication. AWS states that CDC has no service-level agreement for replication latency, and latency can rise with transaction volume, network conditions, replication-instance capacity, target throughput, LOB data, batch work, or maintenance. If the workload requires sub-second or guaranteed low-latency replication, evaluate native database replication or a purpose-built streaming design instead.

6. Which AWS cutover approach gives production teams a usable rollback?

Choose an all-at-once or phased cutover from the application’s dependency and routing constraints. Both approaches require an ingestion freeze or equivalent data-control step, final backup, data synchronization, routing change, validation, operational readiness review, rollback checkpoints, and one named decision owner.

Compare all-at-once and phased cutover

Approach	Use when	Required controls	Rollback profile
All at once	The application is tightly coupled, cannot tolerate split routing or cross-environment latency, or has hostname, licensing, or authentication constraints.	Extensive functional and non-functional testing; a defined failback caller; final backup and sync; hard entry and exit criteria.	Traffic can return through DNS or load-balancer changes when no new data has been written. A data plan is required after new transactions reach AWS.
Phased / canary	The application supports split traffic, resilient tiers, compatible load balancing, and a data path that can operate across the transition.	Small initial traffic slice; continuous monitoring; dependency and latency checks; progressive load increases; operational readiness review.	Usually faster to reverse because traffic can be shifted back while the source environment remains available, but the data strategy must cover writes made in both environments.

AWS Prescriptive Guidance’s cutover-stage guidance describes the sequence as ingestion freeze, backup, final data sync, routing changes, and testing. It also recommends defined rollback checkpoints, a rollback and data strategy, and a named person to decide whether to fix forward or roll back. Use those items in a cutover workbook.

For a rollback after new data reaches AWS, choose the data strategy before the window: fail-forward replication to a designated database, application-supported dual writes, or a tested backup-and-restore path. A traffic switch is not a rollback plan if the source database is already stale.

7. Which AWS security controls belong in the migration foundation?

Security controls should be mapped to workload data, identities, regions, and regulatory requirements before migration. Use least-privilege IAM, encryption, centralized audit evidence, network boundaries, and detection services such as GuardDuty, Security Hub, and Macie where their coverage fits the workload; do not treat service activation as the security design.

Turn security requirements into ownership

• Identity: Replace copied, standing on-premises roles with job-specific human and workload identities. Review privileged access, break-glass use, service-account rotation, and segregation of duties.
• Data protection: Map data classification to encryption at rest and in transit, key ownership, rotation, backup, retention, and deletion. Confirm that the target service and region satisfy the requirement.
• Detection: Decide which accounts and regions require GuardDuty, Security Hub, Macie, CloudTrail, AWS Config, and notification routing. Define who triages findings and how exceptions expire.
• Network and exposure: Review public endpoints, security groups, network ACLs, egress, administrative paths, DNS, and third-party connections. Make the expected exposure explicit before the first workload arrives.
• Evidence: Store control tests, exceptions, approvals, and remediation dates in the same operating record as the migration wave.

The cloud migration risk assessment framework owns the scored heatmap and mitigation vocabulary. Link to it when a program needs likelihood-impact scoring; keep this page focused on the AWS controls that implement the mitigation.

8. How should AWS infrastructure and network changes be controlled?

Use one reviewed Infrastructure as Code path for AWS resources—CloudFormation, AWS CDK, Terraform, or a deliberately documented combination—and make every production change traceable to a pull request, plan, policy check, and deployment identity. IaC reduces drift only when console changes are detected, reconciled, or prohibited.

Standardize the change path

1. Define reusable modules or stacks for accounts, networking, logging, identity, encryption, and common workload patterns.
2. Run formatting, validation, security-policy checks, and a plan or diff in CI before approval.
3. Require peer review from the service owner and security/platform owner for changes that alter exposure, identity, data paths, or production capacity.
4. Use separate deployment roles and environments; do not allow a developer workstation to hold unrestricted production apply permissions.
5. Detect drift and reconcile out-of-band changes. A console exception must have an owner, expiry, and code follow-up.

For hybrid migrations, document the temporary network and DNS state as carefully as the final AWS state. Hardcoded IP addresses, undocumented firewall rules, and shared services left behind on-premises are common reasons a phased cutover cannot scale beyond the pilot.

9. What should an AWS migration pilot prove before scale-up?

A pilot should validate the migration factory, not only show that one server can boot in AWS. Choose a representative but recoverable workload and measure dependency completeness, security controls, data validation, latency, errors, cost allocation, monitoring, runbooks, support ownership, and rollback before approving the next wave.

Set pilot entry and exit criteria

Pick a workload with enough production-like behavior to expose the migration method, but with a bounded blast radius. Before the pilot starts, name:

• the source and target environments;
• the migration pattern and AWS services;
• success thresholds for performance, availability, data integrity, security findings, and cost;
• the cutover and rollback commands or runbook;
• the person who can stop the test; and
• the post-pilot changes that must become part of the reusable migration pattern.

After the pilot, hold an operational readiness review. Confirm that alerts reach the right team, dashboards show application and infrastructure behavior, support staff can restore service, and the workload owner accepts the measured result. The pilot is complete when the process is repeatable, not when the target instance is reachable.

10. What should the post-migration AWS optimization backlog contain?

The post-migration backlog should turn measured operating gaps into owned work: cost allocation and rightsizing, security findings, reliability improvements, observability, data-transfer changes, automation, and application modernization. Compare each result with the pre-migration baseline; do not substitute a universal savings percentage for a measurement.

Use a 30/60/90-day operating review

First 30 days: reconcile inventory and tags, remove failed-test resources, review IAM and security findings, confirm backup and restore behavior, baseline CloudWatch metrics, and compare actual data transfer and support costs with the business case.

Days 31–60: review utilization and rightsizing recommendations, storage lifecycle, idle resources, NAT and inter-AZ traffic, Savings Plans or other commitments, alert quality, incident patterns, and unresolved migration exceptions. Commit only after the workload has a stable usage baseline.

Days 61–90: prioritize funded modernization work based on business value and measured constraints. That may mean changing a database tier, improving deployment automation, isolating a noisy neighbor, moving an event path, or redesigning an application component. It does not mean forcing every workload into containers, serverless, or a new AI service.

Keep the backlog tied to named owners and review dates. If the migration needs external delivery support, compare AWS migration consulting partners against the specific workstream—discovery, landing zone, database migration, modernization, or managed operations—rather than buying a generic “AWS migration” label.

The AWS migration is complete when the workload has a measured operating baseline, a maintained runbook, a clear ownership model, and a funded next step. The cutover is one decision in that operating record, not the end of it.