02/MIGRATE TO AWS
Moving to AWS without the weekend everyone dreads.
Your application runs somewhere that no longer fits — a VPS you have outgrown, a managed host that limits what you can change, a data centre with a contract ending, or another cloud you would rather leave.
AWS is the destination. The part that stops you is the move itself.
You have heard the stories: the weekend that ran to Tuesday, the migration that worked in staging and fell over under real traffic, the rollback that turned out not to exist.
The application earns money while it runs, so the migration has to happen without your customers experiencing it.
01/Why it happens
It is nearly always one of these three.
Migrations are planned as one event
A single cutover means a single point of failure, executed once, under time pressure, by tired people. Almost every migration horror story has this shape.
The rollback is theoretical
A rollback plan that has never been executed is a paragraph, not a capability. It gets tested for the first time on the night it is needed.
The old environment holds undocumented state
A cron job, a file written to local disk, a hardcoded IP in a partner's allowlist. These surface during the cutover rather than during planning, because nobody went looking.
02/What we do about it
The engagement, phase by phase.
Inventory what actually runs
one to two weeks
Every service, scheduled job, data store, outbound integration and inbound allowlist. This phase is where migrations are won, and skipping it is where they are lost.
Produces
A dependency map, including the parts nobody documented
Design the target and the order
one to two weeks
What the environment looks like on AWS, and which workload moves first. Ordered so the earliest moves are the ones that are easiest to reverse.
Produces
A target architecture and a workload-by-workload sequence
Build the target environment
two to four weeks, depending on the estate
The new environment is stood up in parallel and tested with real traffic patterns while the old one keeps serving. Nothing is switched off yet.
Produces
The AWS environment as infrastructure as code, running alongside the old one
Rehearse the cutover
a few days
The cutover is executed against a copy, including the rollback. The first time we do this is not the night it counts.
Produces
A timed runbook, and a rollback that has been performed
Cut over in stages
per workload, scheduled with you
Workloads move one at a time, with the previous environment left running until each move has proved itself. Decommissioning happens last and deliberately.
Produces
Traffic on AWS, the old environment intact behind you
03/What done looks like
How you will know it worked.
- Production traffic served from AWS, with the old environment retired on purpose
- The environment defined as code, so it can be rebuilt rather than remembered
- A cutover runbook that was followed, with the timings that actually happened
- Monitoring and alerting live on the new environment before the traffic arrived
- A cost breakdown of the new environment, compared against the old bill
- No outstanding dependency on the previous host, including DNS and allowlists
04/Honest caveats
Where this gets harder.
Every engagement has failure modes. Here are this one’s, before you commit to anything rather than after.
- Some downtime is occasionally unavoidable — a database engine change, a switch that cannot be dual-written. Where that is true we will tell you the size of the window rather than pretending it is zero.
- AWS is not automatically cheaper than what you have now. Lifting an inefficient application into AWS usually costs more; the saving comes from what gets changed during the move.
- Third parties who allowlist your IP addresses become the critical path, and their timelines are theirs, not ours. We identify them in week one for that reason.
- An application that assumes local disk or in-process state needs code changes before it can move properly. We would rather make those changes than work around them.
05/Questions
Migrate to AWS, asked about.
01How long does a migration take?
A single straightforward application is typically a few weeks; an estate of interconnected services with compliance requirements runs to months. The inventory phase is what turns that range into a date, which is why it comes first.
02Do we have to change the application to move it?
Not always, but often it is worth it. A lift-and-shift gets you onto AWS quickly and keeps every inefficiency you already had. We will show you both options with their cost profiles and let you decide.
03What happens if the cutover goes wrong?
We roll back to the previous environment, which is still running and still serving. That is the entire reason it stays up until each move has proved itself, and the reason the rollback is rehearsed beforehand.
Sound familiar?
Describe your version of it. You will get a reply from an engineer within one business day, including if we think you do not need us.