How much downtime will the cutover cost us?

For most systems it is minutes rather than hours, because the new environment is already built and already holding a copy of your data before anything is switched. The exception is a large database that has to be brought fully up to date at the moment of the switch. We tell you which of those two situations you are in during the inventory, not on the day.

Can you just take an image of our current server and run it in the cloud?

Technically yes, and it is usually the wrong purchase. You would be paying a monthly bill for the same machine, with the same unrotated logs, the same unpatched packages and the same files sitting on a local disk that stops you ever running a second copy. If a straight lift is genuinely what you need, we will say so and it will be the cheap end of the range.

Which provider should we choose?

Whichever one your team can operate and your users are near. AWS has the widest service catalogue, Azure suits organisations already committed to Microsoft identity and licensing, GCP is strong on data work. Distance is the part users actually notice, so the region matters more than the logo — a user in the Gulf served from a European or Middle Eastern region will feel the difference far more than any feature comparison.

What happens to our old system after the move?

It stays running and untouched for an agreed stabilisation window, because it is the fastest rollback that exists. Only after that window closes, and after a backup of the final state is taken and stored outside the old provider, is anything decommissioned. Nothing is deleted to save a month of hosting.

We have no documentation and the original developer has left. Is that a problem?

It is the normal starting position and it is what the first phase exists for. We read the running machine rather than the paperwork — what listens on which port, what the cron table holds, which certificates renew from where, which outside services hold your old IP address in an allowlist. That inventory is yours to keep whatever you decide about the move.

Will the cloud bill be lower than what we pay now?

Often not, and anybody promising otherwise has not seen your workload. Cloud buys you elasticity, redundancy and managed services, not a cheaper monthly number — a steady predictable load on owned hardware can be very hard to beat on price alone. We model the target cost before the build starts so the decision is made with a figure in front of you.

Cloud, DevOps & Infrastructure

Moving your systems onto AWS, Azure or GCP

A rehearsed migration — full inventory first, the new stack built and run in parallel, and a cutover you have already practised before the day it happens.

From: $2,000–$40,000
Typical time: 1–5 months
Usually bought by: SMEs, enterprises

What this actually solves

Migrations start with one of two sentences. The first is that the hardware is going away — a lease ending, a data centre closing, a machine old enough that the replacement disks are no longer sold. The second is quieter and far more common. The business grew, and everything now runs on one box that one person understands.

The second case is the expensive one, because the risk is not technical. The system works, so nobody has opened it in years. There are cron jobs nobody remembers writing. A certificate that renews from a script in someone's home directory. A payment gateway that only accepts calls from a single IP address. Logs that have been written since launch and never rotated, quietly consuming the disk until the database has nowhere left to write and every request turns into a 502 Bad Gateway — a failure that takes minutes to fix and days to diagnose if nobody knows where the server physically is. A migration is the first time in years that anyone opens the box, and everything that was never written down surfaces at once.

Moving to cloud does not fix any of that by itself. Copying a badly configured server into a cloud instance gives you the same badly configured server with a monthly bill attached. The value is in the second half of the work — the application made able to run as more than one copy, state moved off local disks, the undocumented parts written down, and a switchover that has been rehearsed rather than attempted.

How the migration runs

Inventory the system that actually exists, not the one on the diagram. What listens on which port, what the cron table holds, where certificates come from, which outside services hold your current IP address in an allowlist, where user-uploaded files live, and which parts hold state that cannot be recreated. This phase produces a written map whether or not you go ahead with the move. Three to five days.
Design the target and price it before building it. Region chosen for where your users and your data-residency obligations are, not out of habit. Instance sizes taken from real utilisation. Every redundancy decision costed explicitly, because spreading across availability zones means paying for those line items in every zone you spread across, and that has to be a decision somebody makes rather than a default somebody inherits. Three to seven days.
Build the target and run it alongside the old one. The new environment is stood up, a restored copy of the data is loaded into it, and the application is exercised against it while the live system carries on serving customers untouched. This is where the real work sits — state pulled out of local disks and into object storage, secrets moved out of config files, the reverse proxy and certificate path rebuilt properly. Two to six weeks.
Rehearse the cutover. The DNS records are dropped to a short time-to-live a full day ahead so the world stops caching the old address for hours. The sequence is written down — what is stopped, in what order, what is copied last, what is checked before traffic is released, and the exact steps to go back. Then it is walked through end to end against the parallel environment. Two to four days.
Cut over, then stay. Traffic moves, the checks from the rehearsal are run in order, and we watch the error rates and the outside integrations rather than declaring victory. The old environment is left running as the rollback until an agreed stabilisation window closes, and only then is it decommissioned, after a final backup is stored somewhere that is not the old provider's account. One to three weeks.

