Cloud & integration3 min read
Cloud migration: five steps to get it right
A successful cloud migration owes less to technology than to method: know what you actually run, choose the right path for each application, migrate in waves, and put cost governance in place.
By ModalB
A cloud migration rarely fails for technical reasons. It fails because the existing estate is poorly understood, because the same path is applied to applications that have nothing in common, or because nobody watches the bill once the move is over.
Here is the method we apply, whatever the target platform.
1. Audit what you actually run
Before any migration project, you have to understand the real ecosystem — the one that is running, not the one that is documented.
What this phase produces:
- a complete inventory of infrastructure and applications;
- a map of dependencies between applications, including the flows everyone had forgotten;
- measurement of real performance and usage;
- an analysis of current running costs, which becomes the baseline;
- identification of regulatory and data residency constraints.
Expect two to four weeks depending on how complex the environment is. It is the most profitable phase of the project: it is what prevents nasty surprises in wave three.
2. Choose a path per application
There is no single migration strategy, there is one per application. The "6R" framework allows a quick decision:
| Path | What it means | When to choose it |
|---|---|---|
| Rehost | Move as-is | Deadline pressure, stable application |
| Replatform | Minor adaptations (managed database, object storage) | Good effort-to-benefit ratio |
| Refactor | Rewrite for the cloud | Strategic application expected to evolve |
| Repurchase | Replace with an off-the-shelf product | Non-differentiating function |
| Retain | Keep where it is | Regulatory or technical constraint |
| Retire | Decommission | Application nobody uses any more |
The pleasant surprise of a serious audit is how many applications turn out to belong under Retire.
3. Prepare the target platform
Before migrating anything, the landing platform has to be in place:
- network architecture and segmentation;
- identity and access management, with least privilege;
- backup strategy and disaster recovery plan, tested and not merely described;
- monitoring and observability;
- automation and infrastructure as code, so the environment is reproducible.
That last point conditions all the others: a platform built by hand will drift within six months.
4. Migrate in waves
A gradual approach limits risk and gives teams time to learn:
- Pilot wave: non-critical applications, to validate the approach and the tooling.
- Intermediate waves: business applications, in order of priority and dependency.
- Final wave: critical applications, with a rollback plan written down and rehearsed.
Each wave has to produce lessons that correct the next one. A migration that learns nothing from its pilot wave simply repeats its mistakes at a larger scale.
5. Optimise and govern
The migration does not end at cutover. Without governance, the cloud bill drifts every time.
On cost: real-time tracking, resizing of over-provisioned resources, commitments on stable capacity, automatic shutdown of non-production environments.
On operations: proactive monitoring, automation of recurring tasks, incident and change management, regular architecture reviews.
Three factors that make the difference
- Change management. Teams that used to operate servers do not spontaneously become cloud teams. Training is part of the project, not part of the aftermath.
- Security by design. Reworking a cloud architecture to add security afterwards costs far more than building it in from the start.
- Measurement. Cost before and after, availability, time to provide an environment: without those indicators, you cannot demonstrate the value created or decide what to do next.
- Cloud
- Azure
- AWS
- Migration