Services / Cloud / Migration

A migration your customers never notice, with a way back at every step

Migrations rarely fail on the technology. They fail on the things nobody wrote down, the script that runs at midnight, the licence tied to one machine, the integration a supplier built years ago. We find those first, move in waves, and keep the old system warm until the new one has proved itself.

Start the conversation →See the technology

Why it matters

The cost is the wait

There is usually a specific moment that starts this conversation. A server out of warranty and out of spare parts. A hosting contract renewing at a number nobody wants to sign. An operating system going end-of-life, so the software sitting on top of it stops being supported. Or the quieter version: one person understands how the whole thing fits together, and they have started talking about retiring.

The instinct is to move fast and get it over with: pick a weekend, copy everything across, deal with Monday when it comes. That is where migrations go wrong. The failure is almost never the copy itself; it is the dependency nobody knew about. A reporting job that reads a file share by its old name. A payment integration allow-listing a fixed IP address. A licence key bonded to a serial number that will not exist any more. These surface at the worst possible hour, in front of the people least able to fix them.

So we do the boring part first. We build an inventory of what you actually run, not what the documentation claims you run and map how it all connects. Then we move in waves, least critical first, with the old environment still running and a tested way back at every step. Decommissioning is the last thing that happens on the project, and it only happens once you have signed off that you no longer need what is being switched off.

What you actually get

Built to be trusted

Most of the value in a migration sits in the preparation. This is what that preparation actually consists of.

We inventory what you actually run

Discovery comes before planning. Every server, database, scheduled job, certificate, DNS record, licence and integration gets found and written down, including the ones nobody has thought about since the day they were set up. The list is always longer than anyone expects, and that is precisely the point.

A dependency map, not a server list

Knowing you have twelve servers is not useful. Knowing that the reporting server reads the finance database at 2am, and that the finance database is the one with the licence tied to its hostname, is what determines the order things can safely move in.

Moved in waves, never big-bang

Low-risk systems go first so that everyone, us and your team, learns how a cutover behaves before anything critical is on the line. Each wave is a rehearsal for the next one, and the plan gets better every time.

A way back that has been tested

Rollback is not a paragraph in a plan; it is a procedure we have actually run. Before each cutover we agree what "this is not working" looks like, who decides, and how long undoing it takes. Old environments stay available until you say otherwise.

Rebuilt where it pays, relocated where it doesn't

Some systems should move as they are and be done with. Others are worth re-platforming onto managed services, because half the maintenance disappears along with them. We will tell you plainly which is which, and we will not re-architect something for the sake of it.

The old estate switched off properly

Decommissioning is part of the job: data archived to an agreed retention period, hardware disposed of correctly, DNS and certificates cleaned up, contracts and licences cancelled so you stop paying for what you no longer run.

Where it earns its keep

Same pattern, different desks

The technical shape is similar everywhere. What differs is what cannot be allowed to stop, and for how long.

01 · Manufacturing & distribution

The server in the corner of the warehouse

The problem: Stock control, dispatch and order entry all run on one machine bought years ago, sitting on a shelf near the loading bay. There is no realistic backup, the operating system is past end-of-life, and if it dies the warehouse stops, because nothing ships without it.
What we build: The system is inventoried and rebuilt in the cloud as infrastructure code, with the database moved by continuous replication so the final switch is a short pause rather than a long copy. Handheld scanners and the label printers on the floor are repointed and tested during a live shift before anything is committed.
What changes: Dispatch keeps running through the move, the single point of failure in the warehouse is gone, and the environment can be rebuilt from code if it ever needs to be.

02 · Professional services

Half in the cloud already, and worse for it

The problem: Email and documents moved to Microsoft 365 at some point, but the practice management software still lives on an office server reached over a temperamental remote desktop session. Staff work in two worlds, files exist in both, and nobody is certain which copy is current.
What we build: We consolidate. The line-of-business application moves to hosted infrastructure with single sign-on against the identity you already have, file shares migrate with their permissions preserved rather than flattened, and duplicate copies are reconciled before the move instead of being carried into it.
What changes: One login, one place for documents, and remote working that behaves the same at home as in the office, with access properly controlled instead of split across two systems.

03 · Software & SaaS platforms

One rented server that grew for five years

The problem: The product runs on a virtual machine several developers have added to over several years. Nothing is documented, deployment is a manual sequence somebody remembers, and there is no staging environment because there has never been a spare afternoon to build one.
What we build: The application is containerised and its environment described in code, so development, staging and production are built from the same recipe and differ only in size. Deployment moves into an automated pipeline with one-step rollback, and the database moves to a managed service with backups and failover included.
What changes: Releases stop depending on a specific person being available, a test environment exists that genuinely matches production, and the platform can be rebuilt from source rather than restored from memory.

The technology

The tools behind it, named

The tooling depends far more on what you are leaving than on where you are going. These are the parts we most often work with on either side of a move.

6 layers · 36 technologies

Where you are going

We take no commission from any cloud, so the recommendation follows your workloads, your team's skills and a modelled three-year cost, not a partnership agreement.

