Moving a legacy app safely comes down to six things done in order, with production left alone until the last one. This guide is for IT heads, app owners and architects at mid-size companies in India and the GCC. They have older, custom or tightly coupled software to move from their own servers to AWS or Azure. This guide sets out application migration to cloud as a method. Each step comes with the check to run and the tool that fits.
Last reviewed 2026-11-01 by Manish Sharma.
Application Migration to Cloud: The Short Answer
Work through six steps in order. Map the dependencies, choose a path for each app, plan the data path, cutover and rollback, prepare the target, migrate a pilot and then waves, and finally cut over and validate. Skipping a step in application migration to the cloud can move the problem to cutover day.
Key Takeaway The work that decides the outcome happens before anything moves.
Application Migration to Cloud, Step 1: Inventory and Map Dependencies
Start by writing down what you have and what each part depends on. An app can span several servers, and moving only part of it can break the rest.
Build the Application Inventory
List each app with its owner, environment, technology, support status and data size. Discovery tools help fill this in. They supplement conversations with the app owners and do not replace them, because a tool sees traffic and an owner knows why it exists.
Group Dependencies and Mark What Has to Stay
AWS Prescriptive Guidance separates soft dependencies, which do not depend on where components run, from hard ones. A hard dependency is an app server and a database that need low latency. Microsoft Learn adds direct, indirect and business dependencies. Business dependencies are organizational or management relationships, such as related workloads and reporting systems. AWS adds non-technical constraints, such as release schedules, maintenance windows and month-end processing, that can also fix a move date.
A dependency group is a set of components that must move together. Group by shared databases, APIs, authentication and network links, and keep components together when you are unsure. Filter shared services such as directory, backup and monitoring traffic out of the data, or everything looks connected to everything. For any component that will not move in this wave, write down the reason, how it connects to the rest and what data it shares.
Compare what the owner says the app talks to with what the network shows. The differences are your hidden dependencies.
Application Migration to Cloud, Step 2: Choose a Path for Each Application
Choose a path per app, not one for the whole portfolio. Assess each candidate on complexity, criticality, compliance needs and availability needs, then pick the path that fits.
People call the paths the Rs: rehost, replatform, refactor and the others. Rehost moves the app as it is, and refactor changes its design. A legacy app moved as it is carries its problems into the new environment, so the choice matters.
The choice between them is a decision of its own. Our post on legacy modernization covers rehost, replatform and refactor as strategies. This guide covers the method that follows once you have chosen.
Application Migration to Cloud, Step 3: Plan the Data Path, Cutover and Rollback
Decide how the data will move, how the switch will happen and how you will go back, before you copy anything. These three choices shape the risk of the move.
Choose the Data Path
Choose by data volume and sensitivity. A private link or a VPN suits secure transfers. An offline device suits large volumes. The internet suits data that is not sensitive. Microsoft Learn lists ExpressRoute, VPN, Data Box and the internet for Azure, and AWS offers equivalents.
Choose the Cutover Method
Cutover is the moment the live service switches to the new environment. A downtime cutover stops the service for a planned window, and it suits workloads that tolerate a planned outage. A near-zero-downtime cutover suits critical workloads. It needs continuous replication and enough bandwidth, so test it first. Choose per workload.
Write the Rollback Plan
A rollback is the plan for returning to the old environment if the move fails. Microsoft Learn’s guidance asks you to define what counts as a failed migration, to write the steps in order, to automate and test them, and to get stakeholder approval before cutover.
A rollback nobody has rehearsed is untested. Rehearse it in staging, and confirm you can back up and restore the data.
Key Takeaway Settle the data path, the cutover method and the rollback before the first byte moves.
Application Migration to Cloud, Step 4: Prepare the Target Environment
Build and test the destination before any production data moves. This is where compatibility problems surface cheaply in application migration to the cloud.
Landing Zone and Test Environment
A landing zone is the prepared foundation in the cloud, with accounts or subscriptions, networking, identity and security controls in place. Deploy the whole workload into a test environment and check that it is complete, so a missing component shows up now.
Fix Compatibility Issues
Fix problems in the target, not the source, so the original keeps running. Microsoft Learn’s guidance on preparing workloads names compatibility issues like these on Azure (as of November 2026):
| Issue | Fix | Why it matters |
|---|---|---|
| Hard-coded IP addresses | Use DNS names or app configuration | Dynamic addressing suits Azure networking |
| Host-based antivirus | Use Microsoft Defender for Cloud | Cloud-native security detects threats better |
| Hard-coded user accounts | Use managed identities | No credentials to manage |
| Unsupported OS versions | Upgrade to a supported version | Needed for security updates |
| Legacy network card drivers and BIOS | Update drivers and firmware | Supports network performance and security |
| Local file input and output | Use Azure Blob Storage or Azure Files | Scales better |
Test, Then Codify
Test connectivity, authentication, function and performance against a baseline you took before the move. Then capture the setup as infrastructure as code, meaning the environment is defined in files kept in version control. Test that code from scratch in a separate sandbox, so you know the environment can be rebuilt. Write the deployment and rollback documentation while the details are fresh, including rollback triggers and data backup and restore steps.
Application Migration to Cloud, Step 5: Pilot, Then Migrate in Waves
Start with something small and low-risk, then widen. A wave is a group of apps that move together.
Pilot With a Low-Risk Application
Choose a small, non-critical app, preferably in non-production. Include one or two representative complex workloads in early waves, so you learn what the hard ones need while the stakes are low. Critical systems follow after early success.
Size and Sequence the Waves
Keep early waves small, and plan waves ahead but be ready to revise them as discovery continues. Avoid release dates, month-end and quarter-end. AWS Prescriptive Guidance sets no predefined wave length and recommends keeping waves within 6 to 10 weeks (as of November 2026, from its wave planning page). Refine the cutover and rollback plans for each wave.
One dependency group or a small set of related groups.
Run it with the response team on call.
Check the result against the baseline from step 4.
Note what the wave taught you, then adjust the next one.
Application Migration to Cloud, Step 6: Cut Over, Validate and Optimize
Rehearse the cutover, then run it with a response team ready. Afterwards, prove that you lost nothing before you turn anything off.
Verify that the data is complete and intact. Benchmark performance against the baseline and confirm that security controls are in place. Keep the old system available as a fallback, as Microsoft Learn advises, until you have signed off the new one. Then monitor, and review what the app costs and how it performs in its new home. Our post on cloud optimization covers what comes after the move.
Keep the old environment for an agreed period after cutover, and name the person who decides when to switch it off.
Application Migration to Cloud Tools on AWS and Azure
Both providers offer tools for discovery, assessment and replication. They help with steps 1, 3 and 5, and they pay off only after the earlier steps are done.
| Tool | What it does | What it does not do |
|---|---|---|
| Azure Migrate | Discovery, readiness, right-sizing, dependency analysis, and migration of servers, databases, web apps and virtual desktops | Choose the path or explain a dependency |
| AWS Transform MGN | Continuous block-level replication, cutover windows AWS describes as typically minutes, and grouping of servers into apps and waves | Fix compatibility issues or plan the rollback |
Sources: Microsoft Learn and AWS documentation, as of November 2026. AWS lists Mumbai, Hyderabad, Bahrain and UAE among the Regions supported by AWS Transform MGN. Confirm Region support for Azure Migrate and any limits on the provider’s live pages before you choose.
Key Takeaway Tools carry out a plan. They do not make one, so finish the earlier steps first.
What This Article Does Not Cover, and When to Get Help
This guide gives the method. It does not list what can go wrong, give a full checklist or compare the migration strategies. Our post on legacy modernization covers the strategy choice.
Bring in outside help when no one in the company knows the app well, when data volumes are large, or when the timeline is tight. Get it early, because help brought in at cutover can only react.
For the wider picture, see how Signisys helps you migrate legacy applications to the cloud, and our page on cloud migration and modernization on AWS and Azure. See also cloud services and platform engineering.
References
- Microsoft Learn, Plan your migration, Cloud Adoption Framework.
- Microsoft Learn, Prepare workloads for cloud migration to Azure, Cloud Adoption Framework.
- AWS Prescriptive Guidance, Wave planning, application portfolio assessment guide.
Security Insights, Delivered.
Practical, vendor-neutral analysis of threats, tools, and architecture decisions.