Move the platform without moving the problems.
Lifting a badly behaved system into the cloud gives you the same system with a monthly bill attached. We model what each workload will actually cost and behave like first, then move it in a sequence that keeps the business running throughout.
Cloud is not automatically cheaper. It is automatically more flexible.
The migrations that disappoint are the ones sold on cost. Move a system that runs at ten percent utilisation on hardware you already own, and a cloud bill will often be higher, because you are now paying rent on capacity you previously paid for once.
What the cloud reliably buys is elasticity, resilience and speed of change — the ability to add an environment in an afternoon instead of a quarter, to survive a failed data centre, and to scale for a peak without buying for it permanently.
Cost savings do happen, but they come from re-architecting how a workload runs, not from relocating it. Right-sizing, scheduling non-production environments off overnight, moving cold data to cheaper storage and replacing always-on servers with managed services is where the money is.
We model both numbers before you commit: what it costs if you simply move it, and what it costs if you also change it. Then you decide which workloads justify the second.
In waves, lowest risk first.
Nothing about a migration requires a single cutover date, and almost every programme that sets one regrets it. Workloads move in waves, sequenced so the least risky go first and each wave teaches you something before the next one starts.
That sequencing is most of the value of the assessment. Dependencies decide the order, not the org chart, and the workload everyone wants moved first is frequently the one that should move last.
Some things do not move at all, and saying so early is part of the job. A licence server priced punitively in the cloud, a workload with a genuine latency requirement, or a system due for retirement in eighteen months are all better left where they are.
Hybrid is a legitimate end state for a large enterprise rather than a sign the programme ran out of momentum. What matters is that the split is deliberate.
Four routes, chosen per workload.
A migration programme is not one decision. It is one decision per workload, and getting that mix right is most of the value of the assessment.
| Route | When it fits | Trade-off |
|---|---|---|
| Rehost (lift & shift) | A stable system that needs to leave the data centre on a deadline. | Fastest and lowest risk, but inherits every inefficiency it already had. |
| Replatform | The application is fine but the database, runtime or web tier should be managed. | Moderate effort, and most of the operational burden disappears with it. |
| Refactor | The workload is central, changes often, or its costs scale badly. | The most work and the largest return — justified for a minority of workloads. |
| Retire or replace | Nobody has used it in a year, or a SaaS product now does the job properly. | The cheapest possible migration. Most inventories contain more of these than expected. |
Mainframe and on-premise platform transformation.
Mainframe workloads are usually the last thing left, for good reasons: they are reliable, they process enormous volumes correctly, and the consequences of getting a migration wrong are severe. The pressure to move them is rarely technical — it is the shrinking pool of people who can maintain them.
We treat these as comprehension projects before they are migration projects. COBOL and job-control logic are read and documented first, business rules are extracted and confirmed, and only then is a target architecture designed. Nothing moves until the behaviour is written down and agreed.
- COBOL and JCL comprehension — AI-assisted reading of programs and job schedules into documented behaviour.
- Business rule extraction — separating genuine policy from decades of accumulated technical workaround.
- Data migration and reconciliation — moving records with a field-level proof that nothing changed in transit.
- Batch to event-driven redesign — where overnight windows have become a constraint on the business.
- Parallel running — both platforms processing the same work until the outputs match consistently.
- Phased decommissioning — retiring workloads individually, not attempting a single cutover date.
Six things that stop a cloud bill surprising you.
The classic pattern is a migration that lands on budget and an operating cost that doubles over the following year. These are the controls that prevent it.
Landing zone before workloads
Accounts, networking, identity and tagging standards are built first. Retrofitting governance across a hundred deployed resources is far more expensive.
Everything tagged to an owner
Every resource carries an owner, environment and cost centre, so spend can be attributed, not argued about.
Budgets and alerts from day one
Per-environment budgets with alerting, so an unexpected cost is a notification in week one instead of a finance conversation in month four.
Non-production switched off
Development and test environments run on a schedule. This alone is frequently a double-digit percentage of the bill.
Infrastructure as code, always
Terraform for everything. A resource created by hand in a console is one nobody can reproduce, review or reliably delete.
Portability preserved deliberately
Containers and open standards where the choice is neutral, so a proprietary managed service is a decision you make rather than one you discover later.
Nothing moves before the model is agreed.
-
Weeks 1–3
Inventory the estate
Every workload, dependency, integration and licence catalogued. You get a dependency map and a candid list of what should simply be retired, usually more than anyone expects.
-
Weeks 4–5
Model the cost
Projected running cost and performance per workload on each viable route, so the decision to rehost or refactor is made with numbers, not instinct.
-
Weeks 5–8
Build the landing zone
Accounts, networking, identity, security baseline and tagging standards, all defined as code before a single workload arrives.
-
Per wave
Migrate and verify
Workloads moved in waves with parallel running where it matters, and a rollback path retained until each wave is proven.
-
Ongoing
Optimise against reality
Right-sizing and tuning once real usage is visible, with monthly cost and utilisation reporting against the original model.
Before you migrate.
The three below are the ones this page does not already answer. Anything more specific, put it to us directly.
Which cloud should we choose?
Usually the one your organisation is already able to operate. The technical differences between AWS, Azure and Google Cloud matter far less than the skills on your team, the licensing you already hold, and the compliance commitments you have made. If you are a Microsoft estate with Enterprise Agreement discounts and an identity platform already in Entra, Azure will almost certainly cost less in total than a technically marginal preference for something else. Where there is no incumbent we will model two options properly instead of assert a favourite. We hold delivery experience across all three, so we have no reason to steer you.
What about workloads that genuinely cannot move?
Then they stay, and that is a legitimate outcome instead of a failure. Data residency rules, specialised hardware, licence terms that price cloud deployment punitively, and latency requirements that only local infrastructure meets are all real constraints. Hybrid is the normal end state for large enterprises, not a transitional embarrassment. What matters is that the split is deliberate (connected properly, with one identity model and one monitoring view) rather than the accidental result of a migration that ran out of momentum.
We were quoted a fixed price for a full migration. Should we take it?
Read what the inventory phase covers before you sign anything. Fixed-price migrations are reasonable once the estate is understood, and hazardous before that — the unknowns in a legacy estate are not evenly distributed, and one undocumented integration can consume more effort than fifty straightforward servers. Our own preference is a fixed-price assessment followed by fixed-price waves, so the commitment grows as the uncertainty shrinks. If a supplier will fix the whole programme before seeing the estate, ask what happens when they find something unexpected, and get the answer in writing.