Cloud migration done right reduces infrastructure costs by 20–35%, improves agility, and enables capabilities — AI, analytics, global scale — that on-premises infrastructure cannot match. Done wrong, it creates security vulnerabilities, spiralling costs, and technical debt that can take years to unwind.

Having led cloud migrations at Bull SA and across ENGIE's Africa business unit — covering AWS, Azure, and GCP deployments — I have developed a methodology that consistently delivers successful outcomes. Here are the five steps.

"Cloud migration is not an IT project. It is a business transformation that happens to involve technology."
01

Assessment & Discovery

Before moving anything, you need a complete, accurate picture of what you have. This means a full application and infrastructure inventory — including shadow IT — mapped against business criticality, technical dependencies, and compliance requirements. At ENGIE Africa, we discovered 40% more applications than the official CMDB reflected. You cannot migrate what you do not know exists.

Key outputs: application portfolio map, dependency graph, compliance constraints register, and a preliminary business case.

02

Strategy & Design — The 6 R's

Not every workload belongs in the cloud, and not every cloud migration looks the same. The industry-standard "6 R's" framework provides a decision matrix for each application:

Rehost"Lift and shift" — move as-is. Fast, low risk, limited benefit.
ReplatformMinor optimisations during migration (e.g. managed DB).
RefactorRe-architect for cloud-native patterns. High effort, high reward.
RepurchaseReplace with a SaaS alternative (e.g. move CRM to Salesforce).
RetainKeep on-premises — regulatory, latency, or cost reasons.
RetireDecommission. Often 20–30% of portfolio in discovery audits.
03

Migration Execution — Wave Planning

Never migrate everything at once. Structure your migration in waves, starting with low-criticality, low-complexity workloads to build team confidence and test your tooling. Reserve your most complex, business-critical systems for later waves when your team has operational experience.

Each wave should include a rollback plan. The ability to reverse a migration quickly — within 4 hours — is a non-negotiable requirement in regulated industries.

04

Optimisation & FinOps

The most common post-migration surprise is cost. Cloud bills grow quickly when teams are not trained to use cloud resources efficiently. Implement FinOps practices from day one: tagging policies for cost attribution, reserved instance purchasing for stable workloads, rightsizing reviews quarterly, and automated shutdown of non-production environments outside business hours.

In the ENGIE Africa migration, FinOps practices reduced our monthly cloud spend by 28% within six months of go-live.

05

Continuous Governance & Security Posture

Cloud environments drift. Configurations change, new services are spun up, and access permissions accumulate over time. Implement a Cloud Security Posture Management (CSPM) tool, define a cloud governance framework, and establish a Cloud Centre of Excellence (CCoE) to set standards, review architecture decisions, and manage costs on an ongoing basis.

Migration is not complete when the last workload moves. It is complete when governance is operational and the team is self-sufficient.

Multi-Cloud vs Single Cloud

Most large enterprises end up with multi-cloud environments — often through acquisition, vendor diversity requirements, or specific service differentiation. AWS leads on breadth of services; Azure on Microsoft ecosystem integration; GCP on data and AI. Understanding your organisation's primary workloads and integration requirements should guide platform selection, not marketing relationships.

A Note on Regulated Industries

Energy, utilities, financial services, and healthcare face specific data residency, sovereignty, and audit requirements that affect cloud architecture choices. Sovereign cloud offerings from major providers — AWS GovCloud, Azure for Operators, Google Sovereign Cloud — exist for a reason. Map your regulatory obligations before selecting your cloud architecture, not after.