Lesson 327 · AWS Learning Path

AWS 327: Migration and modernization architecture

Anil Jalela · Published May 18, 2026 · 8 min read

Why this lesson matters

Migration moves a workload; modernization changes how it is built or operated. Combining both without control can multiply business, data, and rollback risk. A successful program connects portfolio evidence, landing-zone readiness, application strategy, dependencies, waves, cutover, validation, operating ownership, and decommissioning.

AWS tools accelerate discovery, replication, conversion, transfer, and code transformation, but they do not decide business priority, data ownership, acceptable downtime, rollback after writes, or whether users accept the result.

Learning outcomes

By the end, you can:

• distinguish migration, modernization, transformation, and optimization;
• classify portfolio components with the seven migration strategies;
• establish foundation and workload readiness gates;
• group dependency-safe waves and model constrained capacity;
• choose migration tools by source, target, data behavior, and downtime;
• design test, cutover, rollback, hypercare, and decommissioning;
• place modernization before, during, or after migration using evidence;
• produce a business and technical roadmap for 25 applications.

1. Program model

business case -> discover/assess -> mobilize foundation and teams
-> plan waves -> migrate/modernize -> validate -> operate -> decommission

These activities overlap. Portfolio information is progressively enriched; the wave plan changes as evidence improves. Keep one canonical record for application, owner, strategy, dependency, wave, risk, cost, readiness, and status.

2. Discover the portfolio

Inventory applications, servers, databases, files, interfaces, users, owners, environments, data classes, business criticality, incidents, lifecycle, contracts, cost, and technical debt. Combine interviews, CMDB, configuration, telemetry, flow data, authentication, batch schedules, DNS, certificates, and bills.

Label every item as observed, declared, inferred, or unknown. Discovery tools see only their installed scope and observation period. A quiet monthly dependency can be missed by a one-week capture. Include nontechnical dependencies such as vendor approval, fiscal close, staff availability, licensing, regulatory review, and business campaigns.

Create application groups from business transactions and tightly coupled dependencies, not only server names. Record dependency direction, protocol, data, rate, latency, maintenance window, owner, and consequence of failure.

3. Select strategy by component

Use the seven strategies deliberately:

• Retire: remove capability after user, data, legal, and dependency proof.
• Retain: leave in place for an explicit reason and review date.
• Rehost: move largely unchanged, often to EC2, to accelerate exit.
• Relocate: move compatible virtualized estates without redesign where supported.
• Repurchase: adopt a product/SaaS capability, including data and contract exit.
• Replatform: make bounded platform changes, such as managed database or containers.
• Refactor: change architecture/code/data to meet outcomes unavailable otherwise.

An application can mix strategies. Separate web, batch, database, reporting, and archive components. Do not call a change “replatform” if it requires major domain and data redesign.

Select using business value, source constraints, target requirements, migration deadline, dependency, data gravity, downtime, skills, licensing, cost, and risk. Record confidence and validation needed.

4. Landing-zone and foundation gates

No production wave should outrun its landing zone. Require:

• account/OU and cost ownership;
• federation, workload roles, emergency access, and secrets;
• IP plan, DNS, hybrid connectivity, egress, inspection, and endpoints;
• central logs, audit, Config/security coverage, and evidence retention;
• encryption/key ownership, backup, restore, and data residency;
• infrastructure delivery, artifact provenance, change and rollback controls;
• service quotas, capacity, support, monitoring, and incident escalation;
• target service patterns and exception process.

A green checklist is insufficient. Test connectivity, name resolution, time, identity, logging, backup restore, monitoring, deployment, and incident routes using representative nonproduction workloads.

5. Tool selection boundaries

Tools do not remove application-consistency needs. A three-tier workload may need database replication, server replication, file transfer, DNS/traffic change, identity update, and coordinated freeze. Define source-of-truth and target-write boundaries.

6. Wave planning

Waves are constrained scheduling units, not arbitrary batches. Consider dependency groups, business calendars, environment order, landing-zone capacity, migration-factory throughput, network bandwidth, replication quotas, test environments, approvers, vendors, support, and rollback windows.

Use pilots to test process with meaningful but controlled workloads. Avoid selecting only trivial applications, which proves little. Entry gates cover source readiness, target readiness, replication, runbook, test data, security, monitoring, business owner, rollback, communication, and support.

