Cloud
Move it without stopping the business.
Workloads, data and the dependencies nobody documented — taken across to public, private or hybrid cloud in waves, each one reversible. The hard part of a migration is never the copy. It is knowing what breaks when a thing moves, and in what order to find out.
- Readiness assessment
- Dependency mapping
- Rehost
- Replatform
- Refactor
- Parallel running
- Cutover & rollback
- Hypercare
What we hear
The reasons migrations stall.
We moved the easy things two years ago. What is left is what nobody wants to touch.
Head of Infrastructure
Nobody can tell me what talks to that database, so nobody will sign off moving it.
IT Director
The datacentre contract ends in eleven months and the plan is a spreadsheet.
CIO
Per workload
Six decisions, taken one application at a time.
A migration is not one choice. It is this choice, repeated for every workload — and getting the mix right is most of what decides the cost and the timeline.
Move it as it is
Lift and shift, where the application is healthy and the win is getting out of the datacentre. Fastest route, lowest risk, and the least long-term benefit — so we use it deliberately rather than by default.
Move it and change the foundation
Same application, managed database, managed runtime, autoscaling. Usually where the real return sits: most of the benefit of a rewrite, at a fraction of the cost and risk.
Rebuild the parts that have to change
Where the architecture is the constraint and no amount of moving fixes it. Scoped tightly, to the components that actually block you, rather than applied to a whole estate.
Replace it with something you buy
When a maintained product does the job better than the thing you have been carrying. We will say so, even though it is the option that bills us the least.
Switch it off
Most estates are carrying applications nobody has opened in a year. Finding them is part of the assessment, and every one retired is a workload you do not pay to move or to run.
Leave it where it is
Latency, licensing, data residency or a contract that has not run out. Some things should not move yet, and a plan that admits this is more credible than one that does not.
How it runs
Six phases, and nothing moves in phase one.
Every wave carries a rollback. If a cutover goes wrong at two in the morning, the decision is already written down and already rehearsed.
- 01
Discovery and strategy
Inventory, dependency mapping, readiness scoring per workload, and the security and compliance constraints that will shape the sequence. Ends with the six-way decision taken for every application.
Nothing has moved yet - 02
Proof of concept
One representative workload, taken all the way across. It validates the landing zone, the tooling and the cutover procedure — and it surfaces the surprises while they are still cheap.
- 03
Data migration
Replication set up and running ahead of cutover, with reconciliation that proves what arrived matches what left. Large datasets move first and catch up continuously, so the cutover window stays short.
- 04
Application migration
Workloads moved in waves grouped by dependency, not by team. Configuration externalised, secrets moved into a vault, and anything replatformed gets its new managed services wired and tested before the switch.
- 05
Cutover
Parallel running where the business can carry it, a rehearsed switch where it cannot. DNS, traffic and rollback plans written per wave and signed off before the window opens.
- 06
Run and optimise
Hypercare while the estate settles, then the work that only makes sense once real load is on it: right-sizing, commitments, storage tiering and the first honest view of the bill.
Where the savings actually land
Before anything moves
What the assessment has to establish.
A migration plan is only as good as the inventory under it. These are the things we will not start without.
- What you actually runA real inventory rather than the CMDB’s version of one, including the servers nobody owns and the jobs that run on somebody’s desktop.
- What talks to whatDependency mapping from live traffic, not from documentation. This is what decides the wave order, and it is where the expensive surprises hide.
- Data gravity and residencyVolume, change rate and where the data is legally allowed to sit — the three things that most often rule out the obvious plan.
- LicensingWhat follows you, what gets more expensive in cloud, and what is cheaper to repurchase than to carry.
- The cost of running bothEvery migration has a period where you pay for the old estate and the new one. Budgeting for it up front is the difference between a plan and a surprise.
- Who can approve a cutoverNamed people, per workload, agreed before the first wave — because the slowest part of most migrations is waiting for a decision.
Selected work
What changed, in the client’s terms.
Three recent engagements from this practice.
Core applications made portable
Core components were tied to the machines they ran on. Scaling meant provisioning, deployments were single events against single environments, and recovery from a bad one meant rebuilding by hand. Read the case study→ Aviation · On-premise to Azure
VMware to Azure, without stopping the airline
The estate was a set of interdependent applications on VMware, supporting operations that do not stop. The hard part was never the individual move; it was what breaks when systems that talk to each other sit on different sides of the migration for a period. Read the case study→A two-week paid pilot
Fixed price, on a real piece of your backlog. You keep the output whether or not you continue.