Fabric Runtime 2.0: Migration vor dem Default-Wechsel richtig vorbereiten

Fabric Runtime 2.0 ist allgemein verfügbar und Microsoft plant, die neue Runtime Ende September 2026 zur Standardauswahl für neue Workspaces und Environment Items zu machen. Das ist keine automatische Zwangsmigration aller bestehenden Workloads. Es ist aber ein sinnvoller Migrationsmarker: Fabric-Teams sollten jetzt ihre wichtigsten Spark- und Lakehouse-Workloads auf Kompatibilität prüfen, bevor 2.0 zum normalen Ausgangspunkt für neue Umgebungen wird.

Microsoft beschreibt den Default-Wechsel aktuell als Plan für Ende September 2026. Der tatsächliche Rollout sollte vor einer produktiven Umstellung nochmals gegen die aktuellen Microsoft-Release-Informationen geprüft werden.

Das Wichtigste in 60 Sekunden

Fabric Runtime 2.0 ist mehr als ein Spark-Update. Gegenüber Runtime 1.3 ändern sich gleichzeitig Spark 3.5.5 auf 4.1, Java 11 auf 21, Scala 2.12.17 auf 2.13.16, Python 3.11 auf 3.13 und Delta Lake 3.2 auf 4.2. Auch die Linux-Basis wechselt.

Das Migrationsrisiko steckt deshalb nicht im Runtime-Dropdown, sondern in Abhängigkeiten: Custom JARs, Python-/Wheel-Libraries, Spark-Settings, Code-Kompatibilität und Delta-Interoperabilität über verschiedene Fabric Experiences.

Unsere Empfehlung: Runtime 2.0 zunächst über ein Environment Item für repräsentative Notebooks oder Spark Job Definitions pilotieren. Erst nach Regressionstests, Library-Checks und Cross-Workload-Tests wird in Wellen ausgerollt.

GA, Default und LTS – 3 Dinge, die nicht verwechselt werden sollten

Frage	Stand 31.08.2026	Bedeutung
Ist Runtime 2.0 produktionsreif?	Ja, GA	Microsoft führt 2.0 als aktuellste GA-Runtime.
Ist Runtime 2.0 bereits der Default?	Nein	Neue Workspaces verwenden aktuell noch Runtime 1.3.
Was ist für Ende September geplant?	Default-Auswahl in der UX und für neue Workspaces/Environment Items	Kein automatischer Zwangswechsel jedes bestehenden Workloads.
Was passiert mit Runtime 1.3?	Support-Ende 30.09.2026; danach sechs Monate LTS bis März 2027	begrenzter Übergangs- und Fallback-Puffer.

GA bedeutet Produktionsreife. Default bedeutet, welche Runtime bei neuen Umgebungen zunächst ausgewählt wird. LTS bedeutet, dass Runtime 1.3 noch begrenzte Zeit als unterstützter Übergangspfad zur Verfügung steht.

Was sich technisch von Runtime 1.3 auf 2.0 ändert

Bei Fabric Runtime 2.0 migriert nicht nur Spark. Mehrere technische Schichten ändern sich gleichzeitig. Deshalb sollte der Runtime-Wechsel wie ein Plattform-Upgrade behandelt werden.

Runtime 2.0 bündelt mehrere Versionssprünge – deshalb ist der Wechsel ein Plattform-Upgrade.

Risiko 1 – Libraries, JARs und Python-Abhängigkeiten

Microsoft weist bei JARs auf ein erhöhtes Kompatibilitätsrisiko hin, weil sich gleichzeitig Scala, Java, Spark und das Betriebssystem ändern. Inkompatible Abhängigkeiten müssen Teams selbst aktualisieren oder ersetzen.

Für Python ist die Lage ebenfalls relevant, weil Runtime 2.0 auf Python 3.13 wechselt. Wheels und Packages mit nativen Komponenten sollten nicht nur installiert, sondern mit repräsentativen Daten fachlich ausgeführt und regressionsgetestet werden.

