Landing zone design
A multi-account structure with baseline networking, logging, backup and identity wired in from the start, delivered as code so every new account looks the same as the first.
Infrastructure & Cloud
Cloud Architecture & Migration
Moving workloads to the cloud without moving your risk profile.
The work
What this actually does
Migration is a sequence of small decisions, not a single cutover. We start with a written assessment of what you run today: dependencies, traffic patterns, data volumes, licensing and the handful of systems nobody wants to touch. The output is a landing zone design and a migration order that puts the easy, high-value workloads first.
Account structure, network topology and identity get designed before anything moves, because retrofitting them afterwards is what turns a migration into a two-year programme. Each workload is then placed on the path that fits it: lift-and-shift where speed wins, replatform where a managed service removes real operational load, re-architect only where the business case holds.
If any of these sound familiar
- The migration plan is a spreadsheet nobody has updated since last year
- Costs after go-live are double the estimate that justified the move
- Security review blocks the cutover because IAM was designed last
- Two business-critical systems have no owner and no documentation
Scope
What's included
Every engagement on this page covers the following, sized to your setup rather than delivered as a fixed package. If something here is not relevant to you, it comes off the scope and off the price.
Workload assessment
Every application scored on dependencies, criticality, data sensitivity and change frequency, which produces the migration order and the business case for each path rather than a generic lift-and-shift mandate.
Connectivity and identity
Hybrid links, DNS, firewall rules and federated access built and tested before the first production workload lands, so cutover night is not also network troubleshooting night.
Data migration planning
Replication, cutover windows and rollback for the databases, including a rehearsal against a full-size copy so you know the real duration before the real night.
Cost and sizing model
A forecast built from your own utilisation data, with the commitments, storage tiers and egress charges that usually get missed, plus a comparison against staying where you are.
Cutover and validation
A runbook with named owners, go and no-go checks, and a rollback that has been rehearsed on a copy of the workload, not written on the night.
What changes
What teams typically see
3 wavesTypical migration sequence
1 baselineLanding zone for all accounts
0Workloads without an owner
Handover
What you keep
Everything produced during the engagement is yours: the repositories, the accounts, the documentation. There is no proprietary layer and nothing to unlicense if you take the work in-house.
- Written assessment covering every application, dependency and owner
- Landing zone defined as reviewed infrastructure code
- Migration wave plan with sequencing and go-live windows
- Cost model comparing migration options against staying put
- Cutover runbooks with rollback steps and named owners
Tooling
Tools we use here
A starting point, not a requirement. We work in whatever you already run wherever it does the job.
AWS
Microsoft Azure
Google Cloud
Terraform
Kubernetes
PostgreSQL
HashiCorp Vault
How it runs
From first call to handover
The same four steps on every engagement. You see each one before it starts and can stop at any of them.
- 01
Assess the estate
Two to four weeks of read-only discovery covering applications, data flows, licences and the informal knowledge held by whoever runs each system today.
- 02
Design the landing zone
Accounts, network, identity, logging and guardrails agreed with your security team and built as code, because a landing zone designed after the first workload never quite fits.
- 03
Pilot one workload
We migrate a single representative application end to end, which exposes the real gaps in tooling, access and runbooks while the blast radius is still small.
- 04
Migrate in waves
Workloads move in batches with rehearsed cutovers and a rollback available at every step, and each wave ends with the previous footprint trimmed or switched off.
Questions
Asked before we start
Will this cost more than we run today?
Not automatically. Lifting a badly-sized estate unchanged often costs the same or slightly more once egress and support are counted. The savings usually come from the second pass: rightsizing, commitments and removing the machines nobody uses.
Do we have to re-architect to get any benefit?
No, and we will say so if the business case is thin. Most workloads gain enough from a clean landing zone and managed databases. Re-architecting into microservices is a separate project with its own costs and should not be smuggled into a migration.
How do you handle the systems nobody understands?
Carefully and late. We document what can be discovered from traffic and configuration, then migrate them with a longer rollback window, or recommend that they stay put until the team that built them is available.
Can you work with our existing cloud footprint?
Yes. Brownfield landing zones are the common case. We will adopt or refactor what exists rather than demanding a greenfield rebuild, and we will flag the decisions that are expensive to reverse if you keep them.
Infrastructure & Cloud
Often needed alongside this
Infrastructure & Cloud
Infrastructure as Code
Your entire cloud estate described in version control — reviewable, reproducible and rebuildable from scratch.
- Terraform, OpenTofu, Pulumi & CloudFormation
- Remote state, workspaces and modular reusability
- Drift detection and policy-checked pull requests
Infrastructure & Cloud
Multi-Cloud & Hybrid Strategy
A deliberate, costed answer to multi-cloud — or a clear recommendation that you don't need it.
- Workload placement and portability assessments
- Cross-cloud networking and identity
- On-prem to cloud connectivity and hybrid patterns
Infrastructure & Cloud
Legacy Application Modernisation
Incrementally untangle the monolith and the hand-built VM estate — without a risky big-bang rewrite.
- Strangler-fig migration sequencing
- Containerising and replatforming legacy apps
- Decommissioning plan for the old footprint
Worth a conversation about Cloud Architecture & Migration?
Bring the specific problem. We will tell you honestly whether this is the service that fixes it, and what it would take.