Skip to main content
Blog Cloud Migration

Moving from On-Premises to Azure or AWS: A Practical Checklist

A step-by-step checklist for moving your servers to Azure or AWS: what to list, what to move and how, the secure foundation, the real costs and cutting over in waves.

By Ajay Bhatnagar · · 5 min read

Key takeaways

  • Most cloud migrations that go wrong were rushed: servers copied across without a list of what depends on what, and costs nobody estimated.
  • Decide what happens to each workload before anything moves: move it as-is, improve it on the way, replace it, or switch it off.
  • Build the secure foundation first (access, network, backups, logging, budget alerts), then move workloads in small waves with a way back.
  • The cloud is not automatically cheaper. A right-sized setup with a cost estimate per workload is what keeps the monthly bill predictable.

Ageing servers, a hardware refresh coming up, a virtualisation licence that costs more every year, or a customer asking where their data is kept: these are the usual reasons a company starts thinking about moving to Azure or AWS.

The move itself is rarely the hard part. The hard part is everything before it: knowing exactly what you run, deciding what should move and how, and knowing what it will cost. This checklist walks through it in the order that works.

1. Know exactly what you run

You cannot plan a move for systems you have not listed. For every server and application, write down:

  • What it is and who uses it: the business owner, not just the IT owner.
  • What it depends on: databases, file shares, other applications, licences, and anything that connects to it from outside.
  • How big and how busy it is: CPU, memory and storage actually used, not just what was bought.
  • How important it is: how long the business can live without it, and how much data it could afford to lose.
  • Its condition: operating system and software versions, and anything already out of support.

Both providers offer free tools that scan your environment and help with this, but the business details (owners, importance, dependencies between teams) still come from conversations.

2. Decide what happens to each workload

Not everything should move the same way, and some things should not move at all.

Option What it means Good for
Move as-is Copy the server to a cloud virtual machine with few changes Stable systems you need to move quickly
Improve on the way Small changes, such as moving a database to a managed database service Systems where a little effort removes a lot of maintenance
Rebuild Redesign the application for the cloud Core systems with a long future and real growth
Replace Switch to a ready-made online service Email, file sharing, standard business software
Retire Switch it off Systems nobody really uses any more
Keep on-premises Leave it where it is, for now Systems tied to local equipment, or due for replacement soon

Retiring is the cheapest migration there is. Most inventories turn up at least a few servers that can simply be switched off.

3. Choose between Azure and AWS

Both are mature and both have data centre regions in India, so data can stay in the country when customers or regulation require it. The better choice depends on you:

  • What you already run. Companies built around Microsoft (Windows Server, SQL Server, Microsoft 365) often find Azure a natural fit, partly because existing Microsoft licences can often be reused there.
  • Your team's skills, and the skills of the partner who will support you.
  • The specific services you need, and their price for your workloads.

Compare the two on your actual workloads, not on general reputation.

4. Build the foundation before anything moves

Set these up first, so every workload lands somewhere secure and controlled:

  • Access control: named accounts, multi-factor sign-in, and least privilege. No shared administrator passwords.
  • Network design: how offices and users connect, and what is reachable from the internet (as little as possible).
  • Backups: automatic, kept separately, and tested with a real restore.
  • Logging and monitoring: who did what, and alerts when something fails.
  • Budget alerts and tags: every resource labelled by owner and project, with alerts before spending passes a limit.

If you are also preparing for ISO 27001 or an IT audit, this is the moment to design controls so the evidence is easy to show later.

5. Work out the real monthly cost

Estimate the cost per workload, using the sizes you measured in step 1, not the sizes of today's servers. Then check the costs that are easy to miss:

Often missed Why it matters
Data leaving the cloud Downloads, backups to another site and traffic to offices are charged
Storage and backup copies Snapshots and long backup retention add up month after month
Software licences Operating system and database licences may be included in the price, or need to be brought
Servers left running Test and development machines running nights and weekends
Oversized machines Copying an oversized server keeps paying for capacity you never use

For steady workloads that will run for years, both providers offer lower prices in return for a one- or three-year commitment. Decide on those after a few months of real usage, not before.

6. Move in small waves, with a way back

  1. Start with a pilot: one or two low-risk systems, to prove the process and the foundation.
  2. Group the rest into waves of systems that depend on each other, so they move together.
  3. Write a test plan for each wave, agreed with the business owners who will confirm it works.
  4. Write a rollback plan for each wave: how to switch back if something is not right, and who decides.
  5. Cut over outside business hours, at a time agreed in advance, with people available the next morning.

7. After the move

  • Watch closely for a few weeks: performance, errors and the first real bills.
  • Right-size: shrink machines that turned out to be oversized.
  • Switch off the old servers once you are sure, and end the contracts and licences behind them.
  • Update the documentation and runbooks so your team, or your support partner, can run the new setup.

The checklist in one place

  1. Inventory every server and application, with owners and dependencies.
  2. Decide for each one: move as-is, improve, rebuild, replace, retire or keep.
  3. Choose Azure or AWS based on your workloads, licences and skills.
  4. Build the foundation: access, network, backups, logging, budget alerts.
  5. Estimate the monthly cost per workload, including the easily missed items.
  6. Move in waves, starting with a pilot, each with a test and rollback plan.
  7. Monitor, right-size, retire the old servers and update the documentation.

If you would like help with steps 1 to 5, a cloud readiness assessment gives you the inventory, the plan and a cost estimate you can take to management. If security and audits are part of the reason for moving, see ISO 27001 and IT audit readiness, or browse all our Cloud & IT services.