Hinzu kommt derzeit ein konkret dokumentierter Sonderfall: Microsoft rollt ein Runtime-2.0-Update aus, bei dem die Python-Aktualisierung Environment Items mit Python- und Wheel-Libraries beeinträchtigen kann. Für betroffene Environments beschreibt Microsoft einen Republish-Prozess: Libraries entfernen, Environment veröffentlichen, Libraries wieder hinzufügen und erneut veröffentlichen. Das ist kein universeller Migrationsschritt für jedes Environment, aber ein aktueller Beleg dafür, dass auch die Environment-Konfiguration in den Testumfang gehört.

Risiko 2 – Spark-Settings und Session-Verhalten

Ein Runtime-Wechsel im Workspace greift nicht rückwirkend in eine bereits laufende Spark Session ein. Die neue Auswahl gilt ab der nächsten Session beziehungsweise dem nächsten Job.

Spark-Settings werden beim Wechsel grundsätzlich migriert. Erkennt Fabric eine Einstellung als inkompatibel, wird sie nicht angewendet und mit einer Warnung versehen. Deshalb gehören Pools, Spark-Konfigurationen und Environment-Einstellungen genauso in die Abnahme wie Notebook-Code und Ergebnisdaten.

Risiko 3 – Delta Lake 4.2 und Cross-Workload-Interoperabilität

Delta-4.x-Features müssen gegen alle relevanten Fabric-Verbraucher getestet werden.

Delta Lake 4.2 bringt neue Funktionen und Optimierungen. Microsoft kennzeichnet Runtime-2.0-spezifische Delta-4.2-Funktionen teilweise als experimentell und weist darauf hin, dass sie nur in Spark Experiences funktionieren. Wenn dieselben Tabellen von mehreren Fabric Workloads genutzt werden, sollen diese Funktionen nicht aktiviert werden.

Eine Delta-Tabelle kann in einem PySpark-Notebook korrekt funktionieren und trotzdem Einschränkungen bei einem anderen Verbraucher haben. Die Microsoft-Interoperabilitätsmatrix zeigt unterschiedliche Feature-Unterstützung unter anderem für Python Notebooks, Pipelines, Dataflows, Warehouse, SQL Analytics Endpoint und Power BI Direct Lake.

Neue Delta-Features und Protokoll-Upgrades sollten eine eigene Freigabe bekommen und nicht nebenbei mit der Runtime-Migration eingeführt werden. Ein Delta-Protokoll-Upgrade ist laut Microsoft nicht reversibel und kann ältere Reader oder Writer ausschließen.

Der sichere Pfad führt vom isolierten Environment-Pilot zum kontrollierten Workspace-Rollout.

Eine sichere Fabric-Runtime-2.0-Migration in sieben Schritten

1. Workloads inventarisieren. Erfasst Workspaces, Environment Items, Notebooks, Spark Job Definitions, Runtime-Versionen, kritische Datenflüsse und fachliche Kritikalität.

2. Abhängigkeiten klassifizieren. Sucht gezielt nach Custom JARs, Python-/Wheel-Libraries, Spark-Settings, externen Connectoren, Streaming-Workloads und Delta-Features.

3. Runtime 2.0 isoliert pilotieren. Legt für repräsentative Workloads ein Environment Item mit Runtime 2.0 an. Dieses Environment kann gezielt an Notebooks oder Spark Job Definitions gebunden werden und den Workspace-Default für diese Workloads überschreiben.

4. Environments und Libraries reproduzierbar aufbauen. Prüft, ob alle Libraries installiert, veröffentlicht und bei einem Neuaufbau reproduziert werden können. Bei aktuell betroffenen Python-/Wheel-Environments berücksichtigt ihr den von Microsoft dokumentierten Republish-Schritt.

5. Regressionstests durchführen. Vergleicht Ergebnisdaten, Schemas, Laufzeiten, Fehlermeldungen, Spark-SQL-/DataFrame-Verhalten, Streaming und relevante Performance-Kennzahlen. Microsoft nennt für die Native Execution Engine in Benchmarks bis zu sechsfache Beschleunigung; behandelt das als Benchmark-Maximum, nicht als Leistungsversprechen für euren Workload.

6. Delta-Interoperabilität separat testen. Für gemeinsam genutzte Tabellen testet ihr alle relevanten Verbraucher. Neue Delta-4.x-Features oder Protokoll-Upgrades erhalten eine eigene Freigabe.

7. In Wellen ausrollen. Migriert zuerst risikoarme und gut beobachtbare Workloads, danach kritische Produktionspfade. Den Workspace-Default setzt ihr erst nach erfolgreicher Abnahme. Runtime 1.3 kann in der Übergangsphase als zeitlich begrenzter Fallback dienen.

