Build
Sovereign cloud migration
Migration with the decisions that determine the outcome made before the first workload moves — landing zone, identity, network, security baseline and cost model. Including the applications that should be retired rather than moved.
Duration
3–9 months depending on estate size
Built on
ISO/IEC 27001:2022
Indicative price
€25,000–65,000 per engagement
Who this is for
CIO or IT director
Owns a migration that has to land without stopping the business.
Infrastructure lead
Will run the estate afterwards and wants it built properly.
CFO
Has heard about cloud bills that arrived larger than the data centre they replaced.
CISO
Wants the security baseline set at the start, not retrofitted.
The migration is the easy part
Moving a workload is a solved problem. The tooling is mature and the mechanics rarely fail. What determines whether a migration is a success two years later are the decisions taken before anything moves: how the landing zone is structured, how identity works, how the network is laid out, what the security baseline is, and how cost is attributed.
Get those wrong and the migration still completes. It just produces an estate that is harder to secure, more expensive to run and awkward to change — and unpicking any of it later means touching everything built on top.
The second trap is lift and shift as a default. Moving a workload unchanged is sometimes exactly right, and it is also how organisations reproduce fifteen years of accumulated compromise at a higher unit cost. Every application deserves an explicit decision: retire, retain where it is, rehost, replatform or rebuild. In most estates there are more retirement candidates than anyone expects, and finding them is the cheapest value in the whole programme.
Cost surprises are a design failure rather than a pricing failure. Bills arrive larger than expected because nothing was tagged, nothing was right-sized, non-production ran continuously, and no one could attribute spend to a team who could act on it. All of that is decided in the landing zone.
And cutover is rehearsed, including the rollback. A migration plan without a tested way back is a plan that assumes it will not need one.
How we do it
- 01
Discovery and dependency mapping
2–4 weeks
What exists, what talks to what, and what nobody is certain is still used. Dependencies are where migrations break, and they are rarely documented accurately.
- 02
Disposition per application
2 weeks
Retire, retain, rehost, replatform or rebuild — decided per application with the business owner, not by IT alone. Retirement candidates are identified explicitly and someone signs them off.
- 03
Landing zone design and build
3–4 weeks
Subscription and account structure, identity and access model, network topology and connectivity, security baseline, logging, tagging and cost attribution. This is the foundation and it is worth the time.
- 04
Pilot migration
2–3 weeks
A small, real, representative workload. It tests the landing zone, the runbooks and the assumptions while the cost of being wrong is low.
- 05
Wave migration
ongoing
Grouped by dependency rather than by convenience. Each wave has a cutover runbook, a tested rollback, and a defined success check.
- 06
Optimise and hand over
3–4 weeks
Right-sizing, reservation and commitment decisions, operational runbooks, and handover to whoever runs it — your team, ours, or both.
Named artefacts
What you receive
- Application inventory with dependency map
- Disposition decision per application, with the business owner's sign-off
- Retirement list and the saving attached to it
- Landing zone design and the built environment
- Security baseline as configured, not as aspired to
- Cost model, tagging standard and attribution reporting
- Migration wave plan grouped by dependency
- Cutover and rollback runbooks, tested
- Post-migration optimisation report with right-sizing recommendations
What we need from you
- Application owners who can make a disposition decision. Without them, everything defaults to rehost.
- Access to the existing estate, including the systems nobody quite owns.
- A tolerance for retiring things. Every estate has candidates and every organisation finds reasons to keep them.
- Change windows agreed in advance, and someone who can approve a cutover in the moment.
What changes
- 01The estate you run afterwards is designed rather than inherited.
- 02Cost is attributable to teams who can act on it, from day one.
- 03The security baseline was set before workloads arrived, so it did not have to be retrofitted.
- 04Applications that should have died did, rather than being migrated at expense.
- 05Cutovers are rehearsed and reversible, so they can happen on a Tuesday.
What it costs
€25,000–65,000 per engagement
All prices exclude VAT.
Questions
How long does it take?
Three to nine months for most mid-sized estates, and the variable is rarely the moving. It is discovery, dependency untangling and how quickly application owners make disposition decisions.
Can we lift and shift and improve later?
Sometimes, and for some workloads it is right. But 'later' has to be a scheduled piece of work with a budget, not an intention — because a rehosted estate runs fine and therefore never reaches the top of anyone's list.
What about workloads that cannot move?
They stay, and the design accounts for them. Hybrid is a legitimate end state, not a failure. What matters is that the boundary is deliberate and the connectivity and identity model spans both sides properly.
Who runs it afterwards?
Your team, ours under Sovereign Secured Operations, or a split. We build the runbooks either way, because a handover without them is not a handover.
Leave with your top three risks documented
Thirty minutes with a senior practitioner. No slideware, no sales engineer.