A cloud migration checklist covers six areas: inventory your applications and data, choose a migration approach for each, design security and networking, plan costs and ownership, test thoroughly before cutover, and prepare a rollback. Working through these in order helps you move to AWS or Azure without surprise outages, hidden costs or lost data.
- Start with an honest inventory; most migration surprises come from systems nobody remembered.
- Not every application should move the same way: rehost some, rework others, retire a few.
- Plan security, access and costs before moving, not after.
- Rehearse the cutover and keep a tested rollback option.
Why do cloud migrations go wrong?
Most failed migrations are planning failures rather than technology failures. Teams discover late that an application depends on a file share nobody documented, that a licence does not allow cloud use, or that a nightly job talks to a system outside the migration scope. Each discovery delays the move and erodes trust.
Another common cause is treating migration as a one-time lift of everything. Businesses that move without deciding why, and what success looks like, often end up paying cloud prices for on-premise-style setups. A checklist forces the early questions that prevent expensive rework.
What should you do before moving anything?
Begin with discovery. List every application, server, database, scheduled task, integration and user group, and note who owns each one. Include shadow systems such as spreadsheets with macros that quietly run part of the business. Record dependencies between systems, since those decide what must move together.
Then define the goals. Is the aim lower hardware risk, easier scaling, better backup, or exiting a data centre by a fixed date? Clear goals shape every later choice, including which provider, which regions and how much to invest in redesigning applications.
- Inventory of applications, servers, databases and integrations.
- Named business and technical owner for each system.
- Dependency map showing what talks to what.
- Licence check for software that will run in the cloud.
- Written goals and a date or constraint driving the move.
How do you choose a migration approach for each system?
Common approaches range from rehosting, which is moving a server largely as it is, to replatforming with small improvements, to rebuilding the application for cloud-native services. A fourth option is replacing it with a software-as-a-service product, and a fifth is retiring it entirely if nobody needs it.
Match the approach to the value and condition of each system. A stable internal tool may simply be rehosted, while a customer-facing application with scaling problems may justify deeper rework. Be wary of rebuilding everything at once; sequencing in waves, starting with lower-risk systems, builds team skill before the critical moves.
What security and cost questions need answers first?
Decide how people and systems will authenticate, who may create resources, how networks are separated, how data is encrypted and where logs go. Setting these foundations up front is far easier than retrofitting them. Use multi-factor authentication for administrators and the principle of least privilege from day one.
On cost, estimate running charges using the provider's calculators, and plan how you will watch spending: budgets, alerts and resource tagging by project. Remember to include data transfer, backup storage and support. Check data residency and any regulatory duties that apply to your data, and confirm the current official rules where relevant.
How do you test and cut over safely?
Build and test the target environment before migrating live data. Run functional tests, performance checks and security scans, and ask real users to try critical workflows. Test the data migration itself on a copy, timing it so you know how long the final sync will take.
Plan the cutover for a quiet period, with a written sequence, named responsibilities and a clear go or no-go decision point. Keep the old environment intact until the new one has proved itself, so a rollback is possible. Communicate the plan to staff and customers who might notice a brief change.
- Rehearse the data migration and record how long it takes.
- Agree a go or no-go checkpoint with named decision makers.
- Keep the old system available for rollback until stable.
- Monitor closely for the first days after switching.
What happens after the move?
Migration is the start of operating in the cloud, not the end. Review costs weekly at first, since unused or oversized resources are easy to leave running. Right-size servers, schedule non-production environments to switch off out of hours, and consider reserved or committed capacity once usage is stable.
Update documentation, backup routines, monitoring and the disaster recovery plan to match the new setup. Then decommission old hardware responsibly, wiping data properly. Finally, hold a review to capture lessons learned so the next wave of migration is smoother.
Step by step
- Discover and inventory. List every application, dependency, owner and licence involved in the move.
- Set goals and approach. Decide the reason for moving and choose rehost, replatform, rebuild, replace or retire for each system.
- Design the foundation. Plan accounts, access control, networking, encryption, logging, budgets and monitoring.
- Migrate and test. Move in waves, starting with low-risk systems, and verify function, speed and security.
- Cut over with a rollback plan. Switch during a quiet window with named owners, keeping the old environment for fallback.
- Optimise after the move. Review costs, right-size resources and update backups and documentation.
Frequently asked questions
How long does a cloud migration take?
It depends on how many systems you have and how much rework they need. A small application may move in weeks, while a larger estate is usually migrated in waves over many months.
Will there be downtime during migration?
Often the downtime can be limited to a short cutover window, especially if data is synchronised in advance. Careful rehearsal helps keep it brief.
Should we move everything to the cloud?
Not necessarily. Some systems are better retired, replaced with a service, or kept on-premise for latency, licensing or regulatory reasons. A hybrid arrangement is common.
Is moving to the cloud always cheaper?
Not automatically. Savings depend on right-sizing, usage patterns and how well costs are managed. A move without cost controls can raise spend.
Who should own the migration?
Assign a business sponsor and a technical lead. Involve application owners, security and finance early, so decisions are not left to IT alone.
Need help with this? See our Cloud Services service or talk to Yash Parikh.