Die operative Migrations-Checkliste

Prüffeld	Vor Pilot	Vor Workspace-Rollout
Runtime-/Workspace-Inventar	vollständig	aktualisiert
Custom JARs und Connectoren	identifiziert	produktiv getestet
Python-/Wheel-Libraries	identifiziert	installiert, veröffentlicht, regressionsgetestet
Spark-Settings	dokumentiert	Warnungen/Abweichungen geklärt
Notebook-/SJD-Ergebnisse	Baseline gesichert	fachlich verglichen
Delta-Protokoll/Table Features	erfasst	Cross-Workload-Tests bestanden
Performance	Baseline gemessen	repräsentativ verglichen
Fallback	definiert	für kritische Welle dokumentiert

Welche Workloads ihr zuerst migrieren solltet

Nicht jeder Spark-Workload trägt dasselbe Risiko. Ein Notebook ohne eigene Libraries und mit überschaubaren Delta-Abhängigkeiten ist ein guter Pilot. Ein produktiver Job mit Custom JARs, externen Connectoren, Streaming und gemeinsam genutzten Tabellen gehört dagegen eher in eine spätere Migrationswelle. Die Reihenfolge der Migration sollte sich am technischen Risiko und an der fachlichen Kritikalität orientieren – nicht an der Größe des Workspaces.

Praktisch hilft eine einfache Einteilung in drei Risikoklassen. Niedriges Risiko haben Workloads mit Standard-Libraries, klaren Inputs und wenigen nachgelagerten Verbrauchern. In die mittlere Klasse gehören Jobs mit mehreren Packages, individuellen Spark-Settings oder größeren Delta-Abhängigkeiten. Hohes Risiko entsteht dort, wo Custom JARs, Streaming, externe Systeme oder gemeinsam genutzte Tabellen zusammenkommen. Diese Einteilung macht die Reihenfolge nachvollziehbar und verhindert, dass ausgerechnet der kritischste Produktionspfad zum ersten Testfall wird.

Besonders wichtig wird diese Priorisierung, wenn Daten nicht nur innerhalb eines einzelnen Lakehouse genutzt werden. Sobald zentrale OneLake-Daten, Shortcuts oder mehrere Consumer beteiligt sind, entstehen zusätzliche Abhängigkeiten. Das zeigt sich auch bei Delegated OneLake Shortcuts: Datenzugriff und Identität sind Teil der Architektur und sollten bei einem Runtime-Wechsel nicht isoliert betrachtet werden. Für den Pilot bedeutet das: Nicht nur den erzeugenden Spark-Job testen, sondern auch prüfen, ob alle nachgelagerten Datenpfade weiterhin wie erwartet funktionieren.

Runtime-Migration ist auch ein Governance-Thema

Technische Kompatibilität ist nur eine Seite der Migration. In produktiven Fabric-Landschaften muss ebenso nachvollziehbar sein, welche Runtime, welche Library-Versionen und welche Settings für einen Workload freigegeben sind. Sonst läuft der Pilot heute erfolgreich, aber zwei Monate später kann niemand mehr sauber erklären, warum ein Job nach einem Package-Update oder einer Environment-Änderung anders reagiert.

Eine Runtime-Migration ist deshalb auch ein Governance-Thema: Versionen, Abhängigkeiten und Freigaben müssen nachvollziehbar sein. Dazu gehören dokumentierte Environment-Konfigurationen, klar benannte Verantwortliche für die fachliche Abnahme, definierte Rollback-Kriterien und eine getrennte Entscheidung über Delta-Protokoll- oder Feature-Upgrades. Gerade in größeren Teams ist diese Nachvollziehbarkeit wichtiger als ein möglichst schneller Wechsel des Workspace-Defaults.

Das wird umso wichtiger, wenn auf denselben Daten weitere Fabric-Workloads aufsetzen. Bei Fabric Data Agents: Die Einführung wird sichtbar, wie Datenzugriff, Semantik und Berechtigungen über mehrere Schichten zusammenspielen. Ein Runtime-Upgrade im Spark-Layer kann damit indirekt einen größeren Betriebszusammenhang berühren. Wer Migration und Governance gemeinsam plant, erkennt solche Abhängigkeiten früher und kann Testfälle gezielt darauf ausrichten.

