Move without the weekend from hell.
We follow the AWS Migration Acceleration Program structure — assess, mobilise, migrate, modernise — because it front-loads the discovery that makes cutovers boring.
Four phases, each with a deliverable you can hold
Nothing moves until the inventory is real. Roughly half the migrations we rescue went wrong because discovery was compressed to fit a sales timeline.
| Phase | Duration | What happens | Deliverable |
|---|---|---|---|
| Assess | 2–3 weeks | Automated discovery, dependency mapping, interviews with application owners, TCO modelling and 7R disposition per workload | Application inventory, dependency map, TCO model, migration wave plan |
| Mobilise | 3–5 weeks | Landing zone build, network and identity, security baseline, operating model, and one pilot workload taken all the way to production | Control Tower landing zone, connectivity, guardrails, pilot workload live |
| Migrate | By wave | Wave-by-wave execution with rehearsal in a non-production wave first, hypercare after each cutover, and decommission tracked to closure | Cutover runbooks, rollback plans, hypercare reports, decommission schedule |
| Optimise | Ongoing | Rightsizing against real post-migration usage, modernisation backlog, and transition into managed operations | Optimisation report, modernisation roadmap, handover to run |
Funding
Eligible migrations can attract AWS investment through the Migration Acceleration Program, which commonly offsets a meaningful share of assessment and mobilise costs. We prepare and submit the nomination — it is our paperwork, not yours. How AWS funding works →
What we move, and what we tell you not to
VMware & Hyper-V estates
Rehost with AWS Application Migration Service, or land on VMware Cloud on AWS where a genuine constraint justifies it. We will say which, with reasons.
Windows & SQL Server
Licensing analysis first — BYOL versus license-included changes the economics more than instance choice. Then modernisation options, ranked by payback.
Database modernisation
Oracle and SQL Server to Aurora or PostgreSQL using DMS and schema conversion, with a measured cutover window and a tested fallback.
Co-location exits
Staged decommission with cost tracking, so the savings actually land instead of running two environments for a year.
Containerisation
To ECS or EKS where it earns its keep. We do not containerise an application that will be retired in eighteen months.
What stays put
Some workloads should not move — latency-bound OT systems, licence-trapped appliances, applications with a three-year contract left. We will tell you before you pay us to move them.
Sequenced by blast radius, not by spreadsheet order
The wave plan is the artefact that makes a migration feel knowable. Ours orders workloads by dependency depth and failure consequence, so the team builds confidence on low-risk waves before touching anything that would make the evening news.
- Dependency graph built from network flow data, not from memory
- Each wave has an owner, a rehearsal date and a rollback trigger defined in advance
- Business calendar respected — no cutover in a trading peak or reporting period
- Decommission tracked per wave so the old estate actually gets switched off
Every production cutover is rehearsed at least once
The rehearsal is not a formality. It is where we find the undocumented cron job, the hard-coded IP and the certificate nobody can renew.
Runbook
Step-by-step, timed, with named owners and a go/no-go checkpoint. Written before the rehearsal, corrected after it.
Rehearsal
Full dress run in a non-production wave, including the rollback path. The clock is measured, not estimated.
Cutover
Incident-style command with a single decision-maker, a live channel and a rollback trigger agreed in advance.
Hypercare
Heightened monitoring and a dedicated engineer for the agreed window, then a written wave report before the next wave starts.
The part most migrations skip
A lift-and-shift lands you on cloud pricing with on-premises sizing. That is why so many migrations show a cost increase in month two and a difficult conversation in month three.
We rightsize against real post-migration usage, not the pre-migration guess, and either hand over to your team with the documentation to keep it that way, or take it into managed operations.
Related case study
Two co-location leases expiring within a month of each other, 380 servers and an estate documented mostly in the heads of three engineers. Delivered six weeks early, run-rate down 31%.
Read the case studyMigration questions
How long does a data centre exit really take?
For a few hundred servers, nine to fifteen months end to end is realistic including decommission. Assess and mobilise take two to three months of that. Anyone quoting a 300-server exit in twelve weeks is quoting the migration and ignoring the discovery, the rehearsals and the decommission.
Do we have to move everything?
No, and you probably should not. The assessment gives each workload a disposition — rehost, replatform, refactor, repurchase, retire, retain, relocate — with the reasoning attached. Retire and retain are legitimate answers and we use them.
What happens if a cutover fails?
We roll back on the trigger agreed before we started, not after a debate at 3am. Rollback is tested in the rehearsal, so the path is known. It happens — one wave in eleven on a recent programme — and it is far cheaper than pushing through.
Can you work with our incumbent integrator?
Yes, and often we do. The boundary needs to be explicit in writing: who owns the wave plan, who owns the cutover decision, and who is on the bridge at cutover. Ambiguity there is the most common cause of a bad night.
How is migration work priced?
Assessment is a fixed price from $18,000. Mobilise and migrate are quoted per programme once the assessment tells us the real scope — quoting them earlier would be a guess dressed as a number. AWS funding is applied for where eligible and reduces what you pay.
Start with the assessment
Two to three weeks, fixed price, and often partially AWS-funded. You end up with an inventory and a wave plan you own — usable with or without us.