I have worked in IT and development since 1998 and hold Microsoft’s Azure Fundamentals certification, and Rizonetech is a Microsoft partner. This paper also draws on moving our own website between data centres in October 2026, which was a website move, not an Azure one. Reviewed 13 October 2026 by Derick Payne, with the published facts read that day.
Why plan governance before the move?
A migration can go smoothly and still leave problems afterwards: rising costs, unclear access and workloads nobody owns. Some come from decisions nobody made before the move; others come later, when demand changes, people leave or agreed controls drift. So assign owners and controls before cutover, and keep reviewing them after. Microsoft’s Cloud Adoption Framework lists seven adoption phases, from strategy and planning through readiness, adoption, governance and security to ongoing management. In its words, the outcome “is an Azure landing zone and operational standards that support all Azure workloads”.
Azure does not make a badly run environment well run. It moves it, and makes it easy to create resources and easy to forget them. Write down the business reason for the move, such as ageing hardware, backups you do not trust or remote access that does not work, and check the plan against it.
Where should your workloads and data live?
Microsoft’s South Africa North region is in Johannesburg and has three availability zones. South Africa West, in Cape Town, is its paired region, and access to it is restricted “to support specific customer scenarios, such as disaster recovery within a specific geographic area”. Confirm access and service support before you choose it for disaster recovery.
A pair is not a recovery plan. Microsoft says deploying to a paired region “doesn’t automatically make them more resilient” and tells you to “develop your own high availability and disaster recovery plans”. Decide replication and recovery workload by workload, and do not assume a European region is an approved fallback without checking it against your contracts.
Choosing a region does not settle where all data goes. Microsoft’s data residency page says “certain Azure services do not enable the customer to specify the region”. It adds that Microsoft Entra ID “operates as a non-regional service” and may store directory data globally. POPIA section 72 restricts sending personal information to a third party in another country. A condition in the section must apply, such as the recipient being bound by “a law, binding corporate rules or binding agreement which provide an adequate level of protection”. Document where each service stores and sends data, and check transfers with your legal or privacy adviser.
Which migration method should you follow?
Microsoft’s migration strategies give each workload one of eight paths. Each “can be Retired, Retained, Rehosted, Replatformed, Refactored, Rearchitected, Rebuilt, or Replaced.” Rehosting moves a server as it is. Replatforming makes small changes, such as moving a database to a managed service. The deeper options change the application itself.
Microsoft does not say “rehost everything first”. It does say rehosting builds experience with “Azure operations, governance, and cost management”. It also says “Don’t rehost problematic workloads”. If a workload will likely need modernising within two years, it suggests you “consider refactoring or rearchitecting instead to avoid duplicate effort”. Choose per workload, and write down why.
Base those choices on evidence. Azure Migrate uses a lightweight appliance that “collects the configuration and performance data for your servers”, and its agentless dependency analysis captures the network connections between servers without installing agents. It only sees what runs while it watches, so ask each application’s owner about monthly jobs and integrations that may not have run yet.
What should a cloud migration rollback plan contain?
Microsoft’s migration planning guidance says: “Always establish rollback criteria and procedures before initiating any migration or deployment.” Its rollback section is written for deployments in general. Applied to a migration, a plan covers six things:
| Part | What to decide |
|---|---|
| Triggers | The measurable reasons to roll back, such as “failed health checks, poor performance, security issues, or unmet success metrics” |
| Decision | Who may call a rollback, and the go or no-go review points before and after cutover |
| The way back | How you return: the source still running, a restore from backup, or DNS pointed back, with the steps written down |
| Data | What happens to data written on the new system after cutover, and how it reaches the old one if you go back |
| Testing | A rollback tried before the real cutover; Microsoft says to test rollback and recovery “regularly” |
| The window | How long the old system stays available, who may end that window, and the final backup taken before it ends |
Then write the rollback as a runbook for each workload, with numbers your business can accept. Microsoft defines the recovery time objective (RTO) as “the maximum duration of acceptable downtime” and the recovery point objective (RPO) as “the maximum duration of acceptable data loss”. A runbook might read:
- Owner and deadline: who decides, and the latest time a rollback can still start within the RTO.
- Triggers in numbers: for example, error rates or response times past an agreed limit for an agreed period.
- Identify every system that writes data, stop new writes, and drain or preserve work already queued.
- Capture the data changed since cutover and check, before the old system reopens, that it reconciles within the RPO.
- Restore in the order your tested dependency map gives, infrastructure such as identity, networking and keys included, with integrations and scheduled jobs kept paused.
- Switch traffic back, such as DNS, and check the service. Restart integrations and scheduled jobs, and reopen to users, only after reconciliation and those checks pass.
- Record how long the rehearsal took, and whether it met the RTO and RPO.
Know when rollback stops being possible. Azure Migrate’s test migration “doesn’t affect the on-premises machine, which remains operational and continues replicating”. Microsoft calls it nondisruptive “as long as the test virtual network is sufficiently isolated”, so check that test copies cannot reach live databases, send email or run scheduled jobs against production. But once the final migration is done and the source is shut down, Microsoft says “you can’t perform a rollback from Azure to your on-premises environment”. After that point, the way back is the source you kept and your backups, not the migration tool. A surviving backup is not the same as a working rollback. Rollback stays viable while you have a tested way to restore, dependencies that still fit, data you can reconcile, and a restore that meets your RTO and RPO.
What did our own move teach us about rollback?
In October 2026 we moved rizonetech.com from Pressable’s Los Angeles data centre to Amsterdam, then moved the domain onto the new site on 7 October. Before the copy we exported the database and requested the host’s backups. After it, we checked the copy and re-tested every form and page before the domain moved.
Our rollback plan was to keep the old site, the one the domain had pointed to, untouched for 30 days, until 6 November. It ended after four days: the old site was deleted on 11 October, before a final backup was taken, and the host’s backups of the old site went with it. The new site was unaffected, but the rollback we had planned, the untouched old site, was gone. Two lessons follow. Take the final backup of the old system before anyone can delete it, and keep it somewhere the deletion cannot reach. And write down who may end the rollback window, and when.
How do landing zones, management groups and policy keep control?
Microsoft calls a landing zone “a proven and flexible architecture for governing, securing, and scaling a multi-subscription Azure environment”. In practice, it is identity, networking, security and policy, set up before workloads land.
Management groups sit above subscriptions, so “the governance conditions that you apply cascade by inheritance to all associated subscriptions”. They let you treat development, test and production, or separate business units, consistently without managing each subscription by hand.
Azure Policy automates selected checks. It can deny or audit a resource when it is created or changed. Fixing resources that already exist is separate: only policies with the deployIfNotExists or modify effects support it, through a remediation task whose managed identity needs the right permissions. The built-in Allowed locations policy restricts where resources are deployed. It “excludes resource groups” and “resources that use the ‘global’ region”, so it does not prove that all data stays in South Africa. Exemptions can waive a policy, and an expiry date is optional, so set one and review open exemptions. Keep change review for exceptions, business risk and anything the policies do not cover. Before you claim a control is enforced, check the assigned policies, the exemptions and the real data flows.
How should access work when several vendors share the estate?
Give each person and each vendor only the access their role needs, through Azure role-based access control. For administrator rights, Microsoft Entra Privileged Identity Management provides “just-in-time privileged access”. Activation length and approval are configured per role, and permanent active assignments remain possible. For routine administration, make people eligible for a role rather than permanently active in it, and review each role’s activation length and approval. Keep separate, monitored emergency access accounts, which Microsoft recommends so you are not locked out “because you can’t sign in or activate a role”. PIM needs Microsoft Entra ID P2 or Entra ID Governance licences.
When an outside provider manages your Azure resources, Azure Lighthouse lets you delegate chosen subscriptions or resource groups to that provider’s named users and roles. Microsoft says customers “can audit service provider actions and remove access completely at any time”.
Management groups, policies and access control help organise who can do what. They do not by themselves isolate one client’s data from another’s. If several clients or regulated workloads share infrastructure, decide whether each needs its own tenant, subscription, network or data store. Design that separation on purpose, and test it before anyone shares the estate.
How do you control the cost?
- Commitments. Microsoft says reservations can cut costs “by up to 72% from pay-as-you-go prices”, and the savings plan for compute advertises savings of up to 65%. Both are maximums for specific examples, not South African quotes: the 65% compares one Linux virtual machine in Microsoft’s East US region over three years, at January 2026 prices. A savings plan commits you to an hourly spend for one or three years; unused commitment for an hour does not roll over, and purchases “can’t be canceled or refunded”. Size any commitment against the usage you sustain, not your busiest month.
- Licences you own. Azure Hybrid Benefit lets qualifying Windows Server licences “with active Software Assurance or qualifying subscription licenses” run virtual machines “at a reduced cost”.
- Ownership. Tag resources to an owner or cost centre. Not all resource types support tags, so record the owner of the rest by resource group or subscription. Set budgets with alerts, and review the bill each month.
Data transfer has its own price list. Internet egress is free for the first 100 GB a month, then priced by billing zone, with the South African regions in Zone 2. Traffic between Azure regions is priced separately and does not share that allowance, so a chatty integration with another region or a backup copied abroad adds cost. Microsoft also offers free egress, on conditions, to customers moving all their data off Azure. Treat region and architecture choices as cost decisions too.
Who is responsible for POPIA compliance?
You are. Microsoft’s shared responsibility model says “you own your data and identities” whatever you deploy. Residency answers where data is stored; compliance is how you govern it: who can reach it, how long you keep it, how it is secured, and how you prove that. Policies that restrict regions, access control that limits who reaches data, and logs that record access are how the environment’s design supports that proof.
When several vendors handle personal information for you, POPIA makes you the responsible party and each of them an operator. Section 21 requires “a written contract between the responsible party and the operator” that ensures the operator keeps the security measures section 19 requires. It also says “the operator must notify the responsible party immediately” when there are reasonable grounds to believe personal information has been accessed or acquired by an unauthorised person. Put those contracts in place, and name one incident contact that every vendor knows to call.
What does the migration playbook look like?
| Step | Done when |
|---|---|
| 1. Discover and assess | Every workload is listed with its dependencies, owner and chosen strategy |
| 2. Build the landing zone | Identity, networking, policy, access and budgets are in place and tested |
| 3. Estimate the cost | The estimate rests on measured usage, with commitments and transfer costs modelled |
| 4. Write the rollback plan | Triggers, decision, way back, data, test and window are written and approved |
| 5. Migrate in waves | A test migration passed in an isolated network that could not touch production, the cutover ran in an agreed window, and the rollback was not needed or worked |
| 6. Operate and improve | Cost, access and policy reviews run monthly, and the old system is retired only after its final backup |
How do we approach this?
We treat a migration as a governance project that happens to move servers. The work starts with a readiness review: workloads, dependencies, risks, cost assumptions and the order of work, in plain language, before any quote for the move. The landing zone, access and guardrails go in before the estate grows. If a custom application is involved, its design and the Azure architecture are planned together; see our guide to custom Laravel development. If Microsoft identity and licensing are in scope, the Microsoft 365 guide covers the identity side Azure builds on.
FAQ
When does a migration rollback stop being possible?
When you can no longer restore the old system within your RTO and RPO: no tested restore path, dependencies that no longer fit, or data you cannot reconcile. A backup alone does not keep rollback open. With Azure Migrate, rollback through the tool itself ends when the source machine is shut down after the final migration. After that, you rely on the source you kept, your backups and a rehearsed restore.
Does choosing South Africa North keep all our data in South Africa?
Not on its own. Some Azure services are non-regional, and Microsoft Entra ID may store directory data globally. Check each service, and record where data is stored and sent.
Can several vendors safely work in one Azure estate?
Yes, with least-privilege roles, just-in-time administrator access and delegated access you can audit and remove. Separate clients’ data by design, not by policy alone, and test the separation.
What should you do next?
See where your systems stand with the free IT health check. If you are still deciding whether to move, read cloud vs on-premises costs; for the step-by-step move, read the shorter Azure migration checklist. When you are ready, see Azure migration and governance; we will tell you plainly if the move is not worth it.
Published 16 June 2026. Last updated 13 October 2026.