What should a cloud migration checklist cover when you move to Azure?

A cloud migration checklist for Azure should cover why you are moving, what you have, where each workload and its data will live, how each one moves, what it will cost, who governs it, and how you test, cut over and roll back. Decide each item in writing before anything moves, then check it again after launch.

I have worked in IT and development since 1998 and hold Microsoft’s Azure Fundamentals certification, and Rizonetech is a Microsoft partner. This guide also uses lessons from moving our own website between data centres in October 2026, which was a website move, not an Azure one. Reviewed 12 October 2026 by Derick Payne, with the published facts read that day.

What is the eight-step cloud migration checklist for Azure?

Why are you moving?

“Move to the cloud” is not a reason. Write down the problem: ageing hardware, backups you do not trust, slow deployments, remote access that does not work, or costs nobody can explain. The reason decides the design. Copying an old server layout into Azure as it is keeps its problems, so compare today’s running cost with the proposed one before you decide.

Sometimes the honest answer is not to move. Our own Azure service copy says so plainly: Azure is “Sometimes, not always” cheaper, and “sometimes the honest answer is to stay”.

Where will your workloads and data live?

Microsoft opened its South African Azure regions, Johannesburg and Cape Town, on 6 March 2019. South Africa North is in Johannesburg and has availability zones. South Africa West, in Cape Town, is restricted: Microsoft limits access “to support specific customer scenarios, such as disaster recovery”.

Choosing a South African region does not settle where all your data goes. Backups, logs, monitoring and other services can sit elsewhere, so check each service’s data location. POPIA does not, on our reading, require storage in South Africa, but section 72 restricts sending personal information to a third party in another country unless the recipient is bound by “a law, binding corporate rules or binding agreement which provide an adequate level of protection”, the person consents, or another ground in the section applies. Document where the data goes and check the transfer with your legal or privacy adviser.

Whatever region you choose, Microsoft’s shared responsibility model leaves some things with you: “you always retain” responsibility for your data, endpoints, accounts and access management.

How should each workload move?

Decide one workload at a time. Microsoft’s Cloud Adoption Framework says each workload “can be Retired, Retained, Rehosted, Replatformed, Refactored, Rearchitected, Rebuilt, or Replaced”, chosen “based on its business driver”.

• Rehost moves a workload largely as it is, “like-for-like”. Check compatibility, dependencies, security and cost first. Microsoft warns against rehosting “problematic workloads” and suggests confirming the workload “will not require modernization within two years”.
• Replatform makes small changes to use a managed service, such as a managed database.
• Refactor, rearchitect or rebuild change the application, and suit workloads that justify the effort.
• Replace, retire or retain mean a product instead, switching it off, or leaving it where it is for now.

Whether to modernise during the move or after depends on the workload and on how ready your people are. Microsoft says to decide “based on clear business justification”, not by a blanket rule.

To build the inventory, Azure Migrate, a free Microsoft service, discovers your servers and maps the network connections it observes between them. It cannot see a monthly job that did not run while it watched, or an integration nobody used that week. So ask each application’s owner for its scheduled jobs and integrations, and watch across a full business cycle, such as a month end, before you call the inventory complete.

What did we learn moving our own site?

In October 2026 we moved rizonetech.com twice: from a Los Angeles data centre to Amsterdam, and then onto its own domain. Neither was an Azure move, but the checklist held:

• The reason was written down. We moved to Amsterdam for a stronger footing under POPIA section 72 and shorter round trips from South Africa.
• The inventory found more than we expected. 99 files in our repository named the old site address and 20 named its ID. We moved them all to one source, so the next move changes one file.
• Backups came first. We exported the database before cloning, and requested the host’s backups too.
• Checks were repeated, not assumed. After the copy, the page, post and attachment counts matched the source, and the forms, the sitemap and the page designs were tested again.
• The rollback window was shorter than planned. We planned to keep the old site for 30 days after the domain move. We deleted it after four days, before that window ended. Decide in writing who may end the rollback window, and when.
• DNS has its own clock. Resolvers can keep an old record for as long as its time to live (TTL). Our old name server records carry 48 hours, so switching on DNSSEC after our name server change waits until that has passed. Cloudflare’s documentation explains that a longer TTL “means that updates to your records take longer to go into effect”. Lower the TTL on the records you will change well before a cutover, where your DNS provider allows it, then wait out the old value; name server records are cached separately, often for longer, so plan for those on their own.

What will Azure cost, and how do you control it?

