Cloud-Scale Analytics ist eingestellt. Prüfen Sie die Doku.

Im März 2026 hat Microsoft im Cloud Adoption Framework die neue Anleitung "Unify your data platform for AI and analytics" veröffentlicht und zugleich das Ende der Cloud-Scale-Analytics-Guidance angekündigt. Die alten Artikel wurden am 30. April 2026 gelöscht. Wenn Ihre Azure-Datenplattform zwischen 2021 und 2024 entworfen wurde, verweisen ihre Architekturentscheidungen mit einiger Wahrscheinlichkeit auf Dokumentation, die nicht mehr existiert.

Das ist keine Krise. Es ist ein Anlass zu prüfen, welche dieser Entscheidungen aus eigener Kraft bestehen und welche nur galten, "weil das Framework es so vorsah".

Was Cloud-Scale Analytics war

Cloud-Scale Analytics war die Blaupause der Synapse-Ära für Unternehmens-Datenplattformen auf Azure: eine Data Management Landing Zone für gemeinsame Dienste wie Katalog und Governance, getrennte Data Landing Zones je Fachdomäne und eine Subscription-Topologie, die das Ganze abbildete. Sie übernahm das Vokabular des Data Mesh und übersetzte es in Azure-Ressourcen, mit Azure Synapse, Data Lake Storage und Purview als Standardbausteinen. Viele Organisationen im DACH-Raum haben darauf gebaut, und die Architekturdiagramme aus diesen Projekten hängen heute noch in Wiki-Seiten.

Was an ihre Stelle trat

Die neue Anleitung behält die organisatorischen Ideen und verschiebt den technischen Schwerpunkt zu Microsoft Fabric. Sie rät Entscheidern, Betriebsmodelle um Datendomänen zu organisieren, Verantwortung je Domäne festzulegen und Standards für sichere, gesteuerte Datenprodukte zu setzen, die Analytik und KI versorgen.

Darunter liegt die strukturelle Verschiebung. In Cloud-Scale Analytics war eine Domänengrenze eine Subscription-Grenze: getrennte Landing Zones, getrenntes Netzwerk, getrennte Ressourcengruppen. Im Fabric-Modell wird dieselbe Grenze innerhalb eines Tenants gezogen: eine Fabric-Domäne, ihre Workspaces und die Kapazität, über die sie abgerechnet wird. Das Ordnungsprinzip hat überlebt. Die Azure-Ressourcen, die es ausdrückten, nicht.

Was gültig bleibt

Mehr, als die Löschung vermuten lässt. Domänenorientierte Verantwortung bleibt der richtige Schnitt für einen Unternehmensdatenbestand, und die neue Anleitung verstärkt ihn sogar. Das Denken in Datenprodukten überträgt sich direkt: Ein Datensatz mit Eigentümer, Qualitätsstandards und Abnehmern ist dieselbe Idee, ob er in einem Synapse-Workspace liegt oder als OneLake-Element. Auch die Governance-Absicht bleibt. Purview ist weiterhin die Katalog- und Klassifizierungsebene, Vertraulichkeitsbezeichnungen wandern weiterhin mit den Daten, und die Frage "wer hat diesen Datensatz zertifiziert und wer nutzt ihn" ist unverändert.

Was sich ändert, ist der Ort der Kontrollen. Tenant-Einstellungen, Domänen, Workspace-Rollen, Endorsement und die Capacity Metrics App übernehmen einen guten Teil dessen, was vorher Subscription-Topologie, Azure Policy und RBAC auf Ressourcenebene für Analytik-Workloads geleistet haben. Wenn Ihr Governance-Modell in Subscriptions formuliert ist, muss es übersetzt werden, nicht verworfen.

Was die Einstellung nicht bedeutet

Sie bedeutet nicht, dass Ihre funktionierende Synapse-Plattform aufgehört hat zu funktionieren. Und sie bedeutet nicht, dass Sie in diesem Quartal migrieren sollten, weil ein Dokumentationssatz eingestellt wurde. Die Einstellung von Guidance ist ein Signal dafür, wohin Microsofts Investitionen fließen, und dieses Signal zeigt seit zwei Jahren auf Fabric. Behandeln Sie es als genau das.

Die Migrationsentscheidung verdient eine eigene Rechnung: was die heutige Plattform im Betrieb kostet, welche Workloads von Fabric tatsächlich profitieren würden und was das kapazitätsbasierte Preismodell mit Ihrem Kostenprofil macht, verglichen mit dem heutigen Verbrauch. Fabric-Kapazitäten verrechnen den gesamten Verbrauch über einen gemeinsamen Kapazitätspool. Das vereinfacht den Einkauf und kann Kostenüberraschungen bündeln. Organisationen, die zuerst berichtslastige Workloads umgezogen haben, hatten meist die saubersten frühen Erfolge; eine funktionierende Spark-Umgebung allein aus Prinzip neu zu bauen, erzeugt eher das Gegenteil.

Ein konkreter nächster Schritt

Nehmen Sie die Architekturentscheidungen Ihrer Datenplattform und markieren Sie jede, die auf Cloud-Scale Analytics verweist. Fragen Sie für jede, ob sie aus eigenem Recht weiterbesteht. Domänengrenzen tun das meistens. Subscription-Topologie, Integrationsmuster und Werkzeugwahl brauchen oft eine neue Antwort gegen das Fabric-Modell. Diese Durchsicht ist bei einer kleinen Plattform ein Nachmittag Arbeit und bei einer großen ein strukturiertes Assessment. Beides ist erheblich billiger, als die veralteten Annahmen eine Migration nach der anderen zu entdecken.