Cloud & Infrastructure

How to Plan Your Cloud Migration Step by Step

OAS Editorial Team26 January 20267 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.


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.


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.


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

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.


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.


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

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 →

Keep going

Related solution

Explore

Ready to strengthen your defences?

Book a no-obligation security assessment. We'll map your gaps across Protect, Detect and Recover — and show you exactly where you stand.