Sovereign Cloud Migration Timeline: What Is Realistic and What Disruption to Expect

A realistic sovereign cloud migration for a mid-sized enterprise takes six to eighteen months. Under six months almost always means the hard workloads were quietly left out. Over eighteen usually means nobody committed to a target architecture. The disruption the business will notice is mostly not downtime. It is slower feature delivery from the teams whose systems are in flight, a period of paying two providers at once, and a run of change freezes around cutovers. Downtime itself, done properly, is minutes to a few hours per workload inside planned windows, and close to zero for anything stateless.

This article expands the timeline section of our EU sovereign cloud migration guide into something you can put in front of a board. It assumes you have scored readiness and sorted workloads into waves; if not, see how to assess workload readiness and which workloads to migrate first.

What is a realistic timeline?

Three phases, and the month numbers below are for a mid-sized enterprise with a few dozen workloads and one or two engineering teams on the migration alongside their day jobs. Bigger estates stretch phase two and three; smaller ones compress phase one.

Months one and two: audit, selection, contract

Month one is the inventory. Pull the billing export, classify data, map dependencies, score readiness. Dependency mapping is where the surprises live and it always takes longer than the plan says, because every estate has a queue or a cron job that nobody remembers wiring up.

Month two is provider selection and contracting. Shortlist against the workload mix (the provider comparison is the place to start), run a small proof of concept on the landing zone, and start the commercial process. Procurement time varies a lot by provider. The enterprise-formal providers have longer cycles, and if BSI C5 is a requirement, that is the price of the credential. Start the paperwork before the engineers finish the proof of concept, not after.

Months three to nine: landing zone and first waves

Months three and four are the landing zone: networking, identity federation, secrets management, logging and metrics, CI/CD runners, and whatever policy tooling your compliance team needs to see. Nothing customer-facing moves yet. A pilot workload that nobody will miss goes live at the end of this period so the team learns the provider on something safe.

Months five to nine are wave one: the workloads that were urgent and ready on day one. By the end of this phase you should have production traffic on EU infrastructure, a compliance win you can show a client, and a clear view of where the friction with the new provider actually is. Remediation work on the urgent-but-not-ready workloads runs in parallel the whole time.

Months ten to eighteen: regulated and critical workloads, then decommission

This is the harder half. The workloads that needed re-architecture come out of the remediation lane and move. Data-heavy systems get rehearsed cutovers. Hyperscaler services get switched off one by one, commitments run down, and the final audit evidence gets assembled. A multi-cloud posture during this phase, with sensitive workloads on the EU provider and the rest still on the hyperscaler, is normal and is what we see working in practice. The thing to avoid is letting the bridge become the destination.

What disruption should you expect?

Four kinds, in rough order of how much the business will feel them.

Engineering capacity

This is the real cost and the one most plans leave out. A team whose service is in flight is not shipping features at its normal rate. Some of its time goes to the migration itself, some to the change freeze around the cutover, and some to the inevitable week of chasing a networking difference on the new provider. Put a number on it per team per wave, put it in the roadmap, and tell product management before they find out. A migration that pretends to be free of velocity cost is the one that gets cancelled in month eight when a feature deadline is missed.

Dual-running cost

For the length of phase two and most of phase three, you are paying two providers. The overlap is unavoidable because you cannot cut over without the target running first, and you should not switch the source off until the rollback window has passed. Three things make it worse than it needs to be: reserved instances and savings plans on the hyperscaler that run past the cutover date, marketplace subscriptions billed through the hyperscaler that need to be re-contracted, and egress fees on the way out. The EU Data Act is phasing out switching charges, but the full withdrawal does not land until 2027, so a 2026 cutover may still pay them. Finance should see the overlap curve before the programme starts, not as a surprise in the quarterly review.

Downtime and cutover windows

Stateless services cut over with traffic shifting and DNS changes and the user sees nothing. The cutover windows live in the databases. A database moved by replication, with the target kept in sync and a final switch when lag hits zero, needs minutes. A database moved by dump and restore needs however long the restore takes, and for anything large that is a maintenance window the business has to approve. Object storage of any size is a background sync over days with a short final delta. Rehearse every stateful cutover at least once on production-sized data. The rehearsal is where you learn that the restore takes nine hours rather than two, and you would much rather learn it on a Tuesday afternoon than at the cutover.

Organisational friction

New console, new IAM model, new support process, new invoices. Engineers retrain, and the first month on any new provider is slower. Procurement and legal get a new vendor to manage. Auditors ask for evidence that the data really is where you say it is, and the evidence has to be generated rather than asserted. Clients whose contracts mention residency need telling, and this is the one piece of disruption that is actually good news: the migration is a selling point, and the account team should treat it as one.

What makes timelines slip

Undiscovered dependencies. The dependency map from month one was incomplete, and a wave stalls on a service nobody listed.

Re-architecture estimated as lift-and-shift. The serverless ETL pipeline turned out to be a rewrite, and it was scheduled as a week.

Skipped rehearsals. The first attempt at the big database cutover was the real one, and it ran long.

Shared services left until later. Nothing can land because identity and secrets are still on the hyperscaler.

Waiting for the perfect target architecture. Six months of design, zero workloads moved, sponsorship gone.

Provider procurement. The engineers were ready in month three; the contract was signed in month five.

Descoping the hard parts and calling it done. The regulated workloads are still on AWS and the programme has been declared a success. This is how you get a migration that has to be done twice.

How to keep the disruption low

Move stateless things first and stateful things last within every wave, so the team has fluency before it touches a database. Keep change freezes short and announce them weeks ahead rather than days. Keep the hyperscaler environment as a rollback for a defined window after each cutover, a week or two, and then switch it off on schedule rather than leaving it running out of nervousness. Re-score readiness before each wave so the plan reflects what remediation has actually landed. And report the velocity cost honestly every month, because the board will tolerate a known cost far longer than a surprise.

The one piece of advice we give every CTO at the start: pick the end date for the multi-cloud bridge on day one. Dual running is fine for a year. Dual running with no end date becomes the architecture, and you end up paying for two of everything while still being exposed on the half that never moved.

How Looming Tech can help

Looming Tech plans and delivers sovereign cloud migrations for UK and EU enterprises end to end: readiness assessment, wave planning, landing zone, cutovers, and the decommissioning at the end that most programmes never quite finish. We are a registered partner with OVHcloud, STACKIT, Scaleway, and T Cloud Public, and we work alongside your engineering team rather than around it. If you need a timeline you can defend in front of a board, with the disruption costed rather than hidden, we are happy to have a no-commitment conversation.

Talk to our team →