Capability · Cloud architecture & migration
Cloud architecture & migration
Secure, scalable cloud foundations — and safe ways to move onto them.
76
virtual machines migrated
~38 TB
of data transferred
29%
lower operating cost
<90 min
final cutover disruption
Measured on one engagement — anonymised client, verified with the owner.
Sound familiar?
Two or more of these means this page is for you.
- 1The dependency map lives in a few engineers' heads — nobody can say what breaks if one system moves
- 2A migration has been 'planned' for quarters, but nobody will commit to a cutover date
- 3Environments were built by hand and can't be reproduced, let alone moved
- 4The last platform change caused an outage, so every change since has been frozen
- 5You're paying for two estates — the old one you can't leave and the new one you can't finish
- 6Architecture decisions restart from a blank whiteboard because none were recorded
The transformation
How this discipline behaves when it's done right
- 1
Discovery & dependency mapping
Inventory workloads, data flows and integration points. The dependency map decides the wave plan — not the org chart.
- 2
Target architecture & decision records
Landing zone and target state on AWS, Azure or GCP, with decision records so the reasoning survives the project.
- 3
Wave planning & staged moves
Workloads grouped by dependency into reversible waves — each with validation criteria and a tested rollback.
- 4
Cutover & validation
Rehearsed cutovers in constrained windows, traffic shifted progressively, the way back proven before the way forward.
Decisions
The calls we make — and why
Rehost, re-platform or re-architect?
Per workload, not per estate. Most workloads rehost or re-platform; we re-architect only where the business case is explicit — a migration is not the moment to redesign everything.
One big cutover, or waves?
Waves, almost always. A single-event migration bets the platform on one night. Dependency-grouped waves keep the blast radius known and the rollback real.
Move first or optimise first?
Size before moving. Lift-and-shift of an oversized estate reproduces the waste at cloud billing rates — we right-size inside the wave plan, not after it.
Artifacts
What you hold at the end
- Map
Dependency map and workload inventory
- ADR
Target architecture with decision records
- Code
Terraform landing zone and environments
- Plan
Wave plan with validation criteria and rollback
- Runbook
Cutover runbook — rehearsed before the real night
Evidence
What it did on a real system
Situation
A long-established travel platform running live bookings from two data centres — where a single-event migration was too risky to attempt.
Intervention
A phased hybrid model: private connectivity, Terraform-built AWS infrastructure, dependency-grouped workload waves and modernised storage.
Measured result
76 VMs and ~38 TB migrated in staged waves; final cutover disruption under 90 minutes; operating cost 29% lower after the move.
Verified with the engagement owner · client anonymised by agreement.
Read the full engagementStart here
Most engagements start with a fixed-scope Migration Readiness Assessment; the wave plan it produces becomes the delivery backlog if we go on to execute together.
Delivery & ongoing
- Current-state assessment and dependency mapping
- Target-state architecture and decision records
- Landing zones across AWS, Azure and GCP
- Terraform infrastructure as code
Delivered as code with handover — or run ongoing as managed operations.
Before you engage
How long does a migration take?
The honest answer is the wave plan's answer — discovery sizes it. What we commit to early is the sequence and the rollback; the calendar follows the dependency map.
Can you migrate without downtime?
Near-zero for most workloads via progressive traffic shifting. Where a window is unavoidable we constrain it, rehearse it and prove the rollback first — the travel-platform cutover disrupted service for under 90 minutes.
Not in scope
- Application rewrites disguised as migration
- Big-bang cutovers without a rehearsal
- Moves we're asked to execute without discovery
How we think about this problem
All field notesCloud migration ROI: why optimisation debt compounds — and how to break the cycle
Lift-and-shift reproduces data-centre waste at cloud rates — the discipline to come out ahead.
18 min read
Cloud architectureAWS to GCP: what actually changes (and when not to move)
A re-platforming exercise with a service-mapping problem — including the case for staying.
20 min read
FinOpsCloud repatriation: when leaving the cloud actually pays
An engineering framework for whether leaving the cloud actually pays for your workload.
15 min read
Review your migration sequence
Bring the estate as it is — a rough inventory is enough. We'll map where the risk actually sits before anything moves.