AWS Migration
The target architecture, and the order you move in. Those two calls decide whether a migration lands or stalls halfway with half your estate in each place.
Migrations rarely fail on the technology. They fail on sequencing. A dependency nobody mapped. A database that turns out to be shared by four systems. A cutover window the business was never going to give you. By the time any of that surfaces the project is committed, and the honest options have gone.
This engagement pulls those decisions to the front. You come out with a target architecture, a defensible treatment for each workload, a move order that keeps the business running throughout, and a cost model you can hand to whoever is paying.
I scored 911 out of 1000 on the AWS Certified Solutions Architect Professional exam, against a 750 pass mark, in 2020. The certificate lapsed in 2023. More useful than any certificate: I lead architecture for a multi-region platform running production workloads on AWS across Asia and Europe, so the recommendations account for what breaks at three in the morning in a region you are not sitting in.
What you get
A workload inventory with real dependencies
What you actually run, what talks to what, and which shared databases and undocumented integrations are going to dictate the order. Teams skip this step, and it is the one that decides whether the plan holds.
A treatment decision per workload
Rehost, replatform, re-architect, replace, or leave alone. Chosen per workload against its business value and how much life it has left, with the reasoning recorded. That includes the workloads whose honest answer is that moving them buys you nothing.
Target architecture
Account and network topology, identity and access boundaries, data residency, and the failure domains you are signing up for. Multi-region only where something requires it, because it is not free and most workloads don’t need it.
A sequenced move plan
The order, the cutover approach for each step, what runs in both places during the overlap, and the rollback for every move. A migration step you can’t reverse is a step you shouldn’t take on a Friday.
A cost model with its assumptions showing
Modelled against your real workload shapes, with data transfer, cross-availability-zone traffic and idle non-production environments broken out separately. Those three lines cause most of the surprises, and generic estimates leave them out.
Where migrations go wrong
The failure patterns repeat often enough to name:
- Lift and shift everything. You arrive with the same architecture and a bigger bill, a year later, and the case for the next investment is now much harder to make.
- Re-architect everything. Nothing ships for four quarters, the sponsor changes, and the half-migrated estate becomes permanent.
- The shared database found late. One database turns out to back four systems, nothing can move independently, and the sequence collapses.
- No rollback. A cutover with no way back turns an ordinary bad night into an incident with a board-level postmortem.
- Non-production forgotten. Dev and staging get moved last, run permanently, and quietly become a serious share of the monthly bill.
What I won’t do
I am not a delivery partner. I design the migration and stay available while it runs; your team or your chosen integrator executes it. That split is on purpose. The calls that decide whether a migration succeeds get made before anything moves, and an advisor who is also billing for the execution has a reason to move more than you need.
This also isn’t an AWS sales conversation. Where a workload has no business case for moving, that goes in the report.
Common questions
Do you run the migration, or design it?
I design it and stay available while it runs. Your team or your delivery partner executes. That split is on purpose: the calls that decide whether a migration succeeds get made before anything moves, and an advisor who is also billing for the execution has a reason to move more than you need.
Should we lift and shift, or re-architect?
Usually both, per workload, in a particular order. Lift everything and you get a pricier version of your data centre. Re-architect everything and nothing ships for a year. The useful answer is which specific workloads earn the re-architecture, and that is what the assessment gives you.
Can you tell us what it will cost to run on AWS?
A modelled estimate against your real workload shapes, with the assumptions written out so you can push back on them. Cloud bills usually surprise people on data transfer, cross-AZ chatter and idle non-production environments rather than on compute, so those get modelled explicitly.
What if we’re moving off on-premises SQL Server?
Common, and well-trodden. The real questions are whether you stay on SQL Server at all, what cutover window the business can genuinely give you, and how you prove the data matches before you commit. Data is where migrations get dangerous, so it gets the most attention.
Do we have to move everything?
No. A plan that assumes you must is usually a plan that hasn’t looked closely. Some workloads have no business case for moving, and that goes in the report.
What are your AWS credentials?
AWS Certified Solutions Architect Professional, scored 911 out of 1000 against a 750 pass mark, held 2020 to 2023. More relevant day to day: I lead architecture for a multi-region platform running production workloads on AWS across Asia and Europe.
Related services
Start with an assessment
Engagements are quoted as fixed scope against defined deliverables, after a short discovery call. I take on one or two new consulting engagements per quarter alongside my ongoing work, so lead times vary. Worth asking early.
Get in touch, or read more about my background.