Cloud & Platform

Move what is worth moving. Switch the rest off.

The migration that fails is the one that moves everything. We start from a disposition per application — retire, retain, rehost, replatform, refactor or replace — and the programme finishes when the old environment is genuinely gone.

Disposition per applicationStaged cutover with rollbackDecommission in the planCost modelled before you commit
The problem

Two estates, two bills, and nobody willing to turn the old one off.

The most expensive outcome in cloud is not a failed migration. It is a half-finished one: the new platform is live, the old one still runs because four things were never moved, and you are now paying for both while every change has to be made twice.

No disposition decision

Everything is scheduled to move because deciding what to retire requires someone to own the decision and accept the consequence.

Lift and shift, then stop

Workloads arrive on virtual machines that look exactly like the old ones, so none of the promised operational benefit ever materialises — only the new bill does.

No cutover rehearsal

The migration weekend is the first time the runbook is executed end to end, and the rollback path exists only as a sentence in a slide.

What we do

A programme with a defined end.

Inventory & dependencies

What applications exist, what they talk to, who owns them and who actually uses them. Discovery tooling plus the interviews that find the systems the tooling misses.

Disposition per application

Retire, retain, rehost, replatform, refactor or replace — with a named owner and a reason for each. Retiring the unused ones is usually the largest single saving in the programme.

Target and cost model

The landing zone, the network and identity design, and a run-cost model at real volume before commitments are made rather than after.

Migration factory

A repeatable pattern per disposition type, so the twentieth application is routine instead of another bespoke project.

Cutover & rollback

Rehearsed cutovers, data synchronisation, a tested rollback path and an agreed definition of what would make us stop.

Decommission

Contracts, licences, hardware and DNS. The programme is not finished when the new thing works; it is finished when the old thing is off and the invoice has stopped.

How it runs

Assess, prove, industrialise, finish.

1

Assess

Four to six weeks for a mid-sized estate: inventory, dependencies, dispositions, target design and the cost model.

2

Pilot

Two or three representative applications end to end, including cutover and rollback, to prove the pattern and correct the estimate honestly.

3

Scale

Waves grouped by dependency, delivered against the patterns, with your teams progressively taking the work over.

4

Close

Decommission, contract termination, final cost reconciliation and a written record of what moved, what was retired and what it cost.

Modernisation, honestly

Not everything deserves a refactor.

Refactoring is the most expensive disposition and it is regularly applied to applications that will be replaced within three years. We would rather rehost those cheaply, refactor the two or three that carry real business logic and genuine load, and spend the saved budget where it changes something. That conversation belongs at the start, with the numbers on the table.

Straight answers

Questions we get asked

How long does a migration take?

For a mid-sized estate of thirty to eighty applications, typically nine to eighteen months including decommission. The assessment gives you a defensible number for your estate rather than an average, and it is deliberately the first thing we do.

Can you migrate without downtime?

For most applications, yes, with replication and a staged cutover. For some — particularly older databases with no replication path — a planned window is cheaper and safer than the engineering required to avoid one. We will tell you which case each application is in.

What if we discover mid-programme that something should not move?

Good. Dispositions are reviewed at each wave and changing one is a normal event, not a failure. The alternative is moving something everyone already knows is wrong because it is on the plan.

Do you handle the data centre exit and contracts?

We handle the technical decommission and produce the evidence your procurement and finance teams need to terminate contracts and dispose of hardware. The commercial termination itself stays with your organisation.

Will our team be able to run the new estate?

That is planned from the start. Your engineers work in the migration factory rather than watching it, and the last wave should be one they run with us available rather than leading.

Start here

One free hour. No pitch, no obligation.

Bring the problem you are stuck on — an integration that keeps breaking, a cloud bill nobody can explain, an AI project that is all demo and no product, or a platform you are about to invest in. You will leave with a straight answer and a written summary, whether or not you ever work with us.

  • Architecture and integration review
  • AI feasibility — what will actually work, and what will not
  • AWS, Azure and Google Cloud cost and design
  • Business process audit and ISO readiness
  • Technical due diligence before you invest or acquire