Tools you will see named in the handover — dig for verifying what the world resolves, certbot for certificate state, df -h and free -m for the capacity numbers on the old box, provider CLIs and Terraform for building the target, and the database vendor's own dump and replication tooling rather than a generic file copy.

What moves the price

How much state there is. A stateless application that reads from a managed database is a straightforward move. A system with users uploading files to a local disk, a search index built in place, and sessions held in memory has three separate problems to solve before it can run anywhere else, and each is real engineering.

How much is undocumented. The inventory phase is short when there is a repository, a deployment script and someone who knows the system. It is long when the answer to every question is that the person who set it up has left. That is not a reason not to do it, but it is the single largest variable in the estimate.

Whether you can be offline. A business that can accept a quiet Sunday window gets a simpler, cheaper migration. A system that has to stay live through the switch needs replication, dual running and a far more careful cutover, and that difference is measured in weeks.

What usually goes wrong

The old server is lifted as an image and called a migration. Everything wrong with the machine comes with it — the logs that never rotate, the packages that were last patched three years ago, the uploads on a local disk that make a second instance impossible. You now pay cloud prices for a legacy problem, and the first real incident looks exactly like the last one did.

The DNS cache is discovered on the day. Records are changed at ten in the morning with a long time-to-live still set, so for the rest of that day a share of traffic keeps arriving at the old system. Both environments accept orders. Two databases now hold different truths about the same afternoon, and reconciling them by hand is worse than the outage would have been. Lowering the time-to-live is a five-minute job done the day before, and skipping it is the most common single failure in this work.

Outside services keep pointing at the old address. The payment gateway, the SMS provider and the mail relay each hold your previous IP in an allowlist. The website comes up perfectly on the new stack and payments silently fail, which is why the inventory hunts for those allowlists specifically and why the cutover checklist includes a real transaction rather than a page load.

See where the site stands before you brief anyone.

If the site is already live, start from what it scores rather than from a guess. The audit reports what it checked, what it found, and — the part most tools leave out — what it could not check, and why.

See the website audit Talk about this work

Questions people ask before they commit.

How much downtime will the cutover cost us?: For most systems it is minutes rather than hours, because the new environment is already built and already holding a copy of your data before anything is switched. The exception is a large database that has to be brought fully up to date at the moment of the switch. We tell you which of those two situations you are in during the inventory, not on the day.
Can you just take an image of our current server and run it in the cloud?: Technically yes, and it is usually the wrong purchase. You would be paying a monthly bill for the same machine, with the same unrotated logs, the same unpatched packages and the same files sitting on a local disk that stops you ever running a second copy. If a straight lift is genuinely what you need, we will say so and it will be the cheap end of the range.
Which provider should we choose?: Whichever one your team can operate and your users are near. AWS has the widest service catalogue, Azure suits organisations already committed to Microsoft identity and licensing, GCP is strong on data work. Distance is the part users actually notice, so the region matters more than the logo — a user in the Gulf served from a European or Middle Eastern region will feel the difference far more than any feature comparison.
What happens to our old system after the move?: It stays running and untouched for an agreed stabilisation window, because it is the fastest rollback that exists. Only after that window closes, and after a backup of the final state is taken and stored outside the old provider, is anything decommissioned. Nothing is deleted to save a month of hosting.
We have no documentation and the original developer has left. Is that a problem?: It is the normal starting position and it is what the first phase exists for. We read the running machine rather than the paperwork — what listens on which port, what the cron table holds, which certificates renew from where, which outside services hold your old IP address in an allowlist. That inventory is yours to keep whatever you decide about the move.
Will the cloud bill be lower than what we pay now?: Often not, and anybody promising otherwise has not seen your workload. Cloud buys you elasticity, redundancy and managed services, not a cheaper monthly number — a steady predictable load on owned hardware can be very hard to beat on price alone. We model the target cost before the build starts so the decision is made with a figure in front of you.

Often taken together.

Start with the brief, not the invoice.

Send what you are trying to achieve. You get a written scope, a price and a date — or an honest “this is not the right service for that”.

Talk about Cloud migration (AWS / Azure / GCP) All Cloud, DevOps & Infrastructure services