Cloud strategy & migration
Moving an application is easy. Deciding which ones deserve to move, which ones must be rewritten first and which ones should simply be retired is the part that determines whether the bill goes down or up.
A migration is an arbitration, not a removal job.
Six migrations out of ten return less than expected, and the first reason is always the same: a monolith moved unchanged keeps its defects and pays for reserved capacity it used to get for free on already-amortised hardware.
We start from the inventory rather than from the target. Each workload gets its own strategy, retirement included, and each wave is followed for fourteen days after cutover. A migration that is not measured afterwards is a migration whose result nobody knows.
What we do
Four workstreams so what moves is decided by value rather than by ease.
Inventory and strategy per workload
Each workload is assigned its own path: rehost, replatform, refactor or retire, with the reason written next to it. Retiring is a strategy, and it is often the cheapest one.
the arbitration is negotiated on the file, not discovered during the window
- Stateful or stateless, and its dependencies
- A strategy per workload, with its reason
- What no longer has a use does not move
Landing zone
Network, availability zones, encryption, logging and mandatory tags are laid down before the first workload arrives. What is not written there becomes an exception someone has to defend.
residency and guardrails set at creation, not audited afterwards
- Guardrails refused at creation, not flagged later
- Mandatory tags: team, environment, workload
- Logging separated from the accounts it watches
Waves and cutover
A wave is prepared like an operation: change freeze, rehearsal in pre-production including one rehearsal of the fallback, then a progressive DNS switch with checks at every tier.
the fallback plan is written before the window, never during
- Change freeze and rehearsed rollback
- Progressive switch: 10%, 50%, 100%
- The old environment kept warm
Post-cutover measurement
Latency, errors and cost are compared for fourteen days against the previous situation, workload by workload. The old environment is only switched off after that period.
a workload that costs more after the move goes back to arbitration
- Latency and errors against the baseline
- Cost attached to the workload, not the account
- Switch-off only after the comparison
What you get
One project runs through the four deliverables below: the migration of a group's application base to managed Kubernetes, sixty-four workloads over nine months. Each line states what is actually handed over, in the order it is handed over.
The inventory, and one strategy per workload
The file that gets negotiated before anything moves: state, dependencies, chosen strategy and the reason for it. On this estate nine workloads leave the migration entirely, because they no longer have a use.
The landing zone, described as code
Regions, availability zones, private network, mandatory encryption, forbidden public storage and mandatory tags. A region outside the EU is refused at creation rather than reported in an audit three months later.
The wave and its fallback plan
Change freeze forty-eight hours ahead, cutover rehearsed twice in pre-production including once with the fallback, a progressive DNS switch, and a rollback trigger written as a threshold rather than as a judgement call.
The fourteen days that follow
Errors, latency and cost compared with the previous situation. This is where a workload moved unchanged shows what it really costs, while the old environment is still warm and the decision can still be reversed.
How we deliver
Inventory
depending on the number of workloads, dependencies and residency constraints
- Inventory and dependencies per workload
- One strategy per workload, retirement included
- Costed trajectory with hidden costs modelled
First wave
depending on the landing zone to lay down and the workloads selected
- Landing zone described as code
- Cutover rehearsed, fallback proven
- Fourteen days of comparison before switch-off
Following waves
depending on the workloads left and how coupled they are
- Following waves on the same template
- Workloads rewritten where moving is not enough
- Team upskilling
Operate
service commitment defined with you
- Cost attached to the workload and tracked
- Guardrails enforced at creation
- Reversibility proven, not declared
What migrations actually return
Migrations carried through
A digital factory rebuilt cloud-native on Azure
100% Terraform IaC · −24% cloud bill
A group of 7,000 people whose applications were deployed by hand, with environments that drifted from one another and a cloud bill nobody could attach to a team.
A cloud-native factory on managed Kubernetes, with the whole infrastructure described in Terraform and spread across three availability zones. Deployment time divided by six, and a bill that went down rather than up.
A deployment chain that replays itself, on Azure
230 industrialised pipelines · 0 critical vulnerability
Deployments and data flows handled without a shared chain: every change replayed by hand, and nothing guaranteeing that two environments behaved the same way.
A DevOps and DataOps chain built on Azure: environments described as code, pipelines industrialised, security checks wired into the chain rather than run at the end.
Insights & Perspectives
An introduction to container orchestration
An enterprise application can run thousands of containers that are impossible to manage by hand: what orchestration takes on, and what it does not solve.
Terraform partial backend configuration at scale
Separating what is static from what is dynamic removes duplication, keeps secrets out of the repository, and makes infrastructure automation hold across many environments.
Kubernetes in production: the 2026 guide
Resource limits, probes, rollout strategy and quotas: the practices that separate a cluster that holds from one that works until the first traffic peak.
Decide what moves before moving it
An inventory, one strategy per workload, a landing zone described as code, and a first wave measured for fourteen days.
Frequently asked questions
Because a monolith moved unchanged keeps every one of its defects and now pays for reserved capacity. Six out of ten return less than the expected ROI, mainly for that reason and because hidden costs, egress, licences, support, were never modelled.
The ones that gain something from moving: variable traffic, an isolated dependency chain, a technology already supported by the target. A workload with heavy state and a monolithic core gains little and pays the most, so it goes into a later wave or gets rewritten first.
It sets the ground before the first workload arrives: network, zones, encryption, logging and mandatory tags. Its value is that it refuses at creation rather than reporting afterwards, which is the difference between a guardrail and an audit finding.
By rehearsing the rollback before the window, not by writing it down. The switch is progressive, the old environment is kept warm, and the rollback trigger is a threshold, an error rate or a latency, rather than a judgement made at three in the morning.
After fourteen days of comparison, not on cutover day. Those two weeks are what reveal a workload that costs more than before, and they are only useful while the previous environment is still available to fall back on.
No, and forcing it usually costs more than it saves. The placement of a workload follows its constraints, residency, latency, existing licences, rather than a preference for a single provider. What must stay uniform is the deployment chain, not the destination.
Framing takes 2 to 6 weeks depending on the number of workloads, dependencies and residency constraints, and produces the inventory, one strategy per workload and a costed trajectory. The first wave lands in 4 to 10 weeks, landing zone included, and it is what tells you whether the rest of the plan holds.