Estimate two costs separately. The cost of moving includes the work itself, running the old and new systems side by side while you test and keep a way back, data transfer charges at both ends, and switching the old system off. The cost of running depends on compute, storage, bandwidth, backup, databases, monitoring, licensing and support. Estimate both from real usage.

Which levers lower the running cost?

Look at each one separately:

• Reservations. You commit to one or three years for a specific resource, size and region. Microsoft says they can cut costs “by up to 72%” from pay-as-you-go prices, and its pricing page gives estimates “between 36% and 72%”, the top figure from a specific virtual machine in a US region over 36 months, based on January 2026 pricing. These are Microsoft’s illustrations, not expected savings for a South African workload. A reservation is “use-it-or-lose-it”: “You can’t carry forward unused reserved hours”, so base the estimate on the matching usage you expect every hour.
• Savings plans for compute. You commit to an hourly spend for one or three years, and it applies across eligible services and regions. Microsoft bills usage beyond the commitment at pay-as-you-go rates, and “Unused commitment for an hour expires and does not roll over”, so it suits steady usage. Microsoft gives estimates “between 11% and 65%”, again from a specific US example based on January 2026 pricing, and savings plan purchases “can’t be canceled or refunded”.
• Azure Hybrid Benefit. If you own Windows Server or SQL Server core licences with active Software Assurance or qualifying subscriptions, you can use them in Azure instead of paying for the licence again.
• Data leaving Azure. Inbound data transfer is free, Microsoft charges for outbound data after the first allowance, and rates depend on the billing zone of the source region. A busy integration or a backup target outside Azure can add up.
• Budgets and alerts. Budgets send alerts on actual or forecast cost, but “consumption isn’t stopped”, so someone has to act on them.

Right-size first, then commit. Our Azure service includes a monthly cost review that explains each charge.

What governance do you need from day one?

Before the first workload moves, confirm the target can run and recover it: the services and quotas you need exist in your region, network and DNS paths work, people and applications can sign in, administrators have only the access they need, budgets exist, and you have restored a backup. For larger estates, Azure provides more structure:

• Landing zones: an architecture you configure for your organisation, “for governing, securing, and scaling a multi-subscription Azure environment”.
• Management groups: a level above subscriptions, so the rules you set “cascade by inheritance”.
• Azure Policy: rules that “enforce organizational standards and to assess compliance at-scale”, such as allowed regions or required tags.

Put these in place before the estate grows. Retrofitting order later costs more. Our whitepaper on Azure migration and governance covers this in depth.

How do you cut over safely?

Rehearse on a copy, move in a planned window, and keep a way back. Our Azure service puts it this way: “Rehearsed on a copy, then made in a planned window, with a way back until you say go.” Before cutover, agree in writing:

• the order of moves, by dependency and risk;
• the test you will run on the copy, and what counts as a pass;
• how much downtime and data loss is acceptable, and how writes are paused or replicated during the move;
• the final synchronisation checks before the new system takes over;
• what triggers a rollback, and how data written after cutover is kept or reconciled if you roll back;
• how long the old system stays available for rollback, and who decides to end that;
• who gives the go, and who decides to roll back.

What should you check before approving an Azure move?

• The workload list, with a strategy and a reason for each.
• The migration sequence, the acceptable downtime and data loss, and the rollback plan, including how post-cutover data is handled.
• The readiness tests on the target: services, network, sign-in, access and a restored backup.
• Where each workload’s data, backups and logs will live.
• The cost of moving and of running, their assumptions, and which commitments you will make.
• Who supports and governs the environment after launch.

FAQ

Can our data stay in South Africa on Azure?

Many Azure services can run in South Africa North, but check each service’s data location, including backups and logs. POPIA does not itself require in-country storage, but transfers abroad need a valid basis under section 72.

Is rehosting the safest first step?

Not automatically. It changes the least, but it carries over existing problems. Check compatibility, dependencies, security and cost first.

Can you estimate Azure cost before migrating?

Yes, from real usage and stated assumptions, and it should be checked again after launch against actual bills.

Should everything move at once?

Usually not. Moving in phases, ordered by dependency and risk, keeps each step small enough to roll back.

What should you do next?

Find out where your systems stand with the free IT health check. To plan your own move with a clear order of work, read about planning a cloud migration with us. If the main workload is a custom application, read the Laravel development guide, because application design and Azure architecture should be planned together.

Published 16 June 2026. Last updated 12 October 2026.