English / Machine translation: Čeština · Deutsch

Operations

The 24-month roadmap

Four phases over Q2 2026 – Q1 2028: diagnostics, contractual renewal, architectural diversification, resilience testing

Published 2026-05-04 · Last reviewed 2026-05-04

The contractual checklist provides leverage; this chapter provides sequence. The order in which steps are taken matters. Three principles drive the sequencing:

  1. Diagnostics precedes contractual renewal. Without knowing your exposure, you cannot negotiate the right clauses.
  2. Contractual renewal precedes architectural migration. Without negotiated exit options, migration is not feasible.
  3. Resilience testing comes only after diversification. Testing the resilience of a monolithic deployment has limited value.

Phase 1: Diagnostics (Q2–Q3 2026, three months)

The first phase is purely informational. It asks: what do we actually have, and where are we exposed?

  • Inventory of all ICT suppliers and their jurisdictions. Spreadsheet-grade is fine; what matters is completeness and currency.
  • Classification of workloads by sensitivity along the three layers of digital autonomy: bit, interpretation, instrumentation. Different workloads warrant different contractual rigour.
  • Identification of concentration points. Where is a single vendor providing more than two critical systems? This list is a starting point for diversification planning.
  • Mapping of contract expiry over the next 24 months. Renewals are the natural moments to apply the checklist; without this map, opportunities are missed.

Output of Phase 1: a diagnostic report shareable with executive leadership, identifying the top 10 dependency risks and the calendar of opportunities to address them.

Phase 2: Contractual renewal (Q3 2026 – Q1 2027, six months)

With diagnostics in hand, the second phase activates leverage:

  • Application of the contractual checklist to every renewal. Existing renewals first, new contracts second.
  • Negotiate exit clauses for top-10 critical suppliers proactively, not on renewal. Where suppliers resist, document the resistance — it is itself information about the supplier's strategic posture.
  • SBOM requirements in all software contracts.
  • BYOK/HYOK activation wherever the provider supports it (AWS KMS with External Key Store, Azure Key Vault Managed HSM, Google Cloud EKM).
  • DORA exit-strategy documentation for the financial sector. For non-financial organisations, this is best practice but not yet legally required.

Output of Phase 2: contractual provisions in place that make migration legally and commercially feasible, even if no migration is yet executed.

Phase 3: Architectural diversification (Q1 – Q3 2027, six months)

The third phase moves from paper to deployment:

  • Pilot one workload on European cloud (OVH, Scaleway, or STACKIT). The choice of workload matters: it should be non-trivial enough to validate the operating model, but not so critical that failure is catastrophic. A staging environment, internal tools, or a non-customer-facing analytics pipeline are typical first choices.
  • Pilot Nextcloud or IceWarp for one non-critical team. A 50-person department migrating to Nextcloud is a real test of the productivity stack without betting the company.
  • Pilot Keycloak or Authentik for one non-critical application. Identity migration carries integration risk; piloting on a contained scope reveals what the broader migration will face.
  • Evaluate Mistral AI Studio for one AI use case. Even if production migration waits, the evaluation establishes baseline knowledge.

Output of Phase 3: empirical, organisation-specific knowledge of what each European alternative actually delivers, with quantified differences from the existing American stack. This knowledge is the prerequisite for any further migration decisions.

Phase 4: Resilience testing (Q3 2027 – Q1 2028, six months)

The fourth phase exercises the architecture:

  • Tabletop exercises of "vendor lock-out" scenarios. Simulate the loss of access to a critical supplier — what would the organisation do, in what sequence, and what would it cost?
  • Real-time data migration tests. Move data from Provider A to Provider B at production scale. Measure the time, the cost, the failure modes.
  • BC/DR plan tests with a new provider. The plan exists on paper; does it work when executed?
  • Audit of contract clauses after the first year of operation. Which provisions did suppliers honour? Which required escalation? Which need strengthening at next renewal?

Output of Phase 4: empirical evidence that the leverage provisions of Phase 2 actually operate, not just exist on paper.

What this roadmap does not solve

The roadmap addresses the organisation's own position vis-à-vis its suppliers. It does not solve the political layer (regulatory diplomacy with the U.S., negotiation over CLOUD Act exemptions), nor does it solve issues requiring collective EU action (building new fabs, supporting RISC-V ecosystem, energy policy for data centres). Those are the domain of state planners.

Within its scope, it produces a concrete result: by Q1 2028, the organisation has demonstrated the ability to switch suppliers in months, not years; has contractual provisions that make this practical; has tested the architecture under simulated stress; and has internal capability to operate the diversified stack. That is the operational meaning of Minimum Viable Sovereignty.

Sources cited

  1. Dario Maisto, Minimum Viable Sovereignty: A Smarter Path For Tech Leaders , Forrester Research , 2025-09-29 . link · archived
  2. European Parliament and Council of the European Union, Regulation (EU) 2022/2554 — Digital Operational Resilience Act (DORA) , EUR-Lex , 2022-12-14 . link · archived