Capability · Cloud architecture & migration

Cloud architecture & migration

Q: 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.

Q: 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.

Secure, scalable cloud foundations — and safe ways to move onto them.

Review my migration sequence or view the fixed-scope entry

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 engagement

Start 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.

View scope: Migration Readiness Assessment

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