Inventory and dependency map
What talks to what, including the cron job on the box under someone's desk. Migrations fail on the things not in the diagram.
Migration
AWS migration
From a data centre, from another cloud, or out of the half-finished migration someone else left behind. Every cutover is rehearsed on a copy before it touches the real thing.
Dry run firstRollback planStaged cutover
What does an AWS migration involve?
An AWS migration moves applications and data from a data centre or another cloud onto AWS. The work is an inventory and dependency map, a landing zone built in code, the data move, at least one timed rehearsal against a clone, then the cutover and the week of on-call after it.
The problem
The risk is never the copy, it is the switch
Moving the data is the easy part. The hard part is the hour where DNS has changed, half your traffic is on the new stack, and something nobody tested is failing. So we rehearse that hour, more than once, with the rollback path timed and written down before anyone touches production.
50+
migrations delivered
2+
full rehearsals per cutover
1
rollback plan, tested
What you get
Included in the engagement
Landing zone
Accounts, VPCs, IAM boundaries and logging built in Terraform before a single workload lands, so environment two is a copy rather than a rebuild.
Data migration
DMS, native replication or snapshot-and-catch-up depending on how much downtime you can afford. We tell you the honest number, not the optimistic one.
Rehearsal
A full dry run against a clone, timed end to end. This is where the surprises are meant to happen.
Cutover and the week after
We are on the call for the switch and on the pager for the days after it, when the load pattern finally looks real.
How it runs
How a migration runs
Nothing customer-facing moves until the same steps have been run on something that does not matter.
Inventory and dependency map
Every server, database, queue and cron job, and what talks to what. The surprises are almost always here rather than at cutover.
Landing zone
Accounts, network, IAM and logging built before anything moves, so the first workload across does not set the standard by accident.
Quiet workloads first
Internal and low-traffic systems go first. They prove the pipeline and the runbook while nothing customer-facing is at risk.
Rehearsal
A full dry run against a copy of production, timed, with the rollback actually exercised. We repeat it until the timings stop moving.
Cutover and the week after
The rehearsed window, with the rollback plan on the table. Then a week of watching before anything old is switched off.
Fit
Who this is for
If none of these sound like you, say so on the call and we will tell you honestly whether this is the right piece of work to start with.
- A colocation contract or hardware refresh is forcing the decision.
- You are on another cloud and the commercial case for AWS has changed.
- A previous migration stalled halfway and you are paying for both sides.
How much downtime should we plan for?
For most stateless applications with a replicated database, minutes. For a single large database that cannot replicate, it depends on size and write rate, and we will give you the measured number after the first rehearsal rather than a guess in the proposal.
Can we move one workload first?
That is what we recommend. Pick something real but not existential, move it, run it for a month, then decide about the rest with actual evidence.
What are the 7 Rs of cloud migration?
Rehost, replatform, repurchase, refactor, relocate, retain and retire. Most estates end up as a mix: lift a few things as they are, replatform the databases, and retire the handful of services nobody has used in a year.
Do you migrate from Azure or Google Cloud as well?
Yes. The pattern is the same, and the awkward parts are usually identity and managed services with no exact AWS equivalent. Those get named in the inventory stage rather than found during cutover.
What happens if the cutover goes wrong?
You roll back on the path we timed during the rehearsal. It is written down, it has been run, and the decision point for using it is agreed before the switch so nobody is debating it at two in the morning.
Who is on the call during the switch?
The engineer who built the migration, not a handover team reading notes. They stay on the pager for the days afterwards, when the real load pattern turns up.
How long does a migration take?
A single workload with a replicated database is weeks. A data centre exit with dozens of interdependent services is quarters. The inventory stage is what turns that range into a date, which is why it comes first.
Reference
The AWS documentation we work from
Related
Work that usually comes with this
AWS Well-Architected Review
A two-week read of your AWS account against the six pillars. You get a ranked list of what to fix, what it costs, and what happens if you leave it.
AssessmentRead more
DevOps and platform
Terraform, deployment pipelines and environments that rebuild from code. Deploys a new hire can run in their first week without supervision.
PlatformRead more
Modern app development
Containers on EKS or ECS, microservices where they earn their keep, and enough observability to debug the system at three in the morning.
BuildRead more
Send us your AWS bill
Thirty minutes with an engineer, no slide deck. We will tell you what we would change first and what it would cost to have us do it.