Migrate to Cloud

Move to the cloud without moving the risk with you.

Talk to us
Runs against
One workload at a time
The rule
Nothing moves before there is a way back
You get
A workload register and a repeatable cutover

Lifting everything moves the problems too

The default migration is to rehost everything and decide what to fix later. It is the fastest plan to write and the slowest to finish, because it carries the old estate’s coupling, its undocumented dependencies and its operational habits across intact, and then asks a team to unpick them in an environment they have not learned yet.

The other common ending is quieter: both estates are still running a year later, because nothing was ever decommissioned. The saving that justified the project never arrives, and nobody can point at the moment it was lost.

So we migrate workload by workload, with a decision recorded for each one, a cutover rehearsed before it happens, and a rollback that stays available until the workload has proved itself in its new home.

A disposition per workload, then a rehearsed cutover Each workload is given one of four dispositions: rehost, meaning lift it as it is; replatform, meaning change the runtime; rewrite, meaning change the design; or retire, meaning it does not move at all. The workload then follows a sequence: rehearse, cut over, a period during which rollback is still available, and finally decommission of the old estate. The migration is not finished until that last step. The star marks the cutover: a repeatable one, which you keep. One disposition per workload Rehost Replatform Rewrite Retire Rehearse Cut over Rollback available Decommission The old estate going away is the finish line. lift it as it is change the runtime change the design it does not move then, for each one that moves A disposition per workload, then a rehearsed cutover Each workload is given one of four dispositions: rehost, meaning lift it as it is; replatform, meaning change the runtime; rewrite, meaning change the design; or retire, meaning it does not move at all. The workload then follows a sequence: rehearse, cut over, a period during which rollback is still available, and finally decommission of the old estate. The migration is not finished until that last step. The star marks the cutover: a repeatable one, which you keep. One disposition per workload Rehost Replatform Rewrite Retire Rehearse Cut over Rollback available Decommission The old estate going away is the finish line. lift it as it is change the runtime change the design it does not move then, for each one that moves
Retire is a disposition, not a failure to plan. The cheapest workload to migrate is the one nobody needed, and every register has some.

What the work covers

  • Inventory and dependency map What talks to what, what nobody owns, and what is running that no one remembered was running.
  • A disposition per workload Rehost, replatform, rewrite or retire, decided per workload and written down, because the default of rehosting everything carries the old problems across intact.
  • Data first Volume, change rate, residency and the mechanism that moves it. Data decides the cutover window; everything else follows it.
  • A landing zone before anything moves Accounts and projects, network, identity, policy, monitoring and cost attribution across GCP, AWS or Azure, with Kubernetes for the workloads that warrant it.
  • A rehearsed cutover Run on the real workload, with the rollback path live and timed, so the window is a measurement rather than a hope.
  • Decommission A migration that leaves both estates running has not finished, and that is the most common way the saving disappears.

How the engagement runs

Four stages, each ending in something you keep. No weeks are attached: the length is the number of waves, and the wave count is something stage one produces rather than something anyone can promise before it.

  1. Stage 1 Inventory and disposition Every workload found, its dependencies mapped, a disposition decided for each, and an order set. Multi-region and geo-redundancy decided here too — where they are genuinely required, rather than wherever they are available. You get: a workload register with a disposition, an owner and a position in the order.
  2. Stage 2 Landing zone The target built and governed before anything arrives in it: accounts, network, identity, policy, monitoring and cost attribution. You get: a landing zone that is ready, and described in code.
  3. Stage 3 First wave The least critical workload that still has a real dependency — because one with no dependencies teaches you nothing. The output of this stage is the pattern, not the workload. You get: one workload migrated, and the runbook the rest will follow.
  4. Stage 4 Waves and decommission The pattern repeated, the old estate retired as each wave proves itself, and operations handed to your team or to Cloud Operations. You get: the old estate switched off, and an owner for the new one.

What you leave with

  • The workload register — dispositions, owners and order, which outlives the migration as an inventory.
  • A landing zone in code — not a console someone clicked through once.
  • A cutover runbook — rehearsed, timed, with the rollback path written down.
  • A decommissioned old estate — the part that turns a migration into a saving.

How you will know it worked

We have not published a method for migration, and we will not cite ourselves as though we had. The commitments this page makes are checkable without one: every workload has a written disposition, no workload moves before its rollback exists and has been timed, and the engagement is not finished while both estates are still running.

Where the workloads land afterwards is a separate question with its own answers — Cloud Operations for the delivery path and the rota, and GitOps Operations if you want the new estate described in Git rather than in a console.

Tell us how many workloads you think you have. The gap between that number and the inventory is usually where the interesting part of the migration is.

Talk to us

Related services

Cloud-Native Engineering

Cloud Operations

Accelerate your product development and delivery with our expert DevOps services.

Tell me more
Cloud-Native Engineering

GitOps Operations

Streamline your application management with our GitOps services.

Tell me more
Cloud-Native Engineering

Product and MVP Engineering

Design it, prove it with an MVP, then build the software that outlives the prototype.

Tell me more