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:
- Discover — Full environment assessment and workload classification
- Design — Architecture, cost model, and security framework
- Migrate — Wave-based execution with validation at every stage
- 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.