How to migrate to sovereign alternatives: A framework

When evaluating their next options, Copenhagen's audit committee didn't set out to make a statement about digital sovereignty. It set out to explain why the city's Microsoft bill had climbed 72% in five years, from 313 million to 538 million Danish kroner, right as political tension with Washington made handing that much of the city's data to a single US-based vendor feel like a worse bet every year. The committee's answer was to leave. Copenhagen and Aarhus, Denmark's two largest municipalities, are now most of the way through moving off Microsoft's stack entirely. 

This example is not unique to the Nordics. Many European states or individual regions are taking a closer look at their tech dependencies to move to sovereign alternatives. Schleswig-Holstein reached a similar decision by a slower, more deliberate route. Instead of one dramatic exit, the German state worked through its software portfolio piece by piece: desktops first, with 80% now running LibreOffice instead of Microsoft Office; then email, with more than 40,000 accounts moved off Exchange.  

Neither Denmark nor Schleswig-Holstein treated a move to sovereign alternatives as a single decision. Both treated it as dozens of smaller decisions, made in a defensible order.  

That's the part most sovereignty conversations in enterprises still skip today: the framework for deciding what moves now, what moves next, and what's allowed to wait. 

The following piece explains this in more detail and offers a practical framework for deciding whether a system needs to move now, a map for sequencing everything else, and honest answers to the questions that commonly stall a migration before it can even start. 

Key takeaways

1. "Should we move to sovereign alternatives" is the wrong question: it's dozens of smaller ones 

   Every tool in your stack carries a different mix of legal exposure and operational dependency. Treating the whole portfolio as one migrate-or-don't decision is how organizations end up either paralyzed or migrating everything at once, badly. 

2. Gate one is a legal test, not a gut check: does this tool create real exposure, right now 

   Regulated personal data, financial records, and IP sitting with a US-jurisdiction provider is a different risk category than a marketing analytics tool. Sort by data classification before sorting by vendor. 

3. Gate two is where most frameworks get lazy: "business-critical" isn't a permanent excuse to do nothing 

   A system can be both business-critical and legal liability. The honest answer isn't "it stays forever." It's "it stays until this specific trigger, then we act." 

4. The hardest quadrant (high legal risk and high business criticality) is exactly the one sovereignty washing skips 

   Organizations under pressure to show progress often migrate to the easy, low-stakes systems first and call the sovereignty problem solved, while the system holding customer records or financials stays untouched because it's difficult to move. 

5. Even EU regulators score sovereignty in tiers, not as a pass/fail label: your migration plan should too 

   The European Commission's own Cloud Sovereignty Framework grades providers on a five-level scale, not a binary. A phased, honest migration plan matches how the people writing the rules already think about this problem. 

Most organizations are stuck between two bad defaults 

61 percent of Western European CIOs and IT leaders say geopolitical pressure will push them toward local or regional cloud providers, according to a November 2025 Gartner survey. IDC's sovereign cloud research found usage among European organizations jumped from 30% to 40% between 2023 and 2025, with another 31% planning to adopt it. While the intent is there, what's missing, for most of that majority, is a way to decide where to begin. 

In practice, organizations default to one of two mistakes. The first is paralysis: digital sovereignty becomes a standing agenda item that never produces a migration, because every system feels too risky to touch and too critical to justify the disruption. The second is worse: a rushed, undifferentiated push to "go sovereign" that migrates to the systems that are easiest to move, not the ones that matter most. Marketing sites and internal wikis move first because nobody argues about them. Customer records, HR systems, and financial platforms (the systems carrying regulatory exposure) stay exactly where they are, because moving them is tricky, and nobody wants to own that project. Data sovereignty commentators call this pattern sovereignty washing: presenting a migration as more complete than it is by counting the easy wins and quietly leaving the systems that created the exposure untouched. Unlike the majority might think, it isn't only a vendor problem; it's a buyer problem too, when an organization can point to a handful of completed migrations and call the exposure closed while the system that mattered most never moved. 

Both failure modes come from the same root cause: treating "should we migrate" as one question instead of running every system through the same two gates. 

Gate one: Does this system create real legal exposure right now? 

Gate one is really two separate questions, and most of the confusion around "sovereignty" comes from treating them as one. 

First: can the vendor be compelled to hand the data over? That turns on who owns the vendor, not where the data sits. The US CLOUD Act lets US authorities compel a US-incorporated company to produce data it controls, wherever that data is physically stored. A Frankfurt data center doesn't change who can be compelled, because the CLOUD Act follows the company's domicile, not its servers. 

Second, and separately: was moving the data there legal in the first place? That's what GDPR and the FADP actually govern: whether personal data crossing a border had the right mechanism behind it, typically an adequacy decision or Standard Contractual Clauses. 

Here's the trap: passing the second question says nothing about the first. A vendor can have every SCC on file, host every byte in an EU data center, and still be a US company answerable to a US subpoena. Ask only "are we GDPR-compliant" and the honest answer can be yes while the actual exposure, who can be compelled, stays wide open. 

If either answer comes back exposed, the system moves. Not eventually, but soon, because the exposure exists the day the audit finds it.

Making that call requires classifying data before classifying vendors. A rough three-tier split works for most organizations: data where residency or sovereignty is genuinely mandated by law (a narrow set of regulated categories, such as certain public-sector and national-security data, some health records, and specific financial data under national regulator rules), data where sovereignty is strongly preferred because the alternative carries real legal risk (most personal data under GDPR, along with business-sensitive information and IP), and data with no residency constraint at all (public content, non-sensitive analytics). Running a full sovereign migration against the third tier wastes budget the first two tiers need.

Gate two: is "business-critical" a reason to wait 

The second gate asks whether the system is critical enough that swapping it now would create more operational risk than it removes. That's a legitimate reason to delay, but only if it comes with a plan, not a permanent exemption. 

