Cloud & Infrastructure

How to Plan Your Cloud Migration Step by Step

26 January 2026 · 0x1m3 · 7 min read

Cloud migration is not a technology project. It is a business transformation that happens to involve technology. The organisations that succeed plan thoroughly before they move a single workload. The ones that struggle start with servers and figure out the strategy later.

This guide walks through each stage of a cloud migration — from initial assessment to post-migration optimisation. It is built for South African IT directors and decision-makers who need a practical framework, not a vendor pitch.

---

<div style="text-align: center; margin: 32px 0;"> <svg width="24" height="24" viewBox="0 0 24 24" fill="#4A7AB5" xmlns="http://www.w3.org/2000/svg"> <path d="M9 2C8.45 2 8 2.45 8 3H5C3.9 3 3 3.9 3 5V20C3 21.1 3.9 22 5 22H19C20.1 22 21 21.1 21 20V5C21 3.9 20.1 3 19 3H16C16 2.45 15.55 2 15 2H9ZM9 4H15V5H9V4ZM7 8H17V10H7V8ZM7 12H17V14H7V12ZM7 16H14V18H7V16Z"/> </svg> </div>

Step 1: Assess What You Have

Before deciding what to move, you need a complete picture of your current environment. This means documenting every workload, dependency, and integration.

Build your inventory:

- List all servers (physical and virtual), their operating systems, and resource usage - Map application dependencies — which servers talk to which databases, APIs, and services - Identify data volumes and growth rates - Document current backup and disaster recovery arrangements - Record licensing — what you own, what you lease, and what expires when

Classify each workload:

- Ready to move — Standard workloads with no special hardware dependencies - Needs modification — Applications that require changes to run in cloud - Stay on-premises — Systems with hardware locks, extreme latency requirements, or regulatory constraints

Do not skip this step. Incomplete inventories cause migration delays, unexpected costs, and broken applications.

---

<div style="text-align: center; margin: 32px 0;"> <svg width="24" height="24" viewBox="0 0 24 24" fill="#4A7AB5" xmlns="http://www.w3.org/2000/svg"> <path d="M12 2C6.48 2 2 6.48 2 12C2 17.52 6.48 22 12 22C17.52 22 22 17.52 22 12C22 6.48 17.52 2 12 2ZM14.5 14.5L7 17L9.5 9.5L17 7L14.5 14.5ZM12 10.9C11.39 10.9 10.9 11.39 10.9 12C10.9 12.61 11.39 13.1 12 13.1C12.61 13.1 13.1 12.61 13.1 12C13.1 11.39 12.61 10.9 12 10.9Z"/> </svg> </div>

Step 2: Choose Your Migration Strategy

Not every workload should move the same way. The right approach depends on the application, its age, and your business goals.

Lift and shift (rehost) — Move the workload as-is to a cloud virtual machine. Fastest approach. Minimal risk. Best for standard Windows/Linux servers that need no changes. You gain cloud scalability but not full cloud optimisation.

Refactor (re-architect) — Modify the application to use cloud-native services. More effort upfront, but better long-term performance and cost efficiency. Example: moving a SQL Server database to Azure SQL Managed Instance.

Hybrid — Keep some workloads on-premises and move others to cloud. This is the most common approach for South African enterprises. Critical systems stay local while standard workloads move to Azure.

Replace — Retire the legacy application and adopt a SaaS alternative. Example: replacing an on-premises email server with Microsoft 365.

Most migrations use a combination of all four strategies.

---

<div style="text-align: center; margin: 32px 0;"> <svg width="24" height="24" viewBox="0 0 24 24" fill="#4A7AB5" xmlns="http://www.w3.org/2000/svg"> <path d="M12 2C6.48 2 2 6.48 2 12C2 17.52 6.48 22 12 22C17.52 22 22 17.52 22 12C22 6.48 17.52 2 12 2ZM11 19.93C7.05 19.44 4 16.08 4 12C4 11.38 4.08 10.79 4.21 10.21L9 15V16C9 17.1 9.9 18 11 18V19.93ZM17.9 17.39C17.64 16.58 16.9 16 16 16H15V13C15 12.45 14.55 12 14 12H8V10H10C10.55 10 11 9.55 11 9V7H13C14.1 7 15 6.1 15 5V4.59C17.93 5.77 20 8.65 20 12C20 14.08 19.2 15.97 17.9 17.39Z"/> </svg> </div>

Step 3: Plan for Azure South Africa Regions

Data residency is non-negotiable for many South African organisations. The Protection of Personal Information Act (POPIA) places strict requirements on where personal data is processed and stored.

Azure operates two regions in South Africa:

- South Africa North (Johannesburg) — Primary region with Availability Zones and the full range of Azure services - South Africa West (Cape Town) — Secondary region for disaster recovery and geo-redundant storage

Your region strategy should include:

- Primary workloads in South Africa North for low latency and full service availability - Disaster recovery replication to South Africa West for geographic separation - Geo-redundant storage (GRS) enabled for critical data - Clear documentation of which data stays in SA and which (if any) can go offshore

---

<div style="text-align: center; margin: 32px 0;"> <svg width="24" height="24" viewBox="0 0 24 24" fill="#4A7AB5" xmlns="http://www.w3.org/2000/svg"> <path d="M19 3H5C3.9 3 3 3.9 3 5V19C3 20.1 3.9 21 5 21H19C20.1 21 21 20.1 21 19V5C21 3.9 20.1 3 19 3ZM13.03 7.06L14.09 6L15.97 7.88L17.85 6L18.91 7.06L17.03 8.94L18.91 10.82L17.85 11.88L15.97 10L14.09 11.88L13.03 10.82L14.91 8.94L13.03 7.06ZM6.25 7.72H11.25V9.22H6.25V7.72ZM18 17.25H6V15.75H18V17.25ZM18 14.75H6V13.25H18V14.75Z"/> </svg> </div>

