Modernization Patterns for Large AWS Migrations

Large cloud migrations fail when every application is treated as the same kind of move. A portfolio may contain simple virtual machines, commercial software, databases near end of support, tightly coupled legacy applications, systems that should be retired, and products that deserve a full redesign. Trying to force all of them through one migration pattern produces either unnecessary engineering or a large collection of cloud-hosted legacy problems.

AWS describes seven common migration strategies: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. The useful part of the model is not memorizing the list. It is recognizing that modernization is a portfolio decision. Some applications should move with minimal change, some should receive targeted platform improvements, and a smaller subset justify deeper redesign.

This article follows the architecture scope associated with SAP-C02, which AWS is replacing with SAP-C03 later in 2026. The migration patterns remain relevant because the hardest decisions in enterprise migration are about sequencing, dependencies, risk, and operating model rather than exam-version terminology.

Portfolio discovery comes before migration-wave planning

An organization cannot choose a migration strategy for an application it does not understand. Discovery should identify owners, servers, databases, interfaces, network dependencies, data sensitivity, licensing, business criticality, support status, recovery requirements, and usage. Configuration data can come from CMDBs, discovery tooling, interviews, logs, and application documentation, but each source has gaps.

Dependency information is especially important. A seemingly simple web application may call an on-premises authentication service, write to a shared database, depend on a file server, and exchange batch files with a mainframe. Migrating only the visible servers can create latency, reliability, or security problems that were not apparent during inventory.

Discovery should produce decisions, not an endless data-collection project. The team needs enough information to classify the application, estimate effort, identify blockers, and place it into a sensible wave. Unknowns should be explicit so they can be resolved before cutover.

Rehost and relocate are useful when speed matters more than immediate transformation

Rehosting moves applications with minimal architectural change, often preserving the existing operating system and application structure on cloud compute. Relocation can move supported virtualized workloads with even less change to the workload itself. These approaches are valuable when the main objective is to exit a data center, reduce infrastructure risk, or move a large number of applications under a tight schedule.

The criticism of “lift and shift” is that it can reproduce old inefficiencies in the cloud. That criticism is valid only when rehost is treated as the final architecture by default. In a large migration, moving first can reduce immediate infrastructure pressure and create a stable cloud baseline from which selected applications are modernized later.

AWS guidance for large migrations notes that rehost, replatform, relocate, and retire are common because full refactoring during a high-volume migration can be too complex. The architect’s job is to decide whether modernization must happen before the move, during the move, or after the portfolio has reached a safer operating environment.

Replatform when a managed service removes meaningful operational burden

Replatforming changes part of the application stack without redesigning the application completely. A database might move from a self-managed server to Amazon RDS. A web tier might adopt a managed load balancer and autoscaling. File storage may move to a managed service. Containers may replace some server management while leaving application logic largely intact.

The best replatforming candidates are changes that reduce undifferentiated operational work without creating a long development project. End-of-support databases and operating systems are common triggers because the organization must make a change anyway. Managed services can also improve backups, patching, high availability, monitoring, or scaling.

Replatforming still requires compatibility testing. A managed database is not identical to the same engine running on a virtual machine. Extension support, administrative access, backup behavior, performance characteristics, and licensing can differ. The migration team should evaluate the operational benefit against the application changes required to obtain it.

Refactor only where the business value justifies the engineering risk

Refactoring or re-architecting changes the application substantially to take advantage of cloud-native patterns, improve scalability, accelerate delivery, or remove technical constraints. This can include decomposing a monolith, moving to event-driven architecture, adopting serverless components, redesigning the data layer, or rebuilding deployment practices.

These changes can produce major benefits, but they also introduce software-delivery risk. Doing them simultaneously with data-center exit, network transformation, identity migration, and platform rollout can overload teams. Large programs should identify which applications truly need refactoring before migration and which can move first and modernize afterward.

The AWS Solutions Architect – Professional perspective is useful here because the decision depends on constraints. A customer-facing system that cannot scale may justify deeper redesign. A stable internal application with three years of remaining life may not.

