Home › Services › Cloud setup & migration
Migrations fail on scope, not on technology
On-premise to cloud, or one cloud to another. They go wrong when the scope was never pinned down, the date could not be defended, and there was no way back. We work the other way round, and we stay on to run what we built.
- Fee
- Fixed scope, fixed price + GST · quoted once the scope is agreed
- First wave
- 6–8 weeks
- Pricing
- Fixed cost, per wave
- Moves
- On-premise → cloud, cloud → cloud
On-premise to cloud is the one most people mean: a datacenter or a colo cage, a rack in an office, a set of servers with three years of undocumented history on them. Cloud to cloud is increasingly the other one: a move off a provider whose commercials stopped working, off an account somebody else controls, or off an estate a departed founder or agency set up and nobody else can log into.
The second is not the easier of the two. It looks like a copy and it behaves like a migration, because identity, networking, managed-service equivalents and egress charges all change underneath you. We scope it the same way, on the same fixed cost, with the same rollback path.
We size the first wave to be boring
The first wave earns the right to the second.
Talk to us about thisRoughly a fifth of organisations report cloud budgets overrunning by more than 20%, and the usual cause is discovering the real dependency map halfway through. So the first thing we do is find out what talks to what, and then deliberately pick a first wave small enough that the date is not in question.
That first wave earns the right to the second. It also gives your team a real rehearsal of the cutover process while the stakes are low.
- Discovery: inventory, dependency mapping, licensing implications, and the workloads that shouldn't move at all.
- Landing zone: accounts and projects, network topology, identity, guardrails, logging and budget alarms, built as Terraform in your repository.
- Wave plan: what moves when, what each wave depends on, and what the rollback is for each one.
- Migration: lift-and-shift where that's honest, re-platform where it pays for itself within the year.
- Cutover: rehearsed, run out of hours, with a rollback path agreed in writing and a go/no-go call with a named decision-maker.
- Stabilise: two weeks of hypercare, then a right-sizing pass once real usage data exists.
The workloads we'll tell you not to move
A proposal that moves everything is a sales document.
Talk to us about thisSome things are cheaper, faster or simply safer where they are: licence-bound databases, latency-sensitive plant systems, kit with three years left on the warranty. A migration proposal that moves everything is a sales document, not a plan. Ours will name what stays, and what it would cost you to move it anyway.
A migration changes where the traffic goes, and almost nothing else changes with it.
The leased line or MPLS circuit sized for the pre-migration world keeps billing at the old capacity, the DR site keeps its own, and the two facts live with different teams, so nobody puts them side by side. It is one of the most commonly cited causes of over-provisioned circuits, and a cloud cost tool cannot see a circuit while a telecom audit cannot see a VPC.
We take a baseline of both before the first wave and re-measure after it, so the circuit conversation happens on the way out rather than a year later.
The usual sting in a migration is the org chart it implies. The estate goes live and somebody now has to run it, which for a company of this size means hiring a cloud administrator, or quietly asking the person who ran the servers to learn a new platform on production.
You can hand it to your own team, and everything we leave behind is written so that works. If you would rather not, the same engineers who built it run it under an AMS contract: a support retainer or a variable model sized to the estate, with monitoring, anomaly detection and a live cost dashboard rather than a monthly PDF.
- Infrastructure as code in your repository, not ours.
- Runbooks and as-builts written for someone who wasn't in the project.
- A cost baseline taken on day one, so the following quarter's bill is explainable.
- Admin credentials and the ability to hand the whole thing to anyone else.
Once you're live, the follow-on work is usually a cost assessment after a full billing cycle, or an AMS contract if you'd rather we ran it.
What you walk away with
Yours to keep, and to hand to anyone else, including a provider that isn't us.
Talk to us about thisTerraform in your repository, not ours. The environment can be rebuilt without us.
Written for someone who wasn't in the project, because one day that's who will read them.
So the following quarter's bill is explainable rather than alarming.
And what it would cost you to move it anyway, if you decide to.
Asked before you ask
The ones that come up on nearly every first call.
Talk to us about thisHow long does a migration take?
The first wave is usually six to eight weeks including discovery, for a scope we've deliberately kept tight. Whole-estate programmes run longer and we quote them wave by wave rather than as one number, because a single number that far out isn't honest.
Can you work with our existing team?
That's the preferred shape. Your people know the applications; we know the target platform. We'd rather leave capability behind than a dependency on us.
What happens if the cutover goes wrong?
It rolls back to the agreed point, on the plan we rehearsed, inside the window. That's the entire reason we insist on a rollback path in writing before the window opens.
Which cloud should we pick?
Usually whichever your team already has skills in, unless a specific service or a commercial reason says otherwise. We are vendor-agnostic across both and we resell neither, so our recommendation serves your bill rather than a reseller margin.
We are already on a cloud and want to leave it.
That is a migration, not a copy, and we scope it as one: identity, networking, managed-service equivalents and egress all change underneath you. It is the same fixed-cost, wave-by-wave method, and the egress bill for the move itself is quoted up front rather than discovered.
Not sure this is the one you need?
Tell us the symptom, not the service, and we'll say which of these applies, or that none of them do. A reply within one working day, from someone technical.
The rest of what we do
Most engagements start with one of these and grow into another.