Cloud migration engineering
Migrations fail in the middle, not at the start. The discovery is interesting, the first wave goes well, and then the remaining sixty percent sits in a backlog for a year because nobody is assigned to the boring part.
- Common triggers
- Data centre lease expiry, acquisition, platform end of life
- Typical shape
- Fixed-scope discovery, then an embedded pod for execution
- Team size
- Two to six engineers plus a delivery lead
- Duration
- Three to twelve months, wave dependent
- Roles involved
- Cloud engineers, DevOps, data engineers, FinOps
CloudOps Network staffs cloud migration work with engineers who have completed data centre exits, cloud-to-cloud moves and platform migrations end to end. Typical engagements cover application discovery and dependency mapping, wave planning, landing zone build, migration execution and cutover, with a shortlist available within about 72 hours.
What the engineers actually do
Discovery and dependency mapping
Find out what is actually running, what talks to what, and which of it nobody has owned since 2021.
Wave planning
Sequence applications by risk and coupling, so the first wave teaches you something and the last wave is not the hardest one.
Landing zone build
Accounts, networking, identity, guardrails and logging, built so the platform team can extend it afterwards.
Migration execution
Rehost, replatform or refactor per application, decided on evidence rather than on a blanket policy.
Cutover and rollback
Runbooks, rehearsal, a rollback path that has been tested, and someone awake for the window.
Decommissioning
The step everyone skips. Old systems left running are where the projected savings quietly disappear.
Signs you need outside help
Migration work is unusually easy to start and unusually hard to finish. These are the patterns we see just before a programme stalls.
The first wave landed, the second has not moved in two months
Usually a capacity problem disguised as a prioritisation problem.
Nobody can produce a current dependency map
If discovery output is more than six months old, it is fiction.
The business case assumed decommissioning that has not happened
Running both estates is the single most common reason savings do not appear.
Your platform team is now doing migration full time
Which means the platform work they were hired for has stopped.
How a migration engagement runs
Discovery
Two to four weeks, fixed price. Inventory, dependencies, a wave plan, a cost model and a risk register you can take to a board.
Landing zone
Build or remediate the target environment. Identity, network, guardrails, logging and cost controls before any workload moves.
Wave execution
Applications move in planned waves. Each wave ends with a retrospective that changes the plan for the next one.
Cutover
Rehearsed, documented, with rollback tested rather than assumed.
Decommission and hand back
Old estate shut down, documentation handed over, and your team running it without us.
Questions on this work
How long does a migration take?
A single application can move in weeks. A full data centre exit typically runs six to eighteen months depending on application count, coupling and how much refactoring the business case demands.
Do you do lift and shift or refactoring?
Both, decided per application. Blanket policies in either direction are how migrations get expensive. Rehosting a system due for retirement wastes money, and refactoring something that works is often worse.
Can you work alongside our existing partner?
Yes. A good share of migration engagements are capacity added to an in-flight programme rather than a replacement for it.
Do you cover Azure and Google Cloud?
Yes, though the deepest bench is on AWS. Tell us the target platform in the brief and we filter for demonstrated experience on it.
Tell us what you are building
Describe the work in a few lines. We come back with a shortlist of engineers who have done it before, their availability, and a rate range. No account, no platform fee, no obligation to hire.
Most briefs get a shortlist within three business days.