How to Assess Which Workloads Are Ready for Sovereign Cloud Migration

A workload is ready for sovereign cloud migration when you can answer six questions about it with evidence instead of a guess: what data it holds, which hyperscaler-only services it depends on, how portable its runtime is, how much data it drags with it, what licences and commitments are attached to it, and who actually owns it. Most engineering teams can answer two of those from memory. The other four take digging through billing exports, Terraform, and the on-call rota. That digging is the assessment.

This article is the practical companion to our EU sovereign cloud migration guide. It covers how to score readiness. It deliberately does not cover which workloads you should move first; that is a different question, with a different answer, and we deal with it in which workloads to migrate to sovereign cloud first.

What "ready" means, and what it does not

Ready means you can move the workload with known effort and known risk. It does not mean the workload should move, and it does not mean it will be cheap. A ready workload might sit on the hyperscaler for another year because nothing forces it off. An unready workload might be the one your regulator cares most about. Keep the two judgements apart. Readiness is a technical property of the workload. Priority comes from the business and the law.

The mistake we see most often is mixing them: a CTO scores the customer database as "ready" because it is the most important thing to move. Importance is not readiness. The customer database with three hyperscaler-native services wired into it is important and not ready, and saying so early is what stops the migration from stalling in month seven.

The six readiness criteria

Score each criterion from 1 (we do not know, or the answer is bad) to 4 (we know, and the answer is good). Do it per workload, not per team or per account. A workload is a thing you could cut over on its own: an API and its database, a batch pipeline and its storage, an internal application and its file share.

1. Data classification

Do you know what data the workload holds, and have you classified it? GDPR special categories, health records, financial transaction data, anything a client contract pins to EU residency. A 4 here means a written classification exists, someone owns it, and it has been checked against the actual tables and buckets rather than the original design document. A 1 means "it is probably mostly customer data."

This is also where you check the quieter data flows. Where do logs go? Where does the monitoring agent send telemetry? Which region holds the backups? Metadata leaking to a non-EU endpoint is the most common way an otherwise clean workload fails a sovereignty review, and it almost never shows up in the architecture diagram.

2. Hyperscaler-native service dependencies

Count the managed services the workload uses that have no equivalent on your target EU provider. Bedrock, Step Functions, EventBridge, DynamoDB, Cosmos DB, Glue, Vertex AI, and the long tail of hyperscaler data services all belong on this list. Each one is a piece of re-architecture, and re-architecture is where lift-and-shift estimates go to die.

Do not trust the CMDB for this. Pull the billing export filtered to the workload's accounts or tags and read the service column. Billing does not forget the Lambda that someone wired to an SQS queue in 2022. Score a 4 if the workload uses only compute, networking, object storage, and a mainstream database engine. Score a 1 if the business logic itself lives inside proprietary services.

3. Runtime portability

How does the workload run? Roughly in order from most to least portable: containers on Kubernetes with no cloud-specific operators or CSI drivers; virtual machines built by configuration management you control; a managed platform with a proprietary API (App Engine, Elastic Beanstalk, Azure App Service); serverless functions wired to proprietary event sources. "It is all in Terraform" is not a portability score. Terraform describes the hyperscaler resources perfectly well and is no help at all when the resources do not exist on the other side.

Managed Kubernetes exists on every serious EU provider, so a workload that is already on Kubernetes with standard ingress and standard storage classes scores well. The provider comparison covers which EU providers have the deeper managed service catalogue if the workload needs more than Kubernetes and a database.

4. Data gravity and coupling

How much data does the workload own, and what is it coupled to? Terabytes of object storage, a multi-terabyte database with cross-region replication, or a stream that other workloads consume all raise the cost and the cutover window. Coupling to workloads that will stay on the hyperscaler for now is the subtle one. If the order service calls the fraud service forty times a second and the fraud service is not moving until next year, you have just signed up for cross-provider latency and egress on every request.

Score a 4 if the data is small enough to move in a maintenance window and the workload's integrations are to things that move with it or things that do not care where it lives. Score a 1 if the data is large and the integrations are chatty and synchronous.

5. Licensing and commercial attachments

What commercial ties does the workload have to the current provider? Reserved instances and savings plans that run past your planned cutover. Marketplace subscriptions billed through the hyperscaler. Windows and SQL Server licences bought through the provider's licence-included pricing. VMware licensing, which after Broadcom's pricing changes is a reason to move for many enterprises and a complication for the ones that renewed. Oracle, which is a conversation on its own.