Two refinements make this gate work instead of becoming an excuse. First, check whether the system is a dependency on other systems' migrations, not just a business function on its own. Shared infrastructure (identity providers, logging, integration of middleware) often needs to move early precisely because everything downstream depends on it, even though it doesn't look customer-facing critical on its own. Second, separate "risky to swap today" from "will always be risky to swap." A system earns a spot on the wait list only with an attached trigger: contract renewal date, a named end-of-life deadline, a specific integration getting rebuilt anyway. Without a trigger, "business-critical" often becomes the reason nothing ever moves. That's how organizations end up, years later, explaining to a regulator why the exposure they identified was never closed. 

What the two gates produce: four categories

Run every system through both gates and four groups to emerge. Low legal risk and low criticality: deprioritize, revisit annually. High legal risk and low criticality: move now. These are usually the fastest wins and completing them first builds the internal case for the more difficult work. Low legal risk and high criticality: hold, with a named re-evaluation trigger. High legal risk and high criticality: this is the quadrant that matters, and it's the one both paralysis and rushed "sovereignty theater" avoid, because it's expensive, disruptive, and can't be solved by migrating the easy stuff instead. 

None of the four categories are a pure verdict, either: technical readiness modifies the sequence within each one. A system landing in "move now" still needs an honest look at its configuration debt: undocumented workflow customizations, brittle integrations, and Marketplace-app dependencies determine the real timeline and budget as much as the legal urgency does. Schleswig-Holstein's own rollout shows this in practice. LibreOffice moved first because it was ready to move technically, not just legally; SharePoint is still migrating to Nextcloud because the dependencies underneath it weren't. Treat technical readiness as a factor that reorders the queue within a category, not a reason to let a high-risk system quietly sit on the wait list because migrating it looks challenging. 

That last quadrant doesn't get solved by an all-at-once rip-and-replace either: full-portfolio migrations done under deadline pressure carry their own risk of data loss, service interruption, and costs that spiral once a supposedly standard migration turns up custom configurations nobody scoped in advance. The realistic path is a scoped, sequenced migration: tightened contractual terms, customer-controlled encryption keys, and reduced data flows while the full move is planned. 

It's worth noting that even the European Commission doesn't score sovereignty as pass or fail: its Cloud Sovereignty Framework grades providers on a five-level scale, from no demonstrated sovereignty up to a fully EU-controlled supply chain, and used that scale directly in a €180 million procurement in April 2026. If the regulators writing the rules think in graduated levels, a migration plan that does the same isn't cutting corners, it's matching the actual shape of the problem. 

Renewing the current vendor for one more cycle is a legitimate choice only for the two low-legal-risk categories (deprioritize and hold-with-a-trigger) where another cycle adds no new exposure. It stops being legitimate the moment legal risk is high, which covers both the fast-win quadrant and the last quadrant: there, renewing only extends an exposure gate one already flagged, and buys no real time.

Where sovara fits: one category among several 

Run this framework across a real portfolio and several different categories of tooling end up needing a sovereign replacement at once. Identity and access, storage, collaboration, work management, and more. No single vendor answers all of them, and claiming otherwise would be making exactly the kind of overclaim this framework exists to catch. 

sovara, rready’s sovereign work management platform answers one specific category: the part of most enterprise stacks built on Jira and Confluence. For that category, this is usually where sovara enters the plan, once gate one has flagged the system and gate two has confirmed it's time to act. 

sovara runs on EU and Swiss infrastructure with a legal entity incorporated in Zurich and verifiable in the Swiss commercial register, with no US corporate parent anywhere in the ownership chain. sovara also holds ISO/IEC 27001:2022 certification and BSI C5 attestation (independently audited standards) and lets customers bring their own AI endpoint, use a hosted model, or disable AI entirely. 

On the migration itself, be precise about scope rather than vague about comfort: standard Jira and Confluence configurations (tickets, workflows, automations, and core setup) are guaranteed, with the migration engagement fee refunded if that scope isn't delivered. That guarantee excludes Marketplace apps and custom code; environments heavy on either need to be scoped before commitment.

On total cost of ownership, be as concrete as the framework demands of everything else: licensing is one line item, not the whole picture. The comparison worth running before any commitment covers licensing, the migration engagement itself, internal hours for change management and training, and, for Marketplace-app-heavy or custom-code-heavy environments, the separately scoped cost of handling what the standard guarantee excludes. Naming the buckets doesn't answer what the number is. It does mean nobody discovers a bucket exists only after signing. 

The next step is simpler than it looks 

You don't need a company-wide sovereignty program to start. You need one spreadsheet, every system your organization runs, and two gates run honestly against each one. Most of the list will sort itself quickly: the systems that need to move now and the ones that clearly don't are usually obvious once the data classification is done. The value of the exercise is in the systems that land in the uncomfortable quadrant, because those are the ones a sovereignty review usually avoids naming. 

FAQs

Does every system eventually need to move to a sovereign alternative? 

No. Systems handling public content or non-sensitive data have no legal driver to move and shouldn't be prioritized ahead of systems that do. The framework exists to stop organizations from either migrating everything or migrating nothing: the goal is sorting correctly, not maximizing migration count. 

What do we do with a system that's both high-risk and business-critical? 

That's the quadrant that requires a scoped, sequenced plan rather than an immediate swap or an indefinite pass. Put interim mitigations in place while the migration itself is planned and resourced properly: contractual terms, key control, reduced data flows. 

How often should the "stays for now" list get reviewed? 

On a trigger, not a calendar reminder alone: contract renewal, a vendor's own end-of-life announcement, a related system being rebuilt, or a regulatory change. A wait-list entry without a named trigger tends to still be there in three years.