Track planned versus actual cycle time, defect escape, rollback, replication health, business acceptance, old-resource retirement, and realized benefit. Server count alone rewards movement without outcome.

7. Data migration and cutover

Choose offline copy, bulk plus delta, continuous replication, or application-level transition based on volume, change rate, downtime, consistency, and target behavior. Validate row/object/file counts, checksums where meaningful, constraints, referential integrity, business aggregates, security, and application journeys.

Define cutover states:

1. source remains authoritative while target is tested;
2. change freeze or final synchronization begins;
3. replication lag and validation meet gates;
4. traffic changes in controlled stages;
5. target writes are enabled;
6. business validation and observation complete;
7. migration is finalized only after rollback decisions are explicit.

Rollback before target writes is simpler. After target writes, rollback may require reverse replication, reconciliation, compensation, or forward repair. “Point DNS back” can lose accepted transactions.

8. Testing and operational acceptance

Test functional journeys, integration, performance, peak/burst, security, backup/restore, AZ/dependency failure, monitoring, deployment, batch, reconciliation, and DR. Compare target behavior with requirements, not source defects that should be removed.

Hypercare has start/end criteria, telemetry, staffing, escalation, known risks, daily decisions, and handoff. Operations must accept runbooks, dashboards, on-call ownership, patch/lifecycle, capacity, cost, and recovery evidence before the project team exits.

9. Modernization timing

Modernize before migration when the source cannot move safely or a bounded change unlocks migration. Modernize during migration when the replatform is limited, tested, and reduces material risk or effort. Modernize after migration when deadline, dependency, or change risk favors rehost first.

Avoid “temporary” rehost debt without a funded owner and date. Also avoid refactoring every workload while data centers close. Use business outcome and change capacity, not ideology.

AWS Transform can assist code and infrastructure transformation. Its output still requires repository authorization, human review, tests, secure credentials, license/dependency review, and controlled deployment. As of this review, AWS Transform CLI uses atx; current continuous-modernization guidance requires Node.js 22 or later and additional AWS permissions. Check current documentation before installation.

10. Read-only evidence

export AWS_DEFAULT_REGION="ap-south-1"
aws sts get-caller-identity --query Arn --output text
aws mgn describe-source-servers --output table
aws dms describe-replication-tasks --output table
aws datasync list-tasks --output table
atx --version

atx is separate from AWS CLI and is optional. Do not install it or authorize source repositories merely for this lesson. If an approved Linux lab permits installation, download the official installer to a temporary file, inspect it, verify current prerequisites, and use only an approved synthetic repository. Never upload proprietary code without authorization.

11. Failure diagnosis

12. Guided portfolio workshop

For a fictional 25-application company leaving a data center in 14 months, produce:

1. business case and success measures;
2. portfolio schema and confidence rules;
3. application/server/database/file inventory;
4. technical and organizational dependency map;
5. seven-strategy classification by component;
6. strategy confidence and experiment register;
7. target account/Region pattern;
8. landing-zone readiness gates;
9. migration-tool decision matrix;
10. network and data-transfer capacity model;
11. four dependency-safe waves and pilot rationale;
12. wave capacity and calendar plan;
13. database/data consistency strategy;
14. cutover and post-write rollback rules;
15. test and business-acceptance catalog;
16. hypercare and operating handoff;
17. modernization roadmap and team skill plan;
18. decommission, contract, and benefit-realization plan.

Cost and cleanup

This lesson creates no resources. Model discovery, replication staging, transfer, target coexistence, licenses, support, testing, modernization, training, and retained source cost. Savings are not realized until old infrastructure, contracts, and duplicate data are ended safely.

Knowledge check

1. Is migration success equal to servers launched? No; business acceptance, operations, and decommissioning are required.
2. Why group waves by dependencies? Coupled systems and business processes must transition coherently.
3. Why is post-write rollback difficult? New authoritative transactions must be reconciled or replicated back.
4. When should modernization follow migration? When deadline or combined-change risk outweighs immediate redesign value.
5. Does a migration tool decide business strategy? No; it implements bounded technical work.

Lesson acceptance

Submit all 18 artifacts. Strategies must be evidence-based by component; foundation and wave gates must be testable; data authority and rollback must cover target writes; operations and business owners must accept; and decommissioning must end source risk and cost.

Official sources

• AWS migration strategy
• Large migration phases
• AWS Transform documentation
• AWS Transform continuous modernization getting started
• AWS Application Migration Service
• AWS DMS