Die 24-Monats-Roadmap

Die vertragliche Checkliste schafft Verhandlungsmacht; dieses Kapitel schafft Reihenfolge. Die Abfolge der Schritte ist entscheidend. Drei Grundsätze bestimmen die Sequenzierung:

1. Die Diagnose geht der Vertragserneuerung voraus. Ohne Kenntnis der eigenen Abhängigkeiten können keine zielgenauen Klauseln verhandelt werden.
2. Die Vertragserneuerung geht der architektonischen Migration voraus. Ohne ausgehandelte Ausstiegsoptionen ist eine Migration nicht durchführbar.
3. Resilienzprüfung erfolgt erst nach der Diversifizierung. Die Resilienz eines monolithischen Deployments zu testen, hat nur begrenzten Wert.

Phase 1: Diagnose (Q2–Q3 2026, drei Monate)

Die erste Phase ist rein informationeller Natur. Sie fragt: Was haben wir tatsächlich, und wo sind wir exponiert?

• Inventar aller IKT-Lieferanten und ihrer Rechtsordnungen. Tabellenformat genügt; entscheidend sind Vollständigkeit und Aktualität.
• Klassifizierung der Workloads nach Sensitivität entlang der drei Schichten digitaler Autonomie: Bit, Interpretation, Instrumentierung. Unterschiedliche Workloads erfordern unterschiedliche vertragliche Sorgfalt.
• Identifikation von Konzentrationspunkten. Wo stellt ein einzelner Anbieter mehr als zwei kritische Systeme bereit? Diese Liste ist der Ausgangspunkt für die Diversifizierungsplanung.
• Kartierung der Vertragsausläufe der nächsten 24 Monate. Verlängerungen sind die natürlichen Momente, um die Checkliste anzuwenden; ohne diese Übersicht werden Gelegenheiten verpasst.

Ergebnis von Phase 1: ein Diagnosebericht, der der Unternehmensführung vorgelegt werden kann, die zehn größten Abhängigkeitsrisiken benennt und den Kalender der Handlungsmöglichkeiten aufzeigt.

Phase 2: Vertragserneuerung (Q3 2026 – Q1 2027, sechs Monate)

Mit der Diagnose in der Hand aktiviert die zweite Phase die Verhandlungsmacht:

• Anwendung der vertraglichen Checkliste auf jede Verlängerung. Bestehende Verlängerungen zuerst, neue Verträge danach.
• Verhandlung von Ausstiegsklauseln für die zehn kritischsten Lieferanten proaktiv, nicht erst bei Verlängerung. Wo Lieferanten Widerstand leisten, sollte dieser dokumentiert werden — er ist selbst eine Information über die strategische Haltung des Anbieters.
• SBOM-Anforderungen in allen Softwareverträgen.
• Aktivierung von BYOK/HYOK, wo der Anbieter dies unterstützt (AWS KMS with External Key Store, Azure Key Vault Managed HSM, Google Cloud EKM).
• DORA-Dokumentation der Ausstiegsstrategie für den Finanzsektor. Für Organisationen außerhalb des Finanzsektors ist dies Best Practice, aber noch keine gesetzliche Pflicht.

Ergebnis von Phase 2: vertragliche Regelungen, die eine Migration rechtlich und wirtschaftlich durchführbar machen, auch wenn noch keine Migration umgesetzt wurde.

Phase 3: Architektonische Diversifizierung (Q1 – Q3 2027, sechs Monate)

Die dritte Phase geht vom Papier in den Betrieb über:

• Pilotbetrieb eines Workloads auf europäischer Cloud (OVHcloud, Scaleway oder STACKIT). Die Wahl des Workloads ist bedeutsam: Er sollte anspruchsvoll genug sein, um das Betriebsmodell zu validieren, aber nicht so kritisch, dass ein Scheitern katastrophal wäre. Eine Staging-Umgebung, interne Tools oder eine nicht-kundengerichtete Analyse-Pipeline sind typische erste Kandidaten.
• Pilot von Nextcloud oder IceWarp für ein nicht-kritisches Team. Eine Abteilung mit 50 Personen, die zu Nextcloud migriert, ist ein realer Test des Produktivitätsstapels, ohne das Unternehmen zu gefährden.
• Pilot von Keycloak oder Authentik für eine nicht-kritische Anwendung. Identity-Migration birgt Integrationsrisiken; ein Pilot in begrenztem Umfang zeigt, was die umfassendere Migration erfordern wird.
• Evaluation von Mistral AI Studio für einen KI-Anwendungsfall. Selbst wenn die Produktionsmigration noch aussteht, schafft die Evaluation ein grundlegendes Wissen.

Ergebnis von Phase 3: empirisches, organisationsspezifisches Wissen darüber, was jede europäische Alternative tatsächlich leistet, mit quantifizierten Unterschieden zum bestehenden amerikanischen Stack. Dieses Wissen ist die Voraussetzung für alle weiteren Migrationsentscheidungen.

Phase 4: Resilienzprüfung (Q3 2027 – Q1 2028, sechs Monate)

Die vierte Phase erprobt die Architektur:

• Tabletop-Übungen zu „Vendor-Lock-out"-Szenarien. Simuliert wird der Verlust des Zugangs zu einem kritischen Lieferanten — was würde die Organisation tun, in welcher Reihenfolge, und was würde es kosten?
• Echtzeit-Datenmigrationstests. Daten werden von Anbieter A zu Anbieter B im Produktionsmaßstab verschoben. Gemessen werden Zeit, Kosten und Fehlermodi.
• BC/DR-Plantests mit einem neuen Anbieter. Der Plan existiert auf dem Papier; funktioniert er auch in der Ausführung?
• Prüfung der Vertragsklauseln nach dem ersten Betriebsjahr. Welche Bestimmungen haben Lieferanten eingehalten? Welche erforderten Eskalation? Welche müssen bei der nächsten Verlängerung gestärkt werden?

Ergebnis von Phase 4: empirischer Nachweis, dass die Hebelprovisionierungen aus Phase 2 tatsächlich wirken und nicht nur auf dem Papier existieren.

Was diese Roadmap nicht löst

Die Roadmap adressiert die eigene Position der Organisation gegenüber ihren Lieferanten. Sie löst nicht die politische Ebene (regulatorische Diplomatie mit den USA, Verhandlungen über CLOUD Act-Ausnahmen), und sie löst auch keine Fragen, die kollektives EU-Handeln erfordern (Aufbau neuer Fabs, Unterstützung des RISC-V-Ökosystems, Energiepolitik für Rechenzentren). Das ist die Domäne staatlicher Planer.

Im Rahmen ihres Geltungsbereichs erzeugt sie ein konkretes Ergebnis: Bis Q1 2028 hat die Organisation die Fähigkeit nachgewiesen, Lieferanten in Monaten statt in Jahren wechseln zu können; sie verfügt über vertragliche Regelungen, die dies praktisch ermöglichen; sie hat die Architektur unter simuliertem Stress getestet; und sie hat die interne Kompetenz, den diversifizierten Stack zu betreiben. Das ist die operative Bedeutung von Minimum Viable Sovereignty.