Moving on-premise servers to the cloud is no longer a question of “if” for most organisations, but “how” and “in what order”. A clear cloud migration roadmap is what separates a smooth, well-governed move from a stressful project that runs over budget and leaves you with the same problems in a more expensive location.
Whether you are running a few ageing servers in an office cupboard or a sizeable estate in a co-location facility, the principles are the same: understand what you have, decide the right path for each workload, build a secure foundation, move in controlled waves and keep optimising once you have landed.
This guide walks through that roadmap for Microsoft Azure and Amazon Web Services (AWS), the two platforms we work with most, with practical notes for South African businesses on load-shedding resilience, local regions and POPIA.
Why migrate, and when to think twice
The strongest reasons to move to the cloud are rarely about technology alone. Businesses typically migrate to:
- Reduce operational risk from ageing hardware, single points of failure and power interruptions.
- Avoid a capital hardware refresh and move to operating expenditure that scales with usage.
- Improve resilience with managed backups, multiple availability zones and tested disaster recovery.
- Move faster by provisioning environments in minutes and automating deployments.
- Unlock modern services such as managed databases, serverless functions, analytics and machine learning.
There are also good reasons to pause. Workloads with very steady, predictable usage on hardware that still has years of life can be cheaper to keep where they are for now. Software with restrictive licensing, or specialised hardware dependencies, may need a different solution. A good roadmap acknowledges that not everything has to move, and not everything has to move at once.
Stage 1: Discover and assess your current estate
You cannot plan a migration for systems you do not fully understand. The assessment stage builds an accurate inventory and dependency map.
Build the inventory
For every server and application, capture the operating system and version, CPU, memory and storage actually used (not just allocated), databases, scheduled jobs, licences, business owner, and how critical it is. Both platforms provide discovery tools to help: Azure Migrate and AWS Application Discovery Service can collect configuration and performance data from your environment over a period of time.
Map the dependencies
The most common cause of migration failures is a dependency nobody knew about: a report that reads directly from a database on another server, a file share mapped by a legacy script, or an application with an IP address hard-coded into its configuration. Collect network connection data, interview the people who run the systems, and group servers that must move together into “move groups”.
Classify by criticality and complexity
Score each application on business criticality and technical complexity. Low-criticality, low-complexity workloads make ideal first candidates because they let the team learn the process with little risk.
Stage 2: Choose a strategy for each workload with the 7 Rs
Not every application should be migrated the same way. AWS’s guidance describes seven common strategies, often called the 7 Rs, and Microsoft’s Cloud Adoption Framework uses very similar categories. Deciding the “R” for each workload is the heart of your plan.
| Strategy | What it means | Good fit when |
|---|---|---|
| Retire | Switch the application off | It is no longer used or its function is duplicated elsewhere |
| Retain | Leave it on-premise for now | Compliance, latency, licensing or recent hardware investment make moving premature |
| Rehost (“lift and shift”) | Move servers as-is to cloud virtual machines | You need to exit a data centre quickly with minimal change |
| Relocate | Move a virtualised platform wholesale, for example VMware workloads, to a cloud-hosted equivalent | You have a large virtualised estate and want minimal disruption |
| Replatform (“lift and reshape”) | Make targeted changes, such as moving a database to a managed service | You want quick wins in cost and maintenance without rewriting code |
| Repurchase | Replace with a SaaS product | The application is commodity functionality such as email or CRM |
| Refactor / re-architect | Redesign the application to be cloud-native | The application is strategic and needs scalability, agility or new capabilities |
A common and effective pattern is to rehost or replatform first to exit the data centre, then refactor the most important applications once they are running in the cloud. If you suspect an application’s code is holding you back, our guide on when to refactor legacy code will help you decide how far to go.
Stage 3: Build a realistic total cost of ownership
A credible business case compares the true cost of staying with the true cost of moving. On the on-premise side, include hardware refresh cycles, maintenance contracts, power and cooling, backup power for load-shedding, data-centre or rack costs, software licences, connectivity, and the staff time spent on patching and firefighting.
On the cloud side, use the official Azure and AWS pricing calculators with your measured utilisation data from the assessment, not the allocated sizes. Then add:
- Data transfer (egress) charges, which are easy to overlook.
- Backup, monitoring and security tooling.
- Connectivity, such as a site-to-site VPN or a dedicated private connection.
- One-off migration costs: assessment, tooling, testing, parallel running and training.
Then model the savings levers: right-sizing, auto-scaling, switching non-production environments off out of hours, reserved instances or savings plans for steady workloads, and licence portability options such as Azure Hybrid Benefit for eligible Windows Server and SQL Server licences.
Stage 4: Prepare a secure landing zone
A landing zone is the governed foundation that every migrated workload lands in. Building it first prevents the sprawl of inconsistent, insecure resources that often follows an unplanned migration. Microsoft provides Azure landing zone guidance as part of its Cloud Adoption Framework, while AWS offers AWS Control Tower to set up a multi-account environment with guardrails. A solid landing zone covers:
- Organisation structure: separate subscriptions or accounts for production, non-production and shared services.
- Identity and access: central identity (for example Microsoft Entra ID or AWS IAM Identity Center), multi-factor authentication and least-privilege roles.
- Networking: a hub-and-spoke or equivalent design, IP address planning that does not clash with on-premise ranges, and secure hybrid connectivity.
- Security and compliance: encryption by default, policy guardrails, centralised logging and threat detection.
- Cost management: tagging standards, budgets and alerts from day one.
Regions, data residency and POPIA
Microsoft operates Azure regions in Johannesburg and Cape Town, and AWS operates its Africa (Cape Town) region, so it is possible to keep data in South Africa. Check that every service you plan to use is available in your chosen region, because availability varies. If personal information will be processed outside South Africa, the cross-border transfer conditions in section 72 of the Protection of Personal Information Act apply. Document where data lives, who can access it and how it is protected; your information officer will thank you.
Stage 5: Migrate in waves and plan the cutover
Rather than moving everything over one weekend, group workloads into waves. Start with a pilot wave of low-risk applications, learn from it, refine your runbooks, then tackle progressively more critical systems. Tools such as Azure Migrate and AWS Application Migration Service replicate servers continuously, and both platforms offer database migration services that keep source and target in sync until you are ready to switch.
A cutover runbook that works
- Agree success criteria with business owners: what must work, and how you will verify it.
- Reduce DNS time-to-live values well before the cutover, so traffic can be redirected quickly.
- Run a full rehearsal in a test environment using replicated data.
- Freeze changes to the source system during the cutover window and communicate the plan to users.
- Complete the final data sync, switch traffic and run smoke tests against the agreed criteria.
- Keep a rollback path available, with a clear decision point and owner, until the new environment is proven.
- Provide hypercare: heightened monitoring and support for the first days after go-live.
Automating infrastructure with templates (such as Bicep, Terraform or AWS CloudFormation) and deployments with a CI/CD pipeline makes each wave repeatable. Our guide to CI/CD pipelines for small teams covers how to set that up.
Stage 6: Optimise, govern and modernise
Go-live is the beginning of your cloud journey, not the end. In the months after migration, review utilisation and right-size again, commit to reserved capacity for workloads that have stabilised, decommission the old hardware securely, and test your backup restores and disaster recovery plan. Then turn to modernisation: replatforming databases to managed services, containerising applications, or refactoring key systems to take advantage of serverless and event-driven designs.
Make cost and resilience someone’s job
Cloud spending is easy to start and easy to lose track of. Assign clear ownership for cost reviews, use the budgets and alerts you configured in the landing zone, and review the bill with application owners regularly so that unused resources are switched off promptly. Treat resilience the same way: decide on recovery time and recovery point objectives for each critical system, design backups and replication to meet them, and rehearse a restore at least once rather than assuming it will work. For South African businesses that previously relied on generators and UPS units to ride out load-shedding, a tested cloud recovery plan is often one of the most tangible benefits of the whole programme.
Your cloud migration roadmap at a glance
To summarise, a practical roadmap follows six stages, each with a clear output:
- Assess: inventory, dependency map and workload priorities.
- Decide: a migration strategy (one of the 7 Rs) for every application.
- Justify: a TCO comparison and business case based on measured data.
- Prepare: a secure, governed landing zone in your chosen region.
- Migrate: pilot and subsequent waves, each with a rehearsed cutover runbook.
- Optimise: continuous cost, security and performance improvement.
Precision matters most when the stakes are high. A migration executed with careful planning and attention to detail is one your users barely notice, which is exactly how it should be.
How Adriel Corp can help
Cloud migration is one of our core services, and we work across both Azure and AWS. Our Cloud Migration Readiness Package covers the critical early stages: assessing your servers and applications, recommending a strategy for each workload, estimating costs and designing the landing zone, so you can move forward with a plan you trust. When you are ready, we can carry out the migration and modernise your applications along the way.