None of these stop a migration. All of them change its economics and timing, and finance will want to know before the engineers start. A 4 means the attachments are known and expire within the migration window, or can be transferred. A 1 means nobody has looked.

6. Operational ownership

Could the team that owns this workload rebuild it from scratch on a new provider, and do they know they own it? A 4 looks like: a named team, a runbook, infrastructure code that has been applied from clean at least once, tests that would catch a broken deployment, and observability you could point at a new environment. A 1 looks like: the person who built it left, it has not been redeployed in two years, and the only monitoring is customers emailing.

Ownership is the criterion teams most want to skip, because it is uncomfortable, and it is the one that most reliably predicts whether a migration ticket sits in the backlog for a quarter.

Turning the scores into a readiness decision

Add the six scores. The total runs from 6 to 24, and three bands are enough:

20 to 24: ready now. The workload can be scheduled into a migration wave as soon as the landing zone on the EU provider exists.

14 to 19: ready with bounded work. One or two criteria need fixing first, and you can name the work. Typically this is replacing a single proprietary service or waiting out a commitment. Put the remediation in the plan with an owner and a date.

6 to 13: not ready, which almost always means not yet understood. Do not plan a migration date for this workload. Plan the discovery work that would let you score it properly.

Resist the urge to weight the criteria by how much the workload matters to the regulator. That is priority, and it gets its own axis. A readiness score should mean the same thing for the HR portal as it does for the payments ledger.

A worked example

Take a fictional mid-sized enterprise with three workloads on the way to an EU provider.

The customer-facing API runs on managed Kubernetes with a Postgres database on the provider's managed service. Data is classified (4). It uses one proprietary service, a managed queue, which has a direct equivalent (3). Runtime is standard Kubernetes (4). The database is a few hundred gigabytes and the API talks only to its own database and to an identity provider that is moving in the same wave (3). No reserved commitments beyond the quarter (4). A team owns it and deploys weekly (4). Total 22: ready now.

The analytics pipeline is built on the hyperscaler's serverless ETL service, a query engine over object storage, and a scheduled orchestration service. Data is classified and contains customer transaction history (3). Every component is proprietary (1). Runtime portability is poor because the business logic is in the ETL jobs (1). Twenty terabytes of object storage with downstream dashboards reading from it (2). Nothing commercial attached (4). A data team owns it and understands it well (4). Total 15: ready with bounded work, and the work is a rewrite of the ETL layer onto Spark or a managed equivalent. That is a real project and should be scoped as one.

The internal HR application runs on two Windows virtual machines with SQL Server, licence included, built by hand five years ago. It holds employee personal data, which nobody has formally classified (2). No proprietary services (4). Hand-built VMs with no configuration management (2). Small data, no integrations (4). Licence-included SQL Server that would need relicensing on the new provider (2). Nobody is quite sure who owns it since the last reorganisation (1). Total 15, and the bounded work here is not technical. It is finding an owner and getting the licensing answered.

Three workloads, two with the same score, and three completely different conversations. That is what the assessment is for.

Where the assessment goes wrong

Inventory from the CMDB instead of the billing export. The billing export is what you are actually paying for, and it is complete.

Scoring by team instead of by workload. Teams own several workloads of very different readiness, and a team-level score hides the one that will hurt.

Ignoring the sidecars: logging, monitoring, secrets, identity, CI/CD. These are workloads too, and they need to land on the new provider before anything else can.

Doing it once. Readiness changes as you fix things and as the estate drifts. Re-score each wave before you commit to it.

Letting the provider's sales team run the assessment. They will find that everything is ready for their platform.

What to do with the scores

Readiness tells you what you can move. The next step is deciding what you should move first, which means putting readiness against regulatory and contractual urgency and sorting the result into waves. We walk through that in which workloads to migrate to sovereign cloud first. Once the waves exist, the migration timeline and disruption guide covers how long each takes and what the business will notice while it happens.

How Looming Tech can help

Looming Tech runs workload readiness assessments for UK and EU enterprises as the first step of a sovereign cloud migration, scored against the live billing data and infrastructure code rather than the architecture slides. 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 want a scored inventory you can take to the board, we are happy to have a no-commitment conversation.

Talk to our team →