Which Workloads Should You Migrate to Sovereign Cloud First? A Prioritisation Method

Migrate first the workloads that are both urgent and ready: the ones a regulator, a client contract, or the EU AI Act is already asking about, and that you can move without a rewrite. Urgent workloads that are not ready go into a remediation lane, not a migration wave. Ready workloads that nobody is asking about make good pilots. Workloads that are neither can wait, and some of them should never move at all.

That is the whole method. The rest of this article is how to apply it without fooling yourself. It assumes you have already scored readiness per workload; if not, start with how to assess which workloads are ready for sovereign cloud migration. For the legal background on why any of this is necessary, see why your AWS EU region is not GDPR-safe.

The two axes: urgency and readiness

Every prioritisation argument we have sat through in the last year came down to someone scoring one axis and assuming the other. Legal scores urgency and assumes everything is equally movable. Engineering scores readiness and assumes everything is equally important. Put both on the table and most of the argument evaporates.

Urgency

Urgency is how much it costs to leave the workload where it is for another year. Three kinds of workload score high, and they are the same three we name in the pillar guide:

Regulated personal data: GDPR special categories, health records, financial transaction data, and anything a data protection authority has already asked about in the context of cross-border transfers.

Client-contractual workloads: systems where a contract specifies EU-only residency, or where a large client has started asking the questions your board is asking. These pay back fastest, because moving them turns a contractual risk into something you can put in a sales deck.

AI training and inference data: the EU AI Act is already looking at where training corpora live and how model weights are derived. Treat it as regulated even if your workload is not formally in scope yet. Unwinding it later is expensive.

Add dates. A DORA audit in Q3, a client renewal in November, a hyperscaler commitment that expires in March. Urgency without a date is a feeling; urgency with a date is a plan.

Readiness

Readiness is whether you can move the workload with known effort and known risk. It is scored on data classification, hyperscaler-native dependencies, runtime portability, data gravity, licensing, and ownership, and the scoring method is in the readiness assessment article. The important thing for prioritisation is that readiness is scored on its own, without reference to how important the workload is. If the scoring was done honestly, you now have two independent numbers per workload.

The four quadrants and what to do in each

Urgent and ready: wave one

These go first, and in most estates there are fewer of them than you would hope. A customer-facing service on Kubernetes with a Postgres database, holding regulated data, with a client contract that mentions residency: that is the ideal first production migration. It proves the landing zone, it produces a compliance win you can show, and it does not require a rewrite.

Urgent and not ready: the remediation lane

This quadrant is where sovereign cloud programmes quietly fail. The workload the regulator cares about is the one with the serverless ETL pipeline, the proprietary orchestration, and the forgotten licence. Scheduling it into wave one because it is important guarantees that wave one slips, and a slipped wave one costs you the executive sponsorship you need for wave three.

Instead, give these workloads a remediation lane that runs in parallel with wave one. The work is specific: replace the proprietary queue with one that exists on both sides, move the ETL logic into something portable, find the owner, resolve the licence. Each piece of remediation has a date, and when the readiness score crosses the line the workload graduates into wave two. Say this out loud to the board early. "The payments ledger moves in wave two, and here is the work that makes that possible" is a much better sentence than "the payments ledger is late."

Not urgent and ready: pilots and fillers

A ready workload nobody is asking about is the safest thing to move first technically, even though it is not the most important thing to move first strategically. Use one or two of these as the very first production deployments on the new provider, before wave one proper. Your team needs to learn the provider's networking model, its IAM, its observability stack, and its quirks on something where a bad week does not reach a customer.

After that, these workloads fill gaps in the schedule. When wave two is blocked on a remediation item, move one of these instead and keep the team's fluency up.

Not urgent and not ready: leave it

Non-sensitive development and test environments, ephemeral CI infrastructure, CDN and edge workloads where the hyperscaler still has a real depth advantage. None of these are reasons to spend engineering time. Some will move at the end for the sake of operational simplicity. Some will never move. That is fine. The aim is to reduce legal and contractual exposure, not to perform sovereignty as ideology.

Ordering inside a wave

The quadrant tells you which wave. Inside a wave, four things break ties.

Shared services go first, always. Identity, secrets management, networking, observability, and CI/CD need to exist on the EU provider before any workload can land there. These are workloads too, they are rarely on anyone's urgency list, and they are the actual critical path of the first three months. If your plan has a customer-facing service landing in month three and no mention of where its identity provider lives, the plan is wrong.

Dates go second. A commitment expiring, a contract renewing, an audit landing. Where two workloads are otherwise equal, the one with the nearer date goes first.

Dependencies go third. If the order service calls the fraud service, move the fraud service first or move them together. Splitting a chatty synchronous pair across two providers is a slow way to discover what latency and egress cost.

Blast radius goes last. Between two equal workloads, move the one whose failure hurts less. This sounds obvious and is routinely overridden by whoever shouts loudest in the planning meeting.

A worked wave plan

A fictional enterprise with a dozen workloads might end up with something like this.

Before wave one, the landing zone: networking, identity federation, secrets, logging and metrics, CI/CD runners, and the internal wiki as the first pilot because it is ready, it is harmless, and everyone will notice if it is slow.

Wave one: the customer API with its Postgres database (urgent, ready, client contract mentions residency), the document store that backs it (coupled, moves together), and the identity provider those two depend on. One quarter of work, one visible compliance win.

Wave two: the analytics platform, which was urgent and not ready in month one and spent wave one having its ETL layer rewritten onto something portable. Plus the HR application, which was not ready for the undramatic reason that nobody owned it, and now someone does.

Wave three: the machine learning training pipeline, moving to a GPU-focused EU provider because the economics are better there, and the remaining internal tools for operational simplicity. Development and test environments stay on the hyperscaler through the whole programme and move, or do not, after the regulated estate is done.

How long each wave takes and what the business feels during each is covered in the migration timeline and business disruption guide.

Prioritisation mistakes we keep seeing

Starting with the crown jewels. The most important workload is the worst first migration, because the first migration is where your team makes its beginner mistakes.

Prioritising by hosting cost. Cheap to run on the hyperscaler has nothing to do with cheap to move, and the cost that matters is engineering time.

Letting the provider set the order. A provider's solution architect will prioritise whatever showcases their platform. That is their job, not yours.

Forgetting shared services. Then discovering in month four that nothing can go live because the secrets manager is still in Frankfurt under a US parent company.

Treating the quadrants as permanent. Readiness changes as remediation lands. Re-score at the start of every wave and let workloads move between quadrants.

Treating multi-cloud as the destination. Running regulated workloads on an EU provider and the rest on a hyperscaler is a legitimate bridge during the programme. Left in place for years, it costs you two of everything and erodes the sovereignty benefit you set out to get.

How Looming Tech can help

Looming Tech helps UK and EU enterprises turn a workload inventory into a wave plan that legal, finance, and engineering can all sign off on, and then delivers the waves. We are a registered partner with OVHcloud, STACKIT, Scaleway, and T Cloud Public, so provider selection per wave is part of the same conversation. If you have a list of workloads and no agreed order, or an order that keeps slipping, we are happy to have a no-commitment conversation. Start with the pillar guide if you want the full picture first.

Talk to our team →