Retire, retain, and repurchase are modernization decisions too

Cloud programs often focus on the applications that move, but some of the best outcomes come from applications that do not. Retiring unused systems removes cost, security exposure, and migration effort. Retaining an application on premises can be rational when dependencies, regulation, latency, hardware, or remaining life make migration unattractive. Repurchasing replaces the existing application with a SaaS or commercial alternative.

These strategies require business involvement because technical teams cannot decide whether a capability is still needed. Usage logs may show low activity, but an application owner may know that the system supports a critical annual process. Conversely, a department may discover that a legacy application survives only because nobody was willing to own the retirement decision.

Large migrations are a rare opportunity to challenge the portfolio. Moving an unused server to the cloud is not progress simply because the hosting location changed.

Migration waves should follow dependencies and operational readiness

Applications should be grouped into waves that make sense technically and organizationally. Shared dependencies often need to move together or in a controlled sequence. A low-risk wave can validate the landing zone, network, identity, security, backup, monitoring, and support processes before high-criticality applications follow.

Each wave needs entry criteria. The target account should exist. Connectivity and DNS should be ready. Required quotas should be approved. Security controls should be in place. Monitoring and backup should be tested. Application owners and support teams should know the cutover and rollback plan. A migration factory that measures only how many servers moved can miss whether the organization is actually ready to operate them.

Wave retrospectives should improve later migrations. Repeated issues with firewall approvals, database testing, or application-owner availability are signals that the process needs to change. Large migrations become efficient through learning and standardization, not through skipping checks.

Landing-zone and operating-model maturity determine how much modernization can stick

An application can be modernized technically and still land in an immature environment. If accounts are created manually, logging is inconsistent, IAM is unmanaged, network ownership is unclear, and deployment pipelines do not exist, teams may recreate manual operations around a cloud-native service.

A strong landing zone provides multi-account governance, identity integration, logging, security services, network patterns, and automation that workload teams can consume. Platform engineering then makes common capabilities available through repeatable templates. This is where migration and modernization reinforce each other: moving applications creates demand for a better platform, and a better platform makes modernization easier.

Operational ownership must also be explicit. Who patches what after migration? Who responds to alarms? Who owns database backups? Which team approves infrastructure changes? Cloud adoption changes responsibility boundaries, especially when managed services replace infrastructure tasks that used to belong to separate teams.

Modernization continues after cutover

The day an application moves to AWS should not be treated as the end of architecture work. Rehosted systems can be rightsized. Manual deployments can be automated. Databases can be evaluated for managed services. Observability can improve. Security groups and IAM permissions can be tightened after real traffic patterns are understood. Cost data can reveal where the original design needs adjustment.

For applications that move first and refactor later, a modernization backlog should be created before the migration team disbands. Otherwise, the promised second phase may never happen. Items should have owners, business value, dependencies, and realistic sequencing. Some applications will prove that further modernization is unnecessary; others will become clear priorities once infrastructure risk is removed.

The DOP-C02 domain becomes relevant when modernization shifts toward delivery automation, observability, infrastructure as code, and reliable operational change. Architecture and DevOps meet when the new platform must be operated repeatedly rather than demonstrated once.

A large migration is successful when the portfolio becomes easier to operate and change

The wider AWS ecosystem contains many services that can participate in a migration, but service selection is not the measure of success. A program should reduce infrastructure risk, improve operational clarity, create better security boundaries, retire unnecessary systems, and give teams a platform that supports future change.

The seven migration strategies provide a useful vocabulary because they force different applications to be treated differently. Rehost for speed where appropriate. Replatform where managed services remove meaningful burden. Refactor when the business case supports deeper change. Retire what no longer deserves investment. Retain what should stay. Repurchase when a product is better than a rebuild.

Modernization is therefore not a stage that begins after migration. It is the set of choices that determines how much change each application should absorb, when that change should occur, and whether the organization is prepared to operate the result. Large migrations succeed when those choices are made deliberately at portfolio scale.