Amazon Web Services
Microsoft Azure
Google Cloud
Cloudflare
Vercel
Hetzner

What you are leaving

Most estates we inherit are some combination of these. Knowing the old platform properly is what keeps the move uneventful.

VMware
Proxmox
Windows Server
Red Hat Enterprise Linux
Ubuntu
Apache

Rebuilding it as code

Nothing is configured by hand. Every server, network and permission is described in version-controlled code, so the new environment can be rebuilt exactly and reviewed like any other change.

Terraform
OpenTofu
Ansible
Packer
Pulumi
GitHub Actions

Moving the data

The part with the least margin for error. Databases are replicated continuously and cut over in a short window, rather than copied during a long outage.

PostgreSQL
MySQL
MongoDB
Redis
Apache Kafka
Change-data-capture replication

Packaging what moves

Containers make an application behave the same on the new platform as it did on the old one, which removes an entire category of migration surprise.

Docker
Kubernetes
Helm
NGINX
Traefik
Linux

Proving it worked

Before the old system is switched off, the new one has to be measurably at least as good, under real load, not on a quiet Tuesday afternoon.

Grafana
Prometheus
OpenTelemetry
Sentry
k6
Uptime Kuma

Product names and logos are the property of their respective owners and are shown to describe the technologies we work with. Their use does not imply any partnership, sponsorship or endorsement.

How we deliver it

Live behind a human first

A straightforward estate can move in a matter of weeks. A large or heavily interconnected one takes months, and we would rather tell you that at the start than discover it halfway.

We find out what you actually have

Automated discovery across your network and cloud accounts, plus conversations with the people who use the systems every day. It covers the unglamorous things too: licence terms, contract end dates, certificate owners, and the integrations everyone forgot were there.

We map dependencies and agree the order

Which systems can move alone, which must move together, and which should be retired rather than migrated. You get a wave plan with the reasoning written down, sequenced around your business calendar rather than ours: year end, peak season, an audit.

We build the landing zone first

Accounts, networks, identity, logging, backup policy and cost controls, all as code, before a single workload arrives. Doing this properly at the start is exactly what prevents the messy cloud setup you would otherwise be asking someone to rescue in two years.

We rehearse on something that doesn't matter

The first wave is deliberately low-stakes. We run the cutover end to end, time every step, find what the plan missed, and there is always something, then correct the plan before anything important moves.

We cut over in waves, running in parallel

Each wave moves with the old environment still live. Data is replicated ahead of time so the switch itself is short. If the agreed checks fail, we roll back and go again on another date. That is a normal outcome, not a disaster.

We switch the old estate off: last

Only after an agreed period of stable running, and only with your sign-off. Data is archived to the retention period you have chosen, contracts and licences are cancelled, and you are handed the documentation and runbooks for what now exists.

Before you commit

The questions worth asking

Will we have downtime?

For most systems the answer is minutes, in a planned window you choose, usually overnight or at a weekend. For some it is genuinely zero, because traffic can be shifted gradually. But we will not claim it is always zero: a large, write-heavy database normally needs a short freeze while the final changes are applied, and anything tied to specific hardware or a machine-locked licence may need longer. You get the expected window for each system before you approve its wave.

How long does the whole thing take?

It depends almost entirely on how many systems there are and how tangled they have become, so an honest answer only exists after discovery, which is itself usually a couple of weeks and produces a plan with dates. What we can say is that the schedule is driven by dependencies and your business calendar, not by how fast anyone can copy data.

Will it cost more during the migration?

Yes, almost certainly, and anyone telling you otherwise is selling. For the overlap period you pay for the old estate and the new one at the same time, plus the project itself, plus one-off charges for getting data out of an existing provider. That bulge is temporary but it is real, and it is the single most common unpleasant surprise in cloud projects. We model it during scoping so it lands in your budget as a planned cost rather than an unexplained invoice.

Do we have to move everything?

No, and often you should not. Some workloads are cheaper or faster on hardware you already own, some are pinned in place by licensing, and some are close enough to retirement that moving them is wasted money. We design hybrid setups where the cloud and your own equipment are managed as one system, so your team learns one way of working rather than two.

What happens if a cutover goes wrong?

We roll back to the old environment, which is still running, and go again on another date once we understand why. The decision point, the person who makes it and the time it takes are agreed in writing before the window opens, so nobody is improvising at 2am. A rolled-back wave is an inconvenience. A wave pushed through because rolling back was never planned for is an outage.

Who owns the cloud accounts afterwards?

You do. Accounts are created in your organisation's name, on your billing, with your people as owners. We work inside them with scoped access. If you stop working with us tomorrow, nothing has to be transferred and nothing is held hostage. That includes the infrastructure code, the pipelines and the documentation.

Not sure what you're actually running?

Most people aren't, and that's normal. Tell us roughly what you have and what's forcing the move, and we'll tell you what a realistic plan looks like before you commit to anything.

Start the conversation →

Explore more

The rest of Cloud & Infrastructure

Cost optimisation Security & compliance Reliability ← All of Cloud