Cloud & Infrastructure Modernization

Migration tooling is largely a solved problem. Replication works, cutover works, the vendors have all built competent movers. What is not solved - because it is specific to your estate - is the order in which things move, and that is what determines whether the project finishes.

The common instinct is to start with something simple to build confidence. A file server, a small internal app, something with no dependents. It migrates cleanly, everyone is encouraged, and the project has proven almost nothing: the systems that were easy were easy because nothing relies on them. The hard systems - the database everything queries, the authentication path, the middleware nobody fully understands - are still ahead, and now they are being tackled with less budget and less patience.

Sequencing by dependency inverts this. You map what talks to what, identify the foundations, and move those first even though they are uncomfortable. The early waves are harder, but every subsequent wave gets cheaper, because the things it depends on are already in the destination and already governed.

This also determines how long you spend in the hybrid state. Every workload that moves while its dependencies remain on-premises creates a traffic path back across the link - which costs money, adds latency, and creates a failure mode that did not exist in either environment alone. Minimising the time spent in that state is worth more than optimising any individual cutover.

A landing zone is the governed structure a workload arrives into: subscription and management group layout, identity integration, network topology and routing, policy guardrails, logging destinations, naming and tagging, cost boundaries. It is unglamorous and it is the difference between a cloud estate and a pile of virtual machines.

When it does not exist, every migration wave improvises. The first team picks a subnet, a naming convention and a resource group layout that make sense to them. The second team does the same, differently. Within a year you have the snowflake problem you migrated to escape, except now it is billed monthly and spread across regions.

Policy guardrails matter more than most teams expect. Preventing a public IP on a database subnet, requiring encryption at rest, blocking regions you are not permitted to store data in, mandating tags that make cost allocation possible - each is trivial to configure ahead of time and expensive to retrofit across hundreds of deployed resources.

Cost guardrails are the same story. Budgets, alerts, and lifecycle rules for orphaned disks and unattached IPs cost nothing to establish on day one. Left until the first alarming invoice, they become a cleanup project competing with the migration for the same engineers.

The most common post-migration complaint is that the bill exceeded the on-premises cost it was meant to replace. This is nearly always predictable, and nearly always caused by two things: sizing carried over verbatim, and nothing ever turning off.

On-premises sizing is a capacity-planning artefact. Servers were specified for peak load plus three years of growth plus a safety margin, because adding capacity later meant a purchase order and a change window. Lifting those specifications directly into the cloud means paying hourly for headroom that was only ever there because provisioning was slow. Right-sizing against actual observed utilisation typically recovers a substantial share of the overspend on its own.

The second cause is that cloud resources have no natural end. A physical server that is no longer needed sits in a rack and is eventually noticed. A virtual machine, a managed disk, a load balancer, a snapshot from a migration wave two years ago - none of them are visible unless something looks for them. Lifecycle policies and regular orphan sweeps are cheap and recover real money.

Beyond that: reserved capacity or savings plans for the genuinely steady workloads, autoscaling for the ones with real variance, and scheduled shutdown for non-production environments that nobody uses at 9pm. None of this is exotic. It is simply work that has to be someone's job, which is why we hand it over as a documented practice rather than a one-off cleanup.

For most workloads, migration without user-visible downtime is achievable through replication and staged cutover: the destination is kept synchronised while the source stays live, traffic is switched, and the source is retained as a fallback until confidence is established.

Some systems genuinely cannot do this. Applications with hard-coded hostnames, licensing tied to hardware identifiers, databases whose replication cannot span the link within the available window. Those need a maintenance window, and the honest thing is to identify them during assessment and negotiate the window early - rather than discovering it at 11pm on cutover night with the business waiting.

Every wave we run has a tested rollback and a defined success measure agreed before it starts. The rollback matters because the decision to abort has to be a routine one; if reverting is uncertain, teams push forward through problems they should have backed out of. The success measure matters because without it, cutover completion gets declared on the basis that nothing has visibly broken yet.

We hand the environment over as infrastructure as code. Not because it is fashionable, but because a cloud estate that can only be reproduced by remembering what someone clicked is the same fragility you migrated to escape - and it is the thing that makes the next disaster recovery test either a routine exercise or a crisis.