Moving a regulated enterprise to the cloud without breaking it

A migration goes wrong quietly. Nobody watches a lift-and-shift fall over in real time. It fails weeks later, when an untested dependency, a forgotten firewall rule, or a compliance gap surfaces in production and someone senior asks why. I spent these years making sure that call never had to be made.

From roughly 2016 to 2021 my work moved from building the physical layer to moving whole enterprises off it. Hybrid and public cloud landing-zone design, and the mass migration of multi-environment, multi-stack platforms out of self-hosted data centres and into the public cloud, for the financial sector, where the regulator is a stakeholder in every decision.

The landing zone comes before the workload

The instinct people have is to start migrating applications. That is the mistake. You build the landing zone first: the account and subscription structure, the network topology, the identity model, and the guardrails, all in place before a single workload arrives. Get that foundation wrong and every migration after it inherits the flaw.

I designed these on the established frameworks rather than inventing my own. The Cloud Adoption Framework for the shape of the estate, Well-Architected for the workloads inside it, and a hub-and-spoke topology so shared services and connectivity lived in one governed place while each business unit got its own spoke. Everything as code. Terraform for the whole estate, so the landing zone was a reviewable, repeatable artefact rather than a set of console clicks nobody could reproduce.

The 6 Rs are a conversation, not a checklist

Not every application should move the same way, and pretending otherwise is how programs blow their budgets. For each platform we worked the 6 Rs honestly: rehost the ones that just needed to move, replatform the ones that could shed some operational weight on the way, refactor the few worth rebuilding, repurchase where a SaaS product already did the job, and retain or retire the rest. Lift-and-shift has its place. So does the courage to say an application should not move at all.

I did this as principal and technical lead across several large cloud-adoption programs, the multi-million-dollar kind, coordinating many teams through scrum-of-scrums so the blueprint stayed coherent while dozens of people delivered against it.

In a regulated shop, governance is the product

For a bank, the architecture is only acceptable if it is demonstrably safe. So the guardrails were not decoration. Preventive and detective controls in code. A zero-trust posture rather than a trusted network edge. And compliance built in from the start against APRA CPS 234 and ISO 27001, so that when the regulator asked how a control was enforced, the answer was a policy in the pipeline, not a paragraph in a document.

FinOps sat alongside it, because moving to the cloud without cost discipline just relocates the waste. And the whole thing was framed in enterprise-architecture terms, TOGAF and Zachman, so the technical roadmap tied back to what the business was actually trying to do.

What carried forward

This is the chapter where the engineer learned to run a program. The hazardous-area sites taught me how compute behaves. The mine farms taught me power and thermal at density. These years taught me how to move something enormous and regulated without the quiet failure, how to translate commercial intent into a roadmap, and how to surface risk early enough that nobody ever had to make that phone call. All of it is exactly what you need when the next thing to land safely is an AI factory.