Thought Leadership
„Services Provider Use Rights“ (SPUR) klingen nach Kleingedrucktem, regeln aber in Wahrheit, wie offen oder geschlossen der Markt für gehostete Microsoft‑Workloads ist. Schon im Jahr 2022 hat Microsoft tiefgreifende Hosting‑ und Outsourcing‑Änderungen vorgestellt und als Vereinfachung zugunsten von Kunden und Partnern beworben. Nun lief vor Kurzem die entsprechende Übergangsfrist ab.
Mit dem 30.09.2025 endete für Managed Service Provider (MSPs) die Möglichkeit, eigene SPLA‑Lizenzen auf Infrastrukturen der sogenannten „Listed Providers“ zu verwenden. Seit dem 01.10.2025 ist das nicht mehr zulässig.
Das Ende eines auf dem Markt etablierten Konzepts
Ein SPLA (Service Provider License Agreement) ist der seit Jahren etablierte Rahmen, über den Hoster, MSPs und ISVs Microsoft‑Software monatlich als Service lizenzieren – von Windows- und SQL-Server bis hin zu RDS‑ und Office‑Szenarien. SPUR präzisiert zu jedem Zeitpunkt die konkreten Nutzungsrechte und Einsatzbedingungen. Mit dem Aufkommen der Public Clouds begannen außerdem viele Anbieter, ihre eigenen SPLA‑Verträge auch auf Hyperscaler‑Infrastrukturen zu nutzen; dies verschaffte Redundanz, Preishoheit und Architekturfreiheit. Der Dreh‑ und Angelpunkt der aktuellen Änderungen im Cloud-Geschäft ist das Konzept genau ebenjener „Listed Providers“. Microsoft führt diese Bezeichnung seit 2019 und zählt dazu die vier großen Hyperscaler Alibaba, Amazon, Google und Microsoft (Azure).
Was ändert sich nun konkret? Bis einschließlich 30.09.2025 durften bestehende Bereitstellungen weiterlaufen; seit dem 01.10.2025 dürfen Dienstleister ihre eigenen SPLA‑Lizenzen in den Rechenzentren der Listed Providers nicht mehr einsetzen. Das bestätigen sowohl Microsoft‑Unterlagen als auch die Migrationshinweise der Hyperscaler. Zulässig bleiben dagegen „license‑included“-Angebote der Listed Providers selbst, also Instanzen, bei denen Microsoft‑Lizenzen im Preis enthalten sind. Für MSPs bedeutet das den Verlust eines zentralen Wettbewerbsinstruments – nämlich der eigenen Lizenz – ausgerechnet dort, wo die Nachfrage am größten ist. Preisgestaltung, Margen und Architekturentscheidungen verschieben sich damit in Richtung der Plattformanbieter.
Wenn die Datenportabilität an der Lizenz endet
Zwar verweist Microsoft als Gegenargument auf neue Lizenzvorteile wie das „Flexible Virtualization Benefit“ (FVB), das die Mitnahme geeigneter Abonnement‑ oder SA‑Lizenzen zu Partner‑Clouds erleichtern soll. In der Praxis gilt aber genau dort die entscheidende Einschränkung: Das FVB gilt nicht für Listed Provider, also eben nicht für AWS, Azure, Google oder Alibaba. Das vermeintliche Mehr an Freiheit endet damit bedauerlicherweise an der wichtigsten Marktschnittstelle. Die damit verbundenen Folgen reichen weit über Preisschilder hinaus: Lizenzgrenzen bestimmen die reale Daten‑ und Workload‑Portabilität. Wenn Wechselkosten durch Lizenzpfade steigen und Compliance‑Risiken zunehmen, leidet die Interoperabilität; Multi‑Cloud‑Ansätze werden de facto ausgebremst. Das Ergebnis ist eine Marktarchitektur, die Abhängigkeiten verstärkt und Wettbewerb dämpft – und damit ein Widerspruch zur von Microsoft angeblich behaupteten Öffnung.
Keine Cybersecurity ohne digitale Souveränität
Auch im Hinblick auf die Cybersicherheit ist dieses Vorgehen riskant: Denn Resilienz entsteht durch Anbieter‑Diversität, klar definierte Exit‑Pfade und technisch wie rechtlich abgesicherte Fallbacks. Wenn ein Lizenzwechsel – etwa im Incident‑Fall – zusätzliche Kosten, Umbauten oder juristische Prüfungen auslöst, werden Ausweichstrategien seltener geprobt und langsamer umgesetzt. Für Datenschutz und Data Compliance gilt Entsprechendes: Je enger die erlaubten Hosting‑Pfadoptionen gefasst sind, desto schwieriger wird es, regionale, datensparsame oder besonders souveräne Setups konsequent zu priorisieren – ein Schritt weg von der digitalen Souveränität in Zeiten, in der wir sie mehr denn je benötigen. Ökonomisch betrachtet ist diese Entwicklung im Ergebnis nichts anderes als eine Marktgestaltung via Lizenzrecht: Verhandlungsspielräume – also die Möglichkeit, Workloads anhand eigener SPLA‑Kalkulation auf der jeweils besten Infrastruktur zu betreiben – werden bewusst geschlossen. Der Preisanker verschiebt sich damit hin zu „license‑included“‑Tarifen und Programmen, die der Plattformbetreiber kontrolliert. SPUR wird so zur Stellschraube, mit der technische Möglichkeiten an wirtschaftliche Interessen angepasst werden.
Fahrplan für die Cloud-Umstellung
Guter Rat ist deshalb teuer: Was sollten die Kunden von Service‑Providern jetzt tun? Erstens: Eine Inventur aller Microsoft‑Workloads in den Clouds der Listed Providers durchführen und identifizieren, wo SPLA‑Lizenzen im Einsatz sind. Zweitens: Migrationspfade definieren – etwa den Rückzug in eigenes Rechenzentrum/Colocation. Drittens: Die Datenportabilität technisch absichern – beispielsweise mittels Containerisierung, automatisierten Re‑Deployments, Daten‑Exportpfaden und dem Aufbau eines zweiten, betriebsbereiten Zielumfelds für Notfälle. Viertens: Unbedingt die Kosten‑ und Compliance‑Kontrollen zeitnah schärfen – neue Preismodelle simulieren, Service Level Agreements (SLA) und Data Processing Agreements (DPA) anpassen, Ausstiegsklauseln vereinbaren, Vendor‑Lock‑in‑Risiken bewerten und die Datenrückgabe vertraglich absichern. Und fünftens – falls bislang noch nicht geschehen: Einen Meilensteinplan für die anstehenden Änderungen mit dem Provider verbindlich vereinbaren – inklusive Fallback-Lösungen, falls Termine oder Budgets reißen.
Fazit und Ausblick
Im Ergebnis dürfte damit eines klar sein: SPUR ist mehr als ein abstraktes Fußnotenwerk – es ist die zentrale Regelmatrix, die Wettbewerb, Sicherheit, Souveränität und Resilienz in der Cloud prägt. Die Abschaltung von SPLA auf den gelisteten Hyperscalern seit dem 01.10.2025 ist deshalb keine Randnotiz, sondern eine ganz wesentliche Richtungsentscheidung. Wer jetzt aber nüchtern plant und Datenportabilität konsequent aufbaut, verhindert, dass Lizenzklauseln am Ende die eigene Cloud-Architektur maßgeblich diktieren.
