An application migration changes the way a service is deployed, connected, protected, and operated. Moving its files or starting a new server is only part of that change. A dependable plan explains the business objective, identifies the systems that must move together, rehearses the transfer of data, and gives the team a clear decision at cutover. This guide follows those decisions from the first inventory to the work that remains after production traffic has moved.
Understand the service behind a cloud migration
The goal is a working, supported service in its new environment—not merely a completed transfer.
Cloud migration moves a workload and its operating responsibilities into a different environment. That workload may include application code, databases, scheduled jobs, network connections, identities, and supporting tools. Define the service boundary before deciding which servers or resources belong in the plan.
The change can be deliberately narrow or include selected modernization. Keep those scopes visible. Replacing hosting, changing a database engine, and redesigning an application create different kinds of uncertainty. A migration plan becomes easier to assess when it explains exactly which behavior must remain equivalent and which outcomes are meant to improve.
Establish a business reason for moving
Start with a problem that the move should help resolve: an infrastructure constraint, a support deadline, a recovery limitation, or an obstacle to delivery. Describe the present situation using evidence. Record current performance, availability expectations, operating effort, and relevant costs so the team can compare the result later.
A migration is harder to justify when success is defined only as using a new platform. Include the consequences of staying, moving now, or moving later. Where the objective depends on application changes rather than hosting alone, identify that additional work instead of assuming the destination will automatically deliver the benefit.
Create a strategy from the application inventory
A migration strategy should identify the service outcome, the dependencies that constrain it, and the evidence needed to proceed.
Build an inventory that includes ownership and dependencies, not just machine names. List applications, data stores, deployment mechanisms, certificates, external services, file exchanges, and recurring jobs. Compare the documented architecture with configurations and operational evidence; quiet monthly processes are easy to miss in interviews.
Group the findings into decisions: what moves, what remains, what can be retired, and what needs investigation. Assign owners to unresolved items. The resulting strategy should explain the desired service state, the constraints on change, and the evidence needed before committing to a migration wave.
Outcomes the move should change
Choose measurable outcomes such as a tested recovery path, simpler deployments, or removal of an infrastructure constraint. Agree the baseline and the person responsible for confirming each result.
The portfolio and its owners
Inventory workloads with a business owner and a technical contact. Include scheduled jobs and internal tools so an application’s apparent lack of daily traffic does not make it disappear from the plan.
Connections between applications and data
Trace database access, APIs, file exchanges, certificates, and network assumptions. Use configurations and operational evidence to check the diagram, especially where another team or provider owns part of the workflow.
Readiness and unresolved constraints
Identify unsupported runtimes, restrictive licenses, unusual hardware, and incomplete documentation. Assign an investigation or decision to each uncertainty instead of assuming that a destination platform will remove it.
Service and governance requirements
Record availability, recovery, performance, access, and data-handling expectations with the responsible owners. Translate them into evidence to collect during design, rehearsal, and cutover.
The destination and its operating model
Explain who will deploy, monitor, support, and pay for the new environment. Validate the people and procedures behind the architecture as well as the resources that will be provisioned.
Priorities and candidate waves
Group workloads around dependencies and a useful learning sequence. Keep the business reason for each priority visible so the plan can change coherently when a constraint or dependency is discovered.
Select an approach for each workload
Choose the amount of change that the workload needs; do not hide a redesign inside a move that was estimated as infrastructure work.
AWS describes seven migration strategies: retire, retain, rehost, relocate, repurchase, replatform, and refactor or re-architect. The useful question is which amount of change serves a particular workload. A portfolio can contain several approaches rather than forcing every application through one technical recipe.
Record the implications of each choice. A limited-change move can preserve existing weaknesses, while a redesign adds delivery and testing scope. If modernization is needed, decide which changes are essential before cutover and which can follow once the service is operating reliably in the destination environment.
A rehost with limited application changes
A rehost changes the hosting environment while limiting application changes. Verify the old deployment’s assumptions about identity, storage, networking, and recovery before treating the move as straightforward.
Selected platform changes during a replatform
A replatform changes chosen platform components. Define the behavior that must remain equivalent, then test operational differences such as backups, permissions, maintenance, and connection handling.
A deliberate application redesign
A refactor or re-architecture changes the application more substantially. Connect that scope to a business outcome and an explicit delivery plan rather than attaching an unbounded redesign to an infrastructure deadline.
Replacing a product rather than migrating it
A repurchase introduces replacement software. Assess data conversion, supported workflows, user transition, integrations, and exit arrangements; a subscription decision does not remove the work of changing the service.
Relocating an existing workload environment
A relocation moves an existing workload environment with limited redesign. Verify compatibility and the resulting operating responsibilities instead of assuming the management model remains identical.
Keeping a workload where it is
Retaining a workload can be a deliberate decision when its constraints or value do not support a move. Record the rationale, owner, support plan, and conditions for reviewing that decision.
Retiring an unnecessary application
Retirement needs an owner, a dependency check, and an agreed treatment of retained records. Confirm that a quiet application is genuinely unused before removing its infrastructure or access.
Choosing the amount of change
Compare the options against the workload’s objective and uncertainties. Use a targeted proof of concept where an important assumption cannot be established through documentation or operational evidence.
Organize assessment, preparation, and delivery
AWS separates large migrations into assess, mobilize, and migrate-and-modernize phases. The distinction keeps readiness work visible: the organization needs a business case, prepared teams, an operating model, and repeatable procedures before it attempts a large sequence of production moves.
Use phase outcomes as decision gates. During assessment, validate the objective and inventory. During preparation, establish environments, access, deployment, monitoring, and rehearsals. During delivery, apply the agreed runbooks to controlled waves and improve them with observed results. A calendar milestone alone should not stand in for readiness evidence.
1. Establish readiness and purpose
Confirm the business objective, decision-makers, and constraints. Record the evidence needed to proceed so assessment produces an accountable decision rather than an inventory with no agreed use.
2. Investigate workloads and dependencies
Examine actual configurations, integrations, data flows, and recurring operations. Resolve the differences between the documented architecture and the environment the team will really need to migrate.
3. Design the destination and wave plan
Define the target environment, access model, deployment, recovery, and operating roles. Sequence related workloads and document the entry and exit conditions for each migration wave.
4. Run a representative pilot
Choose a workload that tests important assumptions without taking on the greatest consequence first. Exercise deployment, migration, verification, and handover, then use observed results to revise the process.
5. Execute controlled waves
Apply the agreed runbook with named owners and recorded checkpoints. Keep dependencies and decisions visible so the team can distinguish a planned variation from a problem that requires escalation.
6. Verify and cut over production
Reconcile the data, test important workflows, and apply the agreed traffic change. Give a named decision-maker the evidence needed to continue, stop, or use a recovery option.
7. Stabilize and transfer ownership
Observe the service through its normal workload cycle. Close operational gaps, confirm recovery and support ownership, and track any improvements separately from the acceptance of the migration itself.
Plan how records move and remain consistent
Decide how initial data is copied, how subsequent changes are handled, and when each system may accept writes. Include schemas, encodings, time zones, identifiers, permissions, and application assumptions in the review. Define reconciliation checks that make sense for the business records, not only the size of a transfer.
For supported tasks, AWS DMS can compare source and target rows and report mismatches, including validation of ongoing changes. Its documentation also notes the additional resource and network usage involved. Treat validation as planned workload, and combine tool results with application-level checks before relying on the migrated data.
Database characteristics and application assumptions
Assess the amount of data, supported types, extensions, identifiers, time zones, and access patterns. Include applications and reports that read the database indirectly, not only its primary service.
A paused transfer or an ongoing migration
Choose the data movement approach around the service’s write behavior and acceptable interruption. Explain what remains available, how changes are captured, and which restrictions apply while environments overlap.
Replication and synchronization ownership
Define how changes reach the destination and how lag or a failed transfer is detected. Assign responsibility for resolving disagreements between systems before users depend on the copied records.
The final write and transfer window
Rehearse the last synchronization using representative volume and activity. Measure the time needed to stop or redirect writes, finish validation, and obtain the decision to open the destination.
Completeness and consistency checks
Compare relevant records and application outcomes, not only file sizes or transfer counts. Document exceptions and acceptable verification evidence so the release decision does not rely on an unexplained success indicator.
Restoration and data-aware rollback
Test recovery with the data the service will actually need. Explain how new destination writes affect a return to the original environment, including reconciliation and ownership of any unresolved differences.
Sequence migration waves around dependencies
A useful first wave reduces uncertainty for the next one, not just the number of workloads left on a spreadsheet.
A useful first wave is representative enough to test the process without exposing the most critical service to every unknown. Choose it deliberately. Include the application owner, operations team, and connected-service owners in the plan so the rehearsal tests coordination as well as infrastructure.
Move tightly coupled components together when separating them would create avoidable latency, access, or consistency problems. Record what each wave teaches the team and update later estimates. Give every wave entry criteria, a cutover owner, verification steps, and a clear definition of completion.
Workload groups that reflect real use
Group components by the business journey and the dependencies needed to support it. An infrastructure inventory alone may separate systems that must function together during a migration.
A pilot that teaches the right lessons
Low consequence is useful, but a trivial pilot may not test the eventual process. Choose representative integration, data, and operating characteristics so the result can improve later waves.
Components that should move together
Review tightly coupled applications and databases for latency, consistency, and access requirements. Document any temporary cross-environment connection and the conditions under which it can be removed.
Readiness and completion for each wave
Specify required test results, owners, support coverage, recovery options, and acceptance evidence. A wave is easier to control when the team can determine objectively whether it is ready to begin and complete.
Learning between waves
Record actual effort, transfer timing, failures, and handover issues. Revise the runbook and subsequent estimates so the program benefits from evidence rather than repeating an early assumption at a larger scale.
Verify the complete service in its new environment
Test the journeys that make the application useful, including integrations and scheduled activity. Compare response times and resource behavior with the baseline using representative traffic. Validate access, backup restoration, log delivery, and alerts before those capabilities are needed during a production incident.
Use a documented checklist so a successful test has an identifiable environment, dataset, version, and reviewer. Keep evidence of unexpected differences. A service that responds to a health endpoint can still fail a reporting job or lose access to an external system after cutover.
Application journeys and regressions
Exercise the important customer and staff tasks against the destination. Retain repeatable checks so a configuration or integration change does not silently break behavior that passed an earlier rehearsal.
APIs and external services
Test both successful and unsuccessful interactions with providers, internal APIs, and file exchanges. Confirm identifiers, permissions, certificates, and error handling using the actual target environment.
Records and application results
Reconcile the data and verify that the application interprets it correctly. A matching row count does not establish that dates, identifiers, calculations, or access restrictions retained their intended meaning.
Network paths and latency
Check the routes between users, components, and connected systems. Measure representative requests across those paths, including temporary connections to workloads that remain in another environment.
Traffic, capacity, and scaling behavior
Use realistic activity and data volumes to examine service behavior. Include the slow or periodic operations that a short health check does not exercise.
Identity and access boundaries
Verify the roles used by customers, staff, automation, and services. Check prohibited actions as well as permitted ones so the migration does not preserve or introduce unnecessarily broad access.
Backups and disaster recovery
Restore representative data and rehearse the operational steps required to use it. Record the result and ownership instead of treating the existence of a backup job as a completed recovery test.
Acceptance by the people who use the service
Give business and operational owners realistic workflows to review. Capture the remaining issues and the agreed acceptance decision so readiness is not inferred solely from infrastructure checks.
Define cutover and rollback before moving traffic
Write a timed runbook with named owners, dependencies, checks, and decision points. Describe how traffic changes, when writes pause or resume, and who authorizes the next step. Rehearse the process with realistic data so its duration is measured rather than assumed.
Explain the limits of rollback. Once the destination accepts new writes, returning traffic to the original environment may also require data reconciliation. Define how the team decides between reverting, repairing forward, or temporarily restricting a function. Those choices should be understood before an urgent production decision is required.
One coordinated switch or staged traffic
Choose the traffic transition according to application boundaries and data behavior. Explain the service restrictions, observation period, and recovery decision for each stage rather than selecting a pattern by name alone.
Parallel environments and blue-green patterns
Define which environment may write authoritative data and what a meaningful comparison can establish. Running two environments is useful only when the team understands how state and customer activity relate between them.
The last synchronization checkpoint
Assign the final data copy, reconciliation, and write-state checks to named owners. Record the evidence that authorizes a traffic change, and specify what happens if the expected state is not reached.
Routing, DNS, and cached connections
Plan how requests actually reach the destination, including long-lived sessions and connected clients. Test the transition path so a configuration change is not mistaken for every user immediately reaching the new system.
Recovery triggers and decision ownership
Agree observable stop conditions and who can act on them. Include customer impact and data consequences so the decision is more useful than an undefined instruction to roll back if something goes wrong.
Reducing the interruption window
Use rehearsal results to improve preparation and automate repeatable checks. Keep speed subordinate to the evidence needed to resume the service safely; skipping verification can move uncertainty into production.
Recognize the problems that derail migrations
A move can succeed technically while failing operationally if ownership, data, support, or recovery remain unresolved.
An incomplete dependency map can turn a successful infrastructure move into a broken business process. Other common planning weaknesses include unclear ownership, untested recovery, optimistic data-transfer assumptions, and adding a redesign without revisiting the schedule. Put those uncertainties in the plan where they can be resolved.
Watch for completion being defined too early. Traffic reaching the new system does not prove that backups, support, billing visibility, and old-resource retirement are ready. Keep these tasks assigned and tracked, so work does not disappear between the delivery team and the people who operate the service.
Unknown application dependencies
Investigate quiet integrations, scheduled jobs, and undocumented access before the move. An application can respond normally while an overlooked downstream process fails hours or days later.
One migration approach for every workload
Review each workload’s constraints and desired outcome. A limited-change move is not automatically suitable for software with unsupported dependencies, while a redesign is not automatically necessary for everything else.
An uncontrolled modernization project
Separate required migration changes from broader improvements. Revisit the scope and schedule when a redesign is introduced instead of expecting infrastructure milestones to absorb unrelated application development.
Data movement treated as a minor task
Test transfer duration, ongoing writes, validation, and recovery with representative records. Data work deserves its own plan when it determines whether the service can cut over or return to an earlier state.
Security reviewed only at the end
Bring access, network, secret, and data requirements into the target design. Late discovery of a required control can change deployment, operations, and the evidence needed to release.
Services the team cannot operate
Assess support skills, diagnostic tools, and incident responsibilities before selecting a platform component. A provisioning success does not establish that the operating team can recover or maintain it.
No baseline for judging performance
Record the existing workload and expected outcomes before moving. Without that context, a changed response time or resource bill is difficult to interpret and easier to misattribute.
Unrehearsed verification and recovery
Practice the runbook, restoration, and decision process before production cutover. A checklist that has never been followed can conceal missing permissions, tools, people, or data assumptions.
Costs without ownership
Assign cost visibility and review responsibilities to the service. Include overlapping environments and resources created during testing so the delivery estimate does not conceal continuing expenses.
Old resources left indefinitely
Track which workloads, records, and dependencies must remain and which can be retired. An old environment should have an explicit purpose and owner rather than surviving because nobody has accepted its removal.
Carry security and data responsibilities through the move
Review identities, network boundaries, service permissions, secrets, encryption, and audit records as part of the target design. Avoid copying broad access merely because it existed in the original environment. Decide how temporary migration credentials are issued, monitored, and removed.
Have the responsible specialists confirm requirements for data location, access, retention, and evidence. Record the resulting controls and owners. Continue that review through rehearsal and cutover, including temporary copies, export files, test datasets, and resources that would otherwise remain after the production service has moved.
Identities and least-required access
Review the permissions needed by users, staff, services, and automation. Avoid granting wide access simply to complete a migration task; define temporary permissions and remove them when their purpose ends.
Protection of stored and moving data
Map information flows across the original, migration, and destination environments. Have the security team define and verify the required protection for each flow, including exports, temporary copies, and backups.
Credentials, secrets, and keys
Inventory the credentials used by applications and migration tools. Define issuance, storage, rotation, and removal so a successful move does not leave unmanaged copies of powerful access material.
Network boundaries and service connections
Document the connections that the new environment requires. Verify both allowed and prohibited paths, including any temporary link to retained infrastructure or a migration workstation.
Events, monitoring, and an audit record
Confirm that important events reach the expected tools with usable identifiers and timestamps. Assign alert owners and review access to the logs so collected evidence can support an actual investigation.
Data obligations and location decisions
Ask the accountable specialists to review where production, test, operational, and support data will be processed. Turn their decisions into controls and evidence rather than inferring compliance from a selected cloud region.
A final security readiness review
Verify the agreed controls in the environment that will receive production activity. Resolve or explicitly accept outstanding issues through the responsible owners before the cutover decision.
Estimate migration effort and operating cost separately
Build the delivery estimate from discovery, environment preparation, integration changes, data movement, testing, cutover, and handover. Include work by application owners and partner teams, not just the migration engineers. Show which assumptions are validated and where a rehearsal may change the estimate.
Create a separate operating-cost model for the destination. Account for storage, compute, network use, backups, observability, licensing, and overlapping environments during transition. Review that model against real usage after the move. A lower server count is not by itself evidence of lower total operating cost.
Assessment and engineering effort
Estimate inventory, investigation, environment preparation, changes, and runbooks as visible work packages. Identify where a pilot or technical review can change the range before presenting a firm delivery commitment.
Resources and service charges
Model compute, storage, networking, backups, and observability against expected activity. State the assumptions and the person responsible for reviewing the model when real operating data becomes available.
Data transfer and database work
Include copying, synchronization, validation, and specialist involvement in the estimate. These activities can consume source, destination, and network capacity while the original service still needs to operate.
Overlapping environments
Plan the period in which old and new resources both remain available. Give each temporary environment a purpose, owner, and retirement condition so transition costs do not become indefinite.
Testing and assurance
Include representative test environments, security review, remediation, and operational rehearsal. Readiness evidence is part of delivery, not an optional expense to consider after implementation.
Internal capacity and outside support
State the roles and availability needed from application owners, operations, and specialist teams. An external migration partner does not remove the organization’s responsibility to make and accept service decisions.
The continuing operating model
Review the total cost of running, maintaining, supporting, and improving the service after the move. Compare that model with the original objective rather than treating a provider’s initial resource quote as the whole result.
Measure whether the migration achieved its purpose
Judge the migration against the baseline and business objective agreed before the move.
Use the objectives agreed at the beginning. Compare service behavior, recovery readiness, deployment effort, and operating cost with the recorded baseline. Include customer and support outcomes where relevant, such as fewer failed workflows or a simpler investigation process.
Give the service enough operating time to expose its normal workload cycle, including periodic jobs. Document benefits that are demonstrated, work that remains, and assumptions that proved incorrect. This produces a useful result even when some improvements require a later modernization project rather than the migration alone.
Availability and dependable workflows
Check whether the important journeys remain usable through the expected workload cycle. Track incidents and incomplete workflows in context instead of equating an available server with an available business service.
Response times and resource behavior
Compare representative tasks with the baseline, including background and periodic work. Examine the complete path through dependent systems when a response changes after migration.
Delivery and operational effort
Review whether releases, investigations, and routine maintenance are easier to complete. Use observed work and time rather than assuming that a newer platform automatically improves delivery practices.
Capacity and utilization
Compare allocated resources with real workload behavior. Look for persistent excess capacity or resource constraints, but keep recovery and peak-demand assumptions visible when considering an adjustment.
Infrastructure and operating expense
Review actual provider charges alongside licensing, support, and staff effort. Separate temporary transition costs from the continuing operating model so the result can be assessed fairly.
Incident response and recovery
Rehearse relevant recovery procedures and review actual incidents. Confirm that the people responsible can follow the runbook and reach the expected service state without the original migration team improvising each step.
Customer and business outcomes
Return to the reason for migrating and inspect the evidence for it. Document demonstrated benefits, unresolved problems, and improvements that still require application work rather than hosting changes alone.
Finish the handover and plan the next improvements
Confirm who owns alerts, access reviews, backups, deployments, capacity, and cost. Give the operating team a runbook it has practiced, and verify that someone outside the original migration group can follow it. Remove temporary access and retire old resources only after their dependencies and retention needs are resolved.
Then turn observations into a focused improvement backlog. Rightsizing, simplifying deployments, strengthening recovery, or replacing a fragile integration may be sensible next steps. Prioritize them against the original business objective instead of treating the new environment as a reason to redesign everything at once.
Adjusting resources to the observed workload
Use operating evidence to review compute and storage choices. Make changes deliberately, retaining the performance, recovery, and workload assumptions that explain why capacity was provisioned.
Introducing managed capabilities where useful
Assess autoscaling or managed services against a specific operational need. Test the changed behavior and support responsibility instead of adopting another platform component simply because it is available.
Improving observability
Review whether the current metrics, logs, and traces answer real support questions. Give important alerts an owner and a response path, and remove noise that obscures useful signals.
An accountable cost-review process
Make spending visible to the people responsible for the service. Review changes in usage and temporary resources regularly so operating decisions remain connected to the business objective.
Modernization after stabilization
Prioritize application improvements using measured limitations in the new environment. Keep the scope and acceptance criteria explicit so modernization becomes a reviewable project rather than unfinished migration work.
Closing the legacy environment
Confirm dependencies, access, record-retention decisions, and recovery needs before removing old resources. Record the acceptance and remove temporary credentials so decommissioning is a controlled conclusion to the migration.
FAQ
What determines the migration schedule?
The workload inventory, dependencies, data movement, verification, and readiness of the operating teams determine the work. Use assessment and rehearsal evidence to refine the schedule rather than applying one duration to every application.
Which workload is a useful first pilot?
Choose a workload with manageable consequences that still tests important characteristics of the later program. A low-risk but unrepresentative example may demonstrate provisioning without validating the eventual migration process.
Can a service remain available during a move?
The available transition options depend on the application, its data behavior, and connected services. Set an explicit service target, test the proposed design, and rehearse the cutover instead of assuming a tool guarantees uninterrupted operation.
Should modernization happen before cutover?
Separate changes required for a successful move from improvements that can follow. Additional redesign can be appropriate, but its scope and evidence should be explicit rather than silently added to a migration deadline.
Who needs to participate in the migration?
Include application and business owners, infrastructure and operations staff, data specialists, security reviewers, and the people responsible for important integrations. Name the cutover and acceptance decision-makers before rehearsal.
How can missing documentation be addressed?
Compare interviews and architecture diagrams with configurations, access records, network evidence, and observed operations. Give unknown dependencies an investigation owner and test the resulting assumptions in a representative pilot.
What belongs in a recovery plan?
Include stop conditions, decision owners, traffic changes, restoration steps, data reconciliation, and verification. Explain what a return to the original environment means once new activity has occurred in the destination.
When is retaining an application reasonable?
Retention can be deliberate when the workload’s constraints or value do not justify a move. Record the owner, rationale, continuing support arrangements, and conditions that would trigger another review.
