Cloud Migration & Architecture
Copying the servers is the easy part. The hard decisions are which workloads move as they are, which get rebuilt for the platform, and which should not go to the cloud at all.
The lease on the data centre runs out next spring, or the hardware refresh quote landed and somebody asked why you still buy servers. Either way a date is doing the deciding, which is how estates get moved in a hurry and end up running worse than they did on a floor you controlled. Migrations fail on the dependency nobody mapped, and on the decision to move something that should have been switched off.
The choice is made per workload, not per estate.
Lift and shift
Move the machine as it is onto a cloud instance of roughly the same size. It clears the deadline, changes nothing about the application, and can be undone.
- Nothing in the application changes, so the test surface stays small
- A lease or refresh deadline gets met without a rewrite
- You can move back if the platform turns out wrong
- Costs track the old estate, because the old sizing came too
Re-architect for the platform
Rebuild the workload around what the platform offers: managed databases, object storage, autoscaling, a queue nobody has to patch. More work up front, and a different operating model afterwards.
- Capacity follows demand, so idle hours stop appearing on the bill
- Patching and backups move to the platform, not your rota
- The application has to change, and so do the tests
- Worth choosing workload by workload, not across a whole estate
Why the bill went up, not down
A data centre's habits came across with the machines. Servers sized for a peak that arrives at year end now bill for that peak every hour. The test environment somebody spun up in March is still running. Backups that used to fill a tape library sit on the fastest storage tier the account offers, because that tier is the default.
What controls it is unglamorous. Every resource gets tagged to an owner before it moves, so the bill can be read by team instead of by line item. Instances are sized against what the machine used rather than what it was provisioned for. Put lifecycle rules on storage, stop non-production out of hours, and give one named person the monthly spend review. Cost drifts back the moment nobody is watching.
The sequence that keeps a migration boring
Every estate is a different size and every change board moves at its own pace, so there are no dates on this. The order is the part that does not vary. Each phase ends with a document or a running system you can check.
- 01Phase 1
Inventory and dependencies
We build the list of what is running and map what talks to what. The surprises live here: a licence server nobody owns, a batch job writing to a file share the diagram never mentions. You get the map, with the unknowns marked.
- 02Phase 2
Decide per workload
Each workload gets a disposition: move as it is, rebuild for the platform, replace with something you buy, or switch it off. Retiring things is the cheapest option available and it is almost always under-used. The dispositions are written down with the reasoning.
- 03Phase 3
Build the landing zone
Before anything moves, the accounts, networks, identity and guardrails it will move into. Getting this wrong is expensive to undo later, because every workload after the first inherits it. It is built as code in your repositories, and you review it before any machine lands.
- 04Phase 4
Move in waves
The first wave is chosen to matter little and exercise a lot: real dependencies, forgiving users. Later waves carry the systems people would notice if they stopped. Each wave runs with its rollback tested rather than described, and is reviewed before it closes.
- 05Phase 5
Tune and hand over
Sizing gets corrected against what the workloads do in the cloud, not what they did on hardware bought years ago. Then the handover: dashboards, alerts, runbooks and the on-call procedure, in the hands of whoever operates it, with the decision record alongside.
Platforms and the tooling around them
The platform is usually settled before we arrive, by an enterprise agreement or by where your engineers already have experience, and arguing with either rarely pays. We do hold opinions about the infrastructure code, because that is the part you are left maintaining.
- AWS
- Microsoft Azure
- Google Cloud
- Terraform
- Ansible
- Docker
- Kubernetes
- Helm
- Microsoft Entra ID
- HashiCorp Vault
- Prometheus
- Grafana
- OpenTelemetry
What we get asked
You go back. Every wave has a rollback that has been run, not written down, and the old environment stays up until the new one has held for an agreed period. The awkward part is data written after cutover, which is why the rollback plan says what happens to it and names the window in which going back is still free.
Not sure which one you need?
Describe the problem in a paragraph and we will tell you which service applies.