Large migrations fail less often because a team cannot move a server and more often because the organization underestimates dependencies, ownership, sequencing, operating change, and the accumulated problems inside the source environment. A migration factory can move hundreds of workloads efficiently while still reproducing weak identity, brittle networking, oversized capacity, manual operations, and unsupported platforms in the cloud. Speed is useful only when the target state is intentional.
The SAP-C02 blueprint gives migration and modernization a major role because professional architects need to connect portfolio strategy with landing zones, networks, security, data movement, cutover, and later modernization. AWS Prescriptive Guidance still frames migration around assessment, mobilization, and migrate/modernize phases, with the familiar migration strategies such as rehost, relocate, replatform, repurchase, refactor, retain, and retire.
The most valuable design decision is often not “Which tool moves this workload?” but “What problem are we trying to solve by moving it, and which source problems must not survive the move?”
Portfolio discovery should identify dependencies before migration waves
An application inventory that lists server names is not enough. Migration planning needs business owner, technical owner, criticality, data stores, upstream and downstream integrations, authentication dependencies, network flows, maintenance windows, compliance requirements, licensing, and recovery expectations. Dependency discovery changes migration sequencing because tightly coupled systems often need to move together or maintain temporary connectivity across environments.
The practical output is a set of migration waves that minimize cross-environment dependency rather than simply grouping similar servers. A database and its application might move together even if they run on different platforms. A shared authentication service might remain on premises temporarily but needs tested hybrid connectivity for every dependent workload. Wave design is architecture work.
The landing zone should be production-ready before the migration factory accelerates
A migration program can move faster than the cloud foundation is ready to receive it. If accounts, network connectivity, DNS, logging, identity, security services, backup, tagging, cost controls, and deployment standards are still being invented during each wave, the result is inconsistency and rework. Mobilization exists to prevent this by building the operating foundation before large-scale movement.
The landing zone does not need to solve every future architecture question, but it should provide safe defaults. Account vending, hybrid connectivity, centralized evidence, base security controls, and workload onboarding need repeatable patterns. A migration wave should consume a platform, not create a new one.
The 7 Rs are portfolio decisions, not labels assigned by a tool
Rehost, replatform, refactor, relocate, repurchase, retain, and retire describe different transformations. The right choice depends on business deadlines, application health, technical debt, licensing, skills, compliance, and desired outcomes. A time-constrained data-center exit may favor rehost or relocate for many workloads. A platform approaching end of support may justify replatforming. An application with no business value may be retired rather than migrated.
AWS guidance for large migrations often recommends migrating first and modernizing afterward rather than combining deep refactoring with every move. That reduces the number of variables in each migration event. The exception is when the current platform makes migration unsafe or the business case depends on transformation. The strategy should be chosen intentionally, not because one team specializes in a favorite tool.
Migration waves need measurable entry and exit criteria
A wave should not begin simply because a date arrived. Entry criteria might include dependency validation, owner approval, target account readiness, network and DNS tests, backup status, runbook completion, cutover plan, rollback plan, and monitoring readiness. Exit criteria should include application validation, performance checks, security evidence, business-owner acceptance, source decommission decisions, and financial cleanup.
These criteria turn migration from an event into a controlled state transition. They also make factory metrics more useful. Counting servers migrated can reward speed while hiding failed acceptance, unresolved defects, or source resources left running. Measure completion by business-ready workloads, not infrastructure movement alone.
Rehosting is successful only if the operating model also moves
AWS Application Migration Service and related tools can reduce the mechanics of lift-and-shift, but moving compute does not automatically establish cloud-native operations. Monitoring, patching, backups, access, incident response, cost management, vulnerability management, and deployment still need owners in the target state. A migrated server without those controls is only a server in a different data center.
The existing article on enterprise migration with MGN is useful for the movement layer. At portfolio scale, architects need to place that movement inside a broader lifecycle so cutover is followed by stabilization and operations handoff rather than an immediate assumption that the migration is finished.
Data migration usually sets the real cutover window
Applications can often be replicated or redeployed ahead of time, but data consistency determines when users can switch. Database migration, file transfer, object synchronization, and streaming replication each have different change rates and validation needs. The cutover plan must define the final synchronization method, write freeze if required, validation, and rollback implications.
Large datasets also make bandwidth and time assumptions visible. A nominal network speed does not equal sustained transfer throughput. Compression, small files, latency, encryption, and source-system load can all affect the window. Teams should test representative transfers early rather than discovering throughput limits during the final migration weekend.
Security should improve during migration without becoming an unplanned blocker
Migration is an opportunity to remove shared accounts, tighten network exposure, centralize logging, and standardize encryption. It is also a dangerous time to introduce too many unrelated security changes into a cutover. A practical program distinguishes baseline controls that every target workload must meet from deeper improvements that can follow during modernization.
The security team should be embedded in wave planning rather than acting as a final gate. That allows issues such as unsupported encryption, identity integration, firewall dependencies, or logging gaps to be discovered before cutover. Security becomes part of the factory definition instead of an exception process.
Source decommission is part of migration economics and risk reduction
A workload is not truly migrated if the source remains running indefinitely “just in case.” Duplicate environments create cost, ambiguity, and security exposure. Users may continue hitting old endpoints, backup jobs may protect the wrong system, and teams may not know which copy is authoritative. Decommission planning should begin before the move and define retention, rollback periods, data destruction, license termination, and configuration archival.
This is also where the business case becomes real. Cloud cost comparisons that ignore the continued cost of source infrastructure can make a migration look disappointing. Retirement closes the financial and operational loop.
A migration factory should create a better platform, not a faster copy machine
Imagine an organization moving 600 applications before a lease expires. A weak factory optimizes server replication throughput. A stronger factory builds a repeatable landing zone, groups applications by dependency, assigns 7 R strategies, defines wave criteria, embeds security and operations, validates cutover, and schedules source retirement. Rehosted systems reach the cloud quickly, while modernization candidates enter a prioritized backlog based on business value and technical constraints.
The durable model is to separate movement from improvement without disconnecting them. Professional AWS architecture recognizes that migration is a portfolio transformation. The target environment should make future modernization easier and source-era problems more visible. Moving fast matters; knowing what not to carry with you matters more.
Migration planning should also distinguish technical dependencies from organizational dependencies. A workload may be technically ready to move while a vendor contract, support model, security approval, or business freeze makes the window impractical. Treating those constraints as late project-management details creates avoidable rescheduling. A good wave plan makes nontechnical blockers visible early enough that architects can choose another sequence instead of forcing a risky cutover.
After each wave, the factory should feed lessons back into the next one. New firewall requirements, DNS assumptions, monitoring gaps, cutover timing, or data-transfer behavior can be converted into updated templates and checklists. This continuous improvement is what separates a migration factory from a repetitive manual process. The organization should become better at moving workloads as the program progresses, not merely faster at repeating the first wave.
The factory should also preserve architecture decisions for workloads that are intentionally retained or retired. “Not migrated” is not the same as “forgotten.” Retained systems still need owners, connectivity, security, and an eventual review point; retired systems need confirmed data retention and decommission evidence. Portfolio discipline applies to every outcome, not only successful moves.
That discipline also prevents migration velocity from hiding unresolved business and operational debt.
