SERVICE

Cloud migration

Moving without a freeze, and without arriving at a bigger bill.

What this actually is

Cloud migration is a sequencing problem more than a technical one. Almost anything can be moved; the question is in what order, with what fallback, and which parts should not move at all.

The two common failures are opposite. Lift-and-shift everything and you arrive with the same architecture and a larger bill. Re-architect everything first and you spend a year not shipping features. The workable path is usually neither.

What we do

Inventory and dependency mapping
What runs where and what talks to what — including the server nobody can identify, which every estate has.
Sequencing
What moves first, what moves together, and what stays. Ordered so each step is independently reversible.
Landing zone
Accounts, networking, identity and guardrails set up before workloads arrive rather than retrofitted around them.
Migration
Workload by workload with rollback at each step, running in parallel until the new path is trusted.
Optimisation
Right-sizing after the move, when real usage is visible instead of estimated.

The stack

TerraformAWS / Azure / GCPKubernetesDockerDatabase migration toolingVPN and Direct ConnectCost management tooling

What it connects to

Integration surface is the honest driver of effort — ten systems is not ten times one system.

On-premise hypervisors and storage
Identity providers and directory services
Existing monitoring and backup systems
Network and firewall infrastructure
Databases requiring minimal-downtime cutover

How a project runs

Discovery

2–4 weeks

Inventory, dependencies, and a costed target-state estimate.

Landing zone

2–3 weeks

Accounts, networking, identity and policy guardrails in place.

Pilot workload

2–4 weeks

One non-critical service moved end to end, with the rollback exercised.

Migration waves

2–9 months

Workloads moved in dependency order, each independently reversible.

Optimise

ongoing

Right-sizing and reserved capacity once real usage is visible.

Where teams use it

Data centre exit

A lease or hardware refresh forcing a decision with a fixed deadline.

Scaling limits

Infrastructure that cannot absorb peaks without buying for the peak permanently.

Disaster recovery

A DR posture that has never actually been tested, which is common and usually the real driver.

Compliance

Residency or certification requirements a current provider cannot meet.

Cost

Moving off over-provisioned infrastructure, or back off cloud where it turned out to be the wrong fit.

When this is the wrong answer

Lift-and-shift arrives with the same architecture and a bigger bill. It is a legitimate first step only when the deadline is real and the re-architecture is genuinely planned to follow.

Some things should not move. Latency-sensitive workloads next to on-premise equipment, or systems whose licensing makes cloud absurd, are better left where they are.

The bill goes up before it goes down. Running both estates in parallel is the safe path and it is not free, and that overlap belongs in the budget from the start.

A migration without a tested rollback is a one-way door. If a step cannot be reversed within an hour, it has not been planned properly.

Frequently asked questions

How long does a migration take?

A single application, weeks. A whole estate, six to eighteen months depending on dependencies and how much can move in parallel. Discovery is what turns that range into a plan.

Will we save money?

Not automatically, and not immediately. Savings come from right-sizing and from shutting things down, not from the move itself. Anyone promising savings before seeing your utilisation is guessing.

Can you do it without downtime?

For most workloads, with parallel running and a cutover. Some databases need a maintenance window, and we will tell you which rather than discover it during the cutover.

Which provider should we choose?

Usually the one your team already knows, unless a specific service or a commercial arrangement points elsewhere. Provider choice matters less than most comparisons imply.

Who owns the code?

You do, from the first commit — work happens in your repository under your licence, and the contract assigns IP outright. We keep no rights and build no dependency that makes leaving expensive.

What does it cost?

We do not publish a number, because the honest one depends on scope, integrations and the accuracy bar. Tell us the budget you are working with and we will say what it buys — or say plainly if it does not buy enough.

DevOps Consulting →Legacy System Modernisation →Custom Software Development →Hire engineers for this →