Step 4: Model Your Costs

Cloud pricing is consumption-based. This is an advantage — but only if you model it accurately before committing.

Key cost factors:

- Compute — VM sizes and running hours. Right-size from day one; do not replicate oversized on-premises specs - Storage — Tiered pricing. Hot storage for active data, cool/archive for infrequent access - Networking — Egress charges apply. Data leaving Azure costs money; data entering is free - Licensing — Azure Hybrid Benefit lets you reuse existing Windows Server and SQL Server licences - Reserved Instances — Commit to 1 or 3 years for 30–70% savings on always-on workloads

Common mistakes:

- Lifting on-premises VM sizes directly (most are oversized) - Forgetting egress costs for backup replication and user traffic - Not using reserved instances for predictable workloads - Running dev/test environments 24/7 when they only need business hours

Use the Azure Pricing Calculator for estimates, then add 15–20% contingency for the first six months.

---

<div style="text-align: center; margin: 32px 0;"> <svg width="24" height="24" viewBox="0 0 24 24" fill="#4A7AB5" xmlns="http://www.w3.org/2000/svg"> <path d="M12 1L3 5V11C3 16.55 6.84 21.74 12 23C17.16 21.74 21 16.55 21 11V5L12 1ZM12 11.99H19C18.47 16.11 15.72 19.78 12 20.93V12H5V6.3L12 3.19V11.99Z"/> </svg> </div>

Step 5: Address Security from Day One

Security is not a phase that comes after migration. It must be designed into your architecture from the start.

Essential security measures:

- Identity — Microsoft Entra ID with multi-factor authentication (MFA) for all users. No exceptions - Network — Network Security Groups (NSGs), Azure Firewall, and private endpoints for sensitive services - Data — Encryption at rest (enabled by default) and in transit. Azure Key Vault for secrets management - Monitoring — Microsoft Sentinel for security event monitoring. Microsoft Defender for Cloud for posture management - Backup — Azure Backup with immutable vaults to protect against ransomware - Access control — Role-Based Access Control (RBAC). Principle of least privilege. No shared admin accounts

Align your security design with the Protect, Detect, Recover methodology. Prevention matters, but so does your ability to detect threats and recover from incidents.

---

<div style="text-align: center; margin: 32px 0;"> <svg width="24" height="24" viewBox="0 0 24 24" fill="#4A7AB5" xmlns="http://www.w3.org/2000/svg"> <path d="M20 2H4C2.9 2 2 2.9 2 4V8C2 9.1 2.9 10 4 10H20C21.1 10 22 9.1 22 8V4C22 2.9 21.1 2 20 2ZM20 8H4V4H20V8ZM6 5H8V7H6V5ZM20 12H4C2.9 12 2 12.9 2 14V18C2 19.1 2.9 20 4 20H20C21.1 20 22 19.1 22 18V14C22 12.9 21.1 12 20 12ZM20 18H4V14H20V18ZM6 15H8V17H6V15Z"/> </svg> </div>

Step 6: Execute in Waves

Do not migrate everything at once. Group workloads into waves based on complexity and business impact.

Wave 1 — Low risk, high confidence. Dev/test environments, file shares, non-critical applications. Use this wave to validate your process and build team confidence.

Wave 2 — Standard business applications. Email (Microsoft 365), collaboration tools, standard line-of-business applications. These are well-understood workloads with known cloud equivalents.

Wave 3 — Critical systems. ERP, databases, customer-facing applications. These require the most planning, testing, and stakeholder communication.

For each wave:

- Migrate during a maintenance window - Validate every application against a pre-defined checklist - Confirm user access, performance, and integration points - Keep the rollback path available for at least two weeks

---

<div style="text-align: center; margin: 32px 0;"> <svg width="24" height="24" viewBox="0 0 24 24" fill="#4A7AB5" xmlns="http://www.w3.org/2000/svg"> <path d="M12 5V1L7 6L12 11V7C15.31 7 18 9.69 18 13C18 16.31 15.31 19 12 19C8.69 19 6 16.31 6 13H4C4 17.42 7.58 21 12 21C16.42 21 20 17.42 20 13C20 8.58 16.42 5 12 5Z"/> </svg> </div>

Step 7: Plan Your Rollback

Every migration needs an exit strategy. If something fails, you need a documented path back to the previous state.

Rollback essentials:

- Maintain on-premises infrastructure for at least 30 days after each wave completes - Keep current backups of all migrated workloads - Document the exact steps to revert each workload - Test the rollback procedure before you need it - Define clear triggers — what conditions warrant a rollback decision

A rollback plan you have never tested is not a plan. It is a hope.

OAS: Your Migration Partner

OAS has guided South African enterprises through cloud migrations since Azure's earliest days. With 40+ years of local IT experience and deep Microsoft partnership, we bring structure and certainty to what can feel like an overwhelming project.

We follow a proven methodology:

1. Discover — Full environment assessment and workload classification 2. Design — Architecture, cost model, and security framework 3. Migrate — Wave-based execution with validation at every stage 4. Optimise — Post-migration right-sizing, cost management, and ongoing support

Cloud migration done right starts with a plan. OAS has guided SA enterprises to Azure since day one.

Start Your Migration →