Performance richtig bewerten

Runtime 2.0 kann Performance-Vorteile bringen, unter anderem durch die Weiterentwicklung der Native Execution Engine und den neuen Spark-Unterbau. Trotzdem sollte ein erfolgreicher Migrationsentscheid nicht an einem einzelnen schnellen Testlauf hängen. Laufzeiten schwanken je nach Datenvolumen, Parallelität, Caching, Library-Verhalten und Capacity-Auslastung. Deshalb braucht ihr vor dem Pilot eine belastbare Baseline mit denselben fachlichen Ergebnissen und möglichst vergleichbaren Rahmenbedingungen.

Performance-Gewinne sind ein Bonus, aber kein Ersatz für fachliche Regressionstests. Ein Job, der 30 Prozent schneller läuft, aber andere Schemas erzeugt, einzelne Datensätze anders behandelt oder einen nachgelagerten Consumer beeinträchtigt, ist keine erfolgreiche Migration. Erst wenn Ergebnisqualität, Stabilität und Interoperabilität stimmen, wird Performance zum sinnvollen Optimierungskriterium.

Bei wiederkehrenden Spark-Jobs kann eine veränderte Laufzeit auch wirtschaftlich relevant werden, weil Compute-Nutzung und Capacity-Planung zusammenhängen. Für diese Perspektive lohnt sich der ergänzende Blick auf Microsoft Fabric Kosten verstehen. Wichtig ist dabei, Kosten nicht aus einem einzelnen Benchmark abzuleiten, sondern Laufzeit, Ausführungsfrequenz und tatsächliche Capacity-Nutzung gemeinsam zu betrachten. So lässt sich unterscheiden, ob Runtime 2.0 nur technisch schneller ist oder auch im Betrieb einen messbaren Vorteil bringt.

Wenn eure Lakehouse-Architektur zusätzlich Daten aus anderen Plattformen spiegelt, solltet ihr den Runtime-Test um diese Datenpfade erweitern. Der Artikel Open Mirroring in Microsoft Fabric zeigt, warum zentrale Delta-Daten schnell von mehreren Prozessen abhängig werden können. Genau solche gemeinsam genutzten Pfade gehören in einen repräsentativen Runtime-2.0-Pilot.

Was ihr jetzt konkret tun solltet

Wenn ihr Runtime 1.3 produktiv nutzt, behandelt den September nicht als Wartezeit, sondern als Validierungsfenster. Startet mit zwei bis fünf repräsentativen Workloads: einem einfachen Batch-Notebook, einem komplexeren Job mit Libraries, einem kritischen Delta-Pfad und – falls vorhanden – einem Streaming- oder JAR-lastigen Workload.

Erst wenn diese Fälle unter Runtime 2.0 fachlich und technisch sauber laufen, erweitert ihr den Pilot. So wird aus dem geplanten Default-Wechsel kein Deadline-Projekt, sondern ein kontrollierter Plattformwechsel.

---

Fazit

Fabric Runtime 2.0 ist kein gewöhnliches Minor-Upgrade. Der gemeinsame Sprung auf Spark 4.1, Java 21, Scala 2.13, Python 3.13 und Delta Lake 4.2 verändert mehrere technische Ebenen gleichzeitig. Der geplante Default-Wechsel Ende September 2026 ist deshalb vor allem ein guter Migrationsmarker – nicht der Startschuss für einen Big-Bang.

Wer jetzt repräsentative Workloads über Environment Items isoliert testet, Libraries und Settings überprüft und Delta-Interoperabilität als eigenes Abnahmekriterium behandelt, reduziert das Risiko deutlich. Der wichtigste Schritt ist nicht, Runtime 2.0 möglichst schnell überall zu aktivieren, sondern den Wechsel reproduzierbar und in kontrollierten Wellen durchzuführen.

---

Der nächste sinnvolle Schritt

Wenn ihr eure Fabric-Spark- und Lakehouse-Landschaft vor dem Runtime-Wechsel strukturiert prüfen wollt, ist unser Microsoft Fabric Bereich der passende Einstieg in einen Microsoft Fabric Kick Start bzw. eine konkrete Migrations- und Architekturberatung.