Cloud Design and Migration
Built so the next system costs less than this one did.
Most cloud projects pay for the foundation twice
The first system goes up, and with it a network, a secrets store, logging, monitoring and a set of access rules. Then the second system arrives and, because nobody designed the first one to be shared, most of that gets built again slightly differently. Do it a third time and you have an estate nobody can hold in their head.
The alternative is to treat the foundation as the deliverable. Build the shared parts once, in your own network, and let each system after it bring only what is genuinely its own. It costs a little more the first time and considerably less every time after that.
The foundation is defined as code, which is its own discipline, and watched once it is live through security and monitoring.
Four ways we get brought in
Two are about building, and two are about what is already there.
A first system going to the cloud
Where the foundation gets decided whether anyone means it to. Deliberate now is the cheapest it gets.
Moving something that already runs
Staged, with old and new alongside each other and a way back at every step. Data validated at each stage.
Connecting cloud to what stays
The database, the file share, the system going nowhere. Reaching it safely is a design job.
An estate that grew sideways
Several systems, several patterns, nobody sure what runs or what it costs. We work out what is there.
What the design actually settles
What is shared, and what is not
Secrets, logs, monitoring and network belong to the estate and get built once. Compute and identity belong to a system and come with it. That single split is what stops the third project rebuilding the first.
How it reaches your building
Where the cloud sits relative to the systems you are keeping, which way traffic flows, and what happens to the link when it drops. Chosen up front, because retrofitting it is expensive.
What production does differently
Production and staging should not be the same shape. Public access, firewalling and how long logs are kept are deliberate differences, so testing stays easy without production being casual.
What lands on your desk
- A design document
- Covering the network, the shared services and the access model, with the reasoning kept beside each decision.
- The foundation itself, defined as code
- So the second environment is one run of the same definition.
- A staged migration plan
- Where there is something to move, each stage with its own way back.
- A sizing recommendation
- Based on measured load, with the figures that justify it. And once real usage exists,.
- a post-migration review
- That tunes workloads to the platform's own features for performance, resilience and running cost.
A foundation built for the second system, not just the first
On a recent Azure build for a national operator, the landing zone was designed to carry a series of integrations rather than the one we had been asked for. The shared layer - network, secrets, logging and monitoring - is built once per environment, and each new integration adds only its own compute and identity. It runs inside the client's own network rather than beside it, in the region their existing on-premise link lands in, so the service reads and writes the systems still in their building. Production carries a web application firewall and the application has no public address at all; staging is deliberately reachable so it can be tested. No credentials sit in the application, and the sizing came straight from the load test.
Common questions
What is a landing zone, in plain English?
The foundation everything else gets built on: the network it sits in, where secrets are kept, where logs and alerts go, and who is allowed to do what. Get it right once and every system after it inherits the work. Get it wrong and every system after it inherits that instead.
Do we have to move everything?
No, and the honest answer is often that some things should stay where they are. A system nobody is changing, running fine on hardware already paid for, is rarely improved by moving it. We would rather tell you that than bill for the move.
Can something in the cloud still reach our on-premise systems?
Yes, and in practice it usually has to. Most useful systems need the database or file share that is still in your building. That connection is a design decision with real consequences for latency, security and failure behaviour, so we settle it up front, including what happens the day the link drops.
How do you avoid a big-bang cutover?
By not having one. Work moves in stages, with the old and new running alongside each other while the new one is proven, and a way back at each step. The interesting question is never how to switch over, it is what you do at 4pm when it has not gone to plan.
Does this lock us into one cloud provider?
Some of it, unavoidably, and anyone claiming otherwise is selling something. What we can do is keep the lock-in where it pays, in managed services that save real money and effort, and out of the parts where it buys nothing.