Cloud migration
Moving workloads without moving the mess: an inventory first, a costed target second, then a migration executed in slices you can stop at any point.
The estimate is the risky part, not the move
Migration plans fail on arithmetic more often than on engineering. The target is sized from the current machine list rather than from measured demand, the run-rate is discovered after the cutover, and the fallback plan exists only as a sentence in a slide deck.
What we do
How the work goes
Inventory and measure
What exists, what it uses, what depends on what. Two to four weeks depending on estate size, and the part most likely to change the plan.
Design and cost
A target architecture with a monthly figure attached, plus the assumptions behind it written down so they can be challenged.
Move in slices
Workload by workload, with verification after each. You can stop after any slice and still be in a coherent state.
What you get
- Inventory with owners and dependencies
- Target architecture and a costed monthly run-rate with stated assumptions
- Per-slice runbooks including rollback
A good fit when
- Moving to AWS, or between accounts and regions within it
- Estates where nobody is confident the inventory is complete
Not us, and we will say so
- A lift-and-shift with a deadline that leaves no room for the inventory — that plan fails and we would rather not be in it
Tell us what you are running.
A first call is a conversation. If this is not the service you need, we will point you at the one that is — or tell you that you do not need us yet.
Book a call