To the cloud, workload by workload, eyes open.
Assessment-led migration — rehost, replatform or refactor decided per workload, executed with rehearsals, rollback plans and a cost model you approved first.
- Assess & model
- Landing zone
- Waves
- Optimise
The cost model comes before the migration.
Cloud migrations fail two ways: lift-and-shift everything and inherit your old problems at a higher price, or refactor everything and never finish. Both start from the same mistake — treating the estate as one decision. A payroll system that runs twice a month and a customer-facing API that must not blink are not the same problem, and giving them the same disposition guarantees that one of them is wrong.
We treat each workload on its merits — the seven Rs applied with a spreadsheet, not a slogan. Every application is scored on dependencies, data gravity, licensing, compliance constraints and how much value a change would actually return, and each one gets a disposition you can argue with: rehost, replatform, refactor, repurchase, relocate, retain or retire. Retire is an under-used answer in this business, and finding the workloads nobody depends on any more can be a real saving in the programme.
You’ll know the projected monthly bill — and the assumptions behind it — before anything moves, so the business case survives contact with the invoice rather than being rewritten around it.
Four disciplines the programme runs on.
The order matters. An assessment without a landing zone produces a plan with nowhere to land; a landing zone without FinOps produces a governable estate that still costs more than the data centre it replaced.
Portfolio assessment
Every workload scored: dependencies, data gravity, compliance constraints, and the right R — rehost, replatform, refactor, retire. Discovery combines what the CMDB says with what the network and runtime actually show, because the two rarely agree. The output is a dependency-ordered wave plan with a named disposition per application and the reasoning attached, so a decision can be challenged on its merits later.
Landing-zone engineering
Accounts, networking, identity and guardrails as code — the foundation that keeps the estate governable after the move. Organisation structure, subscription or account boundaries, private connectivity, logging and policy are Terraform from the first commit. Residency, encryption and tagging are enforced on the plan, so the controls your auditors ask about are properties of the platform rather than a follow-up project.
Rehearsed cutovers
Every migration wave rehearsed against production-shaped data, with rollback tested — not just written down. The rehearsal produces the runbook, the timings and the go/no-go criteria, and it is repeated until the timings are stable. Nothing moves on a weekend where the plan has not already been executed end to end at least once, including the part where it goes wrong.
FinOps from the start
Budgets, tagging discipline and rightsizing baked into the landing zone, so the bill is a design output, not a surprise. Every resource carries an owner and a cost centre because the policy will not let it exist otherwise. Commitment and reserved-capacity planning waits until the estate has run long enough to show its real shape — buying discounts on the wrong sizes is a common and expensive way to lock in a mistake.
How the work runs, day to day.
A disposition per workload, with the reasoning attached.
The assessment is where the programme is won or lost. We inventory what is running rather than what is documented, map dependencies from network and runtime evidence, and score each workload on data gravity, licensing, regulatory constraint, change appetite and the return a replatform would actually produce. Then every application gets one of the seven Rs and a line explaining why. Retire and retain are real answers: an estate usually contains applications that can be switched off and some that should stay where they are until a business decision elsewhere is made. The result is a wave plan ordered by dependency, not by whichever team volunteered first.
- Inventory from runtime and network evidence, reconciled against the CMDB rather than trusting it
- Data gravity assessed explicitly — where the data lives usually decides where the workload goes
- Licensing and support terms checked before a disposition is fixed, not after the move
- Every disposition carries its reasoning, so it can be revisited when a constraint changes
A landing zone your team can keep governing.
Estates often become ungovernable early, when speed matters more than structure and everyone gets an account. The landing zone prevents it by making the structure code: organisation and account boundaries, network topology and private connectivity, identity federated to your directory, centralised logging, and policy that refuses a resource which breaks a rule. Environments are then created by a pipeline run rather than a ticket. Because the whole thing is Terraform, adding a region, splitting a business unit or rebuilding from scratch is a reviewable change instead of an archaeology project. The same foundation is what our DevOps & Cloud engagements build delivery on top of.
- Account and subscription structure with guardrails inherited, not copied per team
- Identity federated to your directory with least-privilege roles as code
- Region pinning, encryption and tagging enforced on every plan for GDPR / KVKK obligations
- Centralised logging and cost data from the first environment, not retrofitted later
Waves, rehearsals, and a rollback that has been used.
Workloads move in dependency-ordered waves, and every wave is rehearsed before it is real. The rehearsal runs against production-shaped data, produces the actual timings, and exercises the rollback — because a rollback plan that has never been executed is a paragraph, not a plan. Databases move with replication and a parallel-run validation window, so the cutover is a controlled switch rather than a weekend of hope. Each wave ends with validation evidence: the checks that were run, what they returned, and who signed.
- Dependency-ordered waves — nothing moves before the systems it talks to are ready or bridged
- Rehearsal against production-shaped data, repeated until the timings stop changing
- Database moves with replication and a parallel-run comparison before the switch
- Go/no-go criteria agreed in advance, and a rollback that has been executed at least once
The bill you approved, then the bill you improve.
A migration business case that ends at cutover is half a business case. Before anything moves, we build a cost model per workload — compute shape, storage tier, egress, licensing, support — with the assumptions written down so they can be checked against reality. After each wave the model is compared with the actual invoice and the difference is explained rather than absorbed. Then the optimisation phase does the unglamorous work: rightsizing against measured utilisation, storage lifecycle rules, non-production environments that switch off outside working hours, and commitment planning once the shape is stable.
- Per-workload cost model with named assumptions, approved before movement
- Model versus invoice reconciled after every wave, with variance explained
- Rightsizing and storage lifecycle after real utilisation exists, not before
- Reserved and committed capacity planned last, when the estate has stopped moving
What each side of the table gets.
The estate arrives as code you can read.
Your platform engineers are in the programme from the assessment, not handed a finished environment at the end. The landing zone, the wave runbooks and the rehearsal timings are written with them, in the repository they will keep working in. Enablement is scheduled work in the plan, not an afterthought in the final week.
- Terraform modules and runbooks from the first commit
- Pairing through rehearsals so the cutover is not the first time your team sees it
- Environment creation by pipeline, not by ticket
One wave at a time, with a date that holds.
Application owners get a disposition they can challenge, a rehearsal date, a validation checklist and a rollback window. Nothing moves without the owner signing the go/no-go. Where a workload is being replatformed rather than rehosted, the change is scoped as its own piece of work with its own tests, so migration risk and change risk are never mixed into one weekend.
- Validation checklist per application, agreed before the rehearsal
- Rollback window after cutover, with the old path kept warm
- Replatform work scoped separately from the move itself
Residency and access decided in the design.
Data-residency obligations under GDPR and KVKK are handled where they belong — in the landing-zone design, as region pinning, encryption and access control that a plan will refuse to violate. Every wave leaves validation evidence, and every infrastructure change leaves a commit, a reviewer and a policy result. We document our controls against ISO 27001, and where the estate needs deeper assurance we bring in Cybersecurity.
- Region pinning and encryption enforced by policy, documented for your auditors
- Least-privilege access federated to your directory, defined as code
- Validation evidence retained per wave, with named approvers
A number before the move, and a variance after it.
Finance sees the cost model before movement, the assumptions behind it, and a reconciliation after every wave. Tagging is enforced at plan time, so spend is attributable to a team, a product and an environment without a mapping exercise. Commitment purchases are deliberately deferred until the estate has stopped changing shape, which is the difference between a discount and a lock-in.
- Cost model per workload with named assumptions
- Spend attributed by enforced tags, not by a monthly reconstruction
- Commitments planned after the estate is stable
What every programme includes, and what depends on your estate.
Four phases, repeated per wave.
Assess & model
Inventory, dependency map, per-workload disposition and the cost model — signed off before movement. Discovery uses runtime and network evidence rather than trusting the CMDB, and each application leaves the phase with one of the seven Rs and the reasoning behind it. The wave plan is ordered by dependency, and the business case is a document you can defend rather than a range.
Landing zone
Secure, compliant foundation as code: identity, networking, guardrails, logging. Account structure, private connectivity, policy, central logging and cost tagging land as Terraform. The first workload account is created by the pipeline, which proves the foundation before anything depends on it.
Waves
Workloads move in dependency-ordered waves — rehearsal, cutover, validation, then the next wave. Each rehearsal runs against production-shaped data and exercises the rollback until the timings stop changing. Databases move with replication and a parallel-run comparison, and every cutover ends with signed validation evidence and a rollback window that stays open.
Optimise
Post-move rightsizing, reserved-capacity planning, and the replatform backlog for the workloads that earn it. Utilisation data now exists, so sizing decisions are measured rather than assumed. The phase also closes the programme out: the old estate is decommissioned deliberately, and the replatform candidates are ranked by return rather than by enthusiasm.
What is in your hands at the end.
- Assessment report with per-workload disposition and cost model
- Landing zone as Terraform code
- Migrated workloads with validation evidence per wave
- Rollback plans — tested, not theoretical
- Post-migration optimisation report and FinOps dashboard
- Wave runbooks with rehearsed timings and go/no-go criteria
- A decommissioning plan for the estate you are leaving behind
When this is the right call.
Choose this when a data-centre contract, a hardware refresh or an end-of-support date is forcing a decision and you want it made per workload rather than in one sweep. Choose it when a previous migration stalled and left half the estate in each place, when the cloud bill is already growing without anyone owning it, or when residency obligations mean the design has to be defensible to a regulator. It sits naturally before DevOps & Cloud, which turns the new estate into a delivery capability, and alongside Software Modernisation when some of the workloads deserve more than a move.
It is the wrong call when the real problem is the application rather than the infrastructure. A system that cannot be changed safely will not become changeable by running somewhere else; that is Legacy Re-engineering work, and moving it first can make it harder. It is also the wrong call when the organisation wants a date before an assessment. We will not commit to a cutover schedule for an estate nobody has inventoried, because the waves that go badly are usually the ones with a dependency that was not on the map.
Frequently asked questions
Where this service usually sits.
Tell us what you’re building.
Describe what exists today and what you need. An engineer reads it and replies in writing with how we would approach it, and the model that fits.