An app is ready to move when every check below has evidence behind it and a named person has signed. This guide is for IT heads, app owners and architects at mid-size companies in India and the GCC. They have an older, custom or tightly coupled app to move to AWS or Azure. It gives a cloud migration checklist of 26 checks in seven parts. For each check you get where to look on AWS and on Azure, the evidence to collect, the owner and the risk if it is skipped. Run it before anything moves, and treat a check without evidence as not done.
Last reviewed 2026-11-01 by Manish Sharma.
Cloud Migration Checklist for Legacy Applications: The Short Answer
Work through seven parts in order, from scope and ownership to cutover and acceptance. A checklist here is a readiness review, not a plan. You record what you find, name the owner and decide at a gate whether to proceed.
How to Use the 26 Checks
Use this cloud migration checklist with the app owner and the technical owner together. For every row, write down what you saw, the evidence (a report export, a screenshot, a signed test result) and the person who confirmed it. A check passes only with its evidence. Change nothing yet, because this pass is about learning what the move involves.
A check without a named owner and a piece of evidence counts as open. The gate at the end reads the evidence, so keep it where the approver can find it.
Cloud Migration Checklist, Part 1: Scope and Ownership
Three checks fix who owns the move and what counts as success. Without them, nobody can say later whether the move worked.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Owner | Risk if skipped |
|---|---|---|---|---|---|
| 1. Named business owner, technical owner and decision-makers | AWS Organizations account owners | Subscription and management group owners | One-page list of names and what each can approve | Program lead | No one can approve a stop or a rollback |
| 2. Success criteria and a performance baseline | Amazon CloudWatch, or your current monitoring tool | Azure Monitor, or your current monitoring tool | Baseline of CPU, memory, disk I/O, network, peak load and response times | App owner | No way to show whether the move helped |
| 3. A decision per app: move, retire or retain | App inventory sheet | App inventory sheet | A signed decision for each app | App owner | Apps that should be retired move anyway |
Take the baseline before anything changes. A baseline taken after the move measures the new environment against itself.
Choosing how to move an app is a separate decision from this cloud migration checklist. Our post on legacy modernization covers rehost, replatform and refactor. For the method of moving an app, see our step-by-step guide to application migration.
Cloud Migration Checklist, Part 2: Inventory and Support Status
Four checks establish what you run and whether the target supports it. Legacy software that the target does not support can block the move, not only the schedule.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Owner | Risk if skipped |
|---|---|---|---|---|---|
| 4. Inventory with owner, technology, environment, data size and support status | AWS Transform discovery and assessment | Azure Migrate discovery | Inventory export reviewed by the owner | App owner | Servers are left behind or moved blind |
| 5. Supported operating system, runtime and middleware versions on the target | Systems supported by AWS Transform MGN; EC2 documentation | Azure Migrate support matrix; Microsoft’s supported-software lists | Version list with end-of-support dates flagged | Architect | The target refuses or does not support the software |
| 6. License terms and vendor compatibility for the new environment | Vendor license terms | Vendor license terms | Written confirmation from each vendor | Procurement with the app owner | A license that forbids the new setup stops the move late |
| 7. Hardware ties, drivers, processor architecture and local storage | Instance types and storage options | VM sizes and disk options | Every hardware dependency, with its planned replacement | Infrastructure lead | Hardware-bound software fails to start |
AWS Application Discovery Service closed to new customers on 7 November 2025, so check 4 points to AWS Transform. Support lists also change, and vendors drop some older systems on set dates. As of November 2026, AWS Transform MGN’s documentation lists end-of-support dates for operating systems such as Windows Server 2008 (30 December 2026) and CentOS 7 (20 November 2026). Azure Migrate says results may be unreliable for Windows Server 2008, 2008 R2, 2012 and 2012 R2, and advises an upgrade first.
One unsupported library in an otherwise supported app can block the whole move. List every component and confirm its support status on the target.
Cloud Migration Checklist, Part 3: Dependencies
Four checks find what the app talks to. Undocumented dependencies can cause surprises at cutover, and our guide to cloud migration risks covers what goes wrong when they are missed.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Owner | Risk if skipped |
|---|---|---|---|---|---|
| 8. Internal dependencies found by tool and confirmed with owners | AWS Transform dependency mapping, agent-based and agentless | Azure Migrate dependency analysis | Dependency map signed off by each owner | App owner | A missing component breaks the app after cutover |
| 9. External dependencies: partner APIs, SaaS and on-premises systems | Network flow data; API gateway records | Network flow data; API records | Each external system, with its address and owner | Integration lead | Partner allow-lists or links stop working |
| 10. Hard-coded IP addresses, credentials, certificates, keys and scheduled jobs | Code, configuration and scheduler search | Code, configuration and scheduler search | Search results, each item with a fix | Developer or app owner | Fixed addresses and credentials fail in the new environment |
| 11. Databases: shared or split, with inbound and outbound flows | Database connection logs | Database connection logs | Database list with every connecting app | Database owner | Moving one database breaks others that share it |
Key Takeaway Discovery tools can miss undocumented dependencies, so interview the owners as well as reading the tool output.
Filter shared services such as directory, backup and monitoring out of the data, or everything looks connected. AWS Prescriptive Guidance separates soft dependencies, which do not depend on where components run, from hard ones, which do.
Cloud Migration Checklist, Part 4: Security, Compliance and the Target
Four checks confirm that the destination is ready and that rules allow the move. Do this part before you copy any data.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Owner | Risk if skipped |
|---|---|---|---|---|---|
| 12. Identity and access, including service accounts and hard-coded credentials | AWS IAM roles and policies | Microsoft Entra ID roles and managed identities | Account list mapped to target identities | Security lead | Service accounts fail, or broad access carries over |
| 13. Encryption and network rules mapped to the target | AWS KMS keys, security groups, network ACLs | Azure Key Vault, network security groups | Translated rule set, reviewed by security | Security lead | Data is exposed or blocked |
| 14. Regulatory requirements and data residency, confirmed with legal, compliance and security | Provider compliance documentation; AWS Region choices | Provider compliance documentation; Azure Region choices | Written confirmation of each requirement and where data may sit | Compliance lead | The move breaks a rule, found late |
| 15. Landing zone, quotas and connectivity ready | AWS Control Tower or an equivalent landing zone; service quotas | Azure landing zone; subscription quotas | Landing zone review and a connectivity test | Cloud platform lead | The destination lacks room for the workload |
A landing zone is the prepared foundation in the cloud, with accounts or subscriptions, networking, identity and security controls in place. Which data-residency rules apply to you depends on your sector and regulator, so take them from the regulator’s own guidance. This article states no country rule. Microsoft Learn notes that compliance requirements influence Region selection and architecture, and says to identify the applicable standards with legal, compliance and security stakeholders.
Cloud Migration Checklist, Part 5: Data and Rollback
Five checks cover how data moves and how you go back. This part decides whether a failed move is an incident or a pause.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Owner | Risk if skipped |
|---|---|---|---|---|---|
| 16. Data volume and transfer path chosen | AWS Direct Connect, VPN, DataSync or Data Transfer Terminal | ExpressRoute, VPN or Data Box | Volume, sensitivity and chosen path in writing | Data owner | Transfer runs too long or exposes data |
| 17. Backups proven restorable in isolation | AWS Backup restore test | Azure Backup restore test | Recorded restore of the full backup in isolation | Backup owner | Backups exist but do not restore |
| 18. Cutover method, and how writes are paused, synchronized and validated | AWS Transform MGN replication status | Azure Migrate replication status | Written cutover method with write-freeze steps | App owner | Data written during the switch is lost or duplicated |
| 19. Rollback plan with triggers, named decision-makers, steps and a deadline | Runbook and rehearsal records | Runbook and rehearsal records | Approved rollback plan with tested steps | Program lead | A failed move has no safe way back |
| 20. Recovery point and recovery time objectives agreed per workload and tested | AWS Backup and replication settings | Azure Backup and replication settings | Agreed RPO and RTO per workload, with a test result | App owner | Recovery targets are promised but unproven |
AWS Snowball Edge is closed to new customers, so check 16 lists DataSync and Data Transfer Terminal as the AWS options for online and physical transfer.
RPO is the amount of data, measured in time, that you can afford to lose. RTO is how long the service can be down. Microsoft Learn says to document RPOs and RTOs for each workload. AWS notes that, even following its best practices for active/passive recovery, recovery time and recovery point will be greater than zero. Agree both per workload and test them.
Azure Migrate does not support migrating VMs with encrypted disks or volumes, and BitLocker must be disabled before migration (Microsoft Learn, as of November 2026), so check encryption on the source as well as the target.
Once users write to the destination, a rollback needs a separate way to reconcile those new writes. Plan that path before cutover.
Cloud Migration Checklist, Part 6: Test and Rehearse
Three checks prove the app works in the destination before the real move.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Owner | Risk if skipped |
|---|---|---|---|---|---|
| 21. Complete test environment, with compatibility fixes made in the target | Test account with the full workload | Test subscription with the full workload | Deployment record and a list of fixes | Cloud platform lead | A missing component shows up on cutover day |
| 22. Functional, integration, performance and acceptance tests against the baseline | CloudWatch against the Part 1 baseline | Azure Monitor against the Part 1 baseline | Test report with results against the baseline | App owner | The new environment is slower or breaks a function |
| 23. A full rehearsal that becomes the runbook | Rehearsal record and runbook | Rehearsal record and runbook | Timed rehearsal, issues logged, runbook updated | Program lead | Steps are discovered live, under pressure |
Key Takeaway Fix compatibility problems in the target, not the source, so the original keeps running until acceptance.
Cloud Migration Checklist, Part 7: Cutover and Acceptance
Three checks cover the switch and the close. Keep the fallback open until acceptance.
| Check | Where to look on AWS | Where to look on Azure | Evidence | Owner | Risk if skipped |
|---|---|---|---|---|---|
| 24. Change freeze, writers stopped, final sync and DNS handled | Cutover runbook; Amazon Route 53 records | Cutover runbook; Azure DNS records | Signed runbook steps with times | Cutover lead | Data is lost or users reach the old system |
| 25. Post-cutover metrics against the baseline, with the fallback open | CloudWatch against the baseline | Azure Monitor against the baseline | Metrics report and a note on the fallback | App owner | A slow failure goes unseen until the fallback is gone |
| 26. Acceptance first, then decommissioning and removal of leftover access | Resource and access lists | Resource and access lists | Acceptance sign-off and a decommissioning record | Program lead | The source goes before the result is proven, or temporary access stays open |
After the move, review what the app costs and how it performs. Our post on cloud optimization covers what follows.
The Go/No-Go Gate
Proceed only with evidence for every part and a named approver. A verbal yes is not approval.
What the Gate Needs
Gather it across scope, target, data, recovery, people and time.
Choose one accountable person, not a committee.
Proceed, or stop and fix.
Note the date and the evidence it rested on.
What a Finding Record Holds
For each check, keep the check, the owner, the evidence, the decision and the date. Add a risk register entry for anything unresolved, with the mitigation, the owner and a date for resolution.
A gap with an owner and a date is manageable. A gap that everyone knows about and nobody owns is how a move stalls.
What This Checklist Does Not Cover, and When to Get Help
This cloud migration checklist is a readiness review. It does not give the method for the move, the full set of risks or the choice between migration strategies. Our post on legacy modernization covers the strategy choice. This article provides no template file, so if you were searching for a cloud migration plan template, use the evidence and finding record described above as your structure.
Bring in outside help when no one knows the app well, when data volumes are large, or when the timeline is tight. 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, Assess your workloads for cloud migration, Cloud Adoption Framework.
- Microsoft Learn, Plan your migration, 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.