Fabric und Azure
Cloud-Migrationsstrategie: Leitfaden und Checkliste
Cloud-Migrationsstrategie für BI und Data Warehouse: Rehost, Replatform oder Refactor, Checkliste nach Phasen und ein Fabric-Beispiel.
Austin Levine
·
Aktualisiert
Eine Cloud-Migrationsstrategie ist der Plan, Daten, Anwendungen und Workloads von lokaler Infrastruktur auf eine Cloud-Plattform zu verlagern, ohne zu zerstören, was bereits funktioniert. Bei einer Migration von BI oder Datenplattform heißt das konkret: entscheiden, was unverändert umzieht, was neu gebaut wird und in welcher Reihenfolge, bevor Sie eine einzige Datenquelle anfassen.
Dieser Leitfaden behandelt die Entscheidung, an der die meisten Organisationen tatsächlich hängen bleiben: Rehost, Replatform oder Refactor. Danach geht er ein konkretes Beispiel durch, nämlich ein lokales Data Warehouse und seine Power-BI-Reports nach Microsoft Fabric zu verlagern, und endet mit einer Checkliste nach Phasen.
Rehost, Replatform oder Refactor
Jeder Cloud-Migrationsansatz für einen bestehenden Workload läuft auf eine von drei Entscheidungen hinaus. Entscheiden Sie pro Workload, nicht einmal für den ganzen Bestand.
Ansatz | Was sich ändert | Wann es passt |
|---|---|---|
Rehost | Den Workload mit wenig oder keiner Änderung an seiner Struktur in die Cloud verschieben. Manchmal Lift-and-Shift genannt. | Der Workload funktioniert bereits, die Frist ist knapp oder für die App oder Datenbank gibt es noch kein cloudnatives Gegenstück, das sich zu bauen lohnt. |
Replatform | Den Workload verschieben und einzelne Teile durch ein cloudnatives Gegenstück ersetzen, ohne kompletten Neubau. | Die Datenquelle selbst zieht um (zum Beispiel ein lokales SQL-Server-Warehouse nach Fabric Warehouse), aber die Reports und Modelle darauf müssen ihre Form nicht ändern. |
Refactor | Den Workload neu bauen, um die Cloud-Plattform zu nutzen, etwa monolithisches ETL in Pipelines und Spark-Notebooks aufteilen. | Das aktuelle Design ist ein bekannter Engpass, etwa nächtliche Batch-Jobs, die nicht mehr in ihr Zeitfenster passen, oder ein Modell, das über sein aktuelles Datenvolumen hinaus nicht skaliert. |
Ein einzelnes Migrationsprojekt kann alle drei mischen. Ein Dashboard, bei dem nur die Quelle umzieht, ist ein Replatform. Ein fragiler Satz nächtlicher SSIS-Pakete, der es speist, kann ein Refactor sein, getrennt und mit eigenem Zeitplan.
Ein durchgespieltes Beispiel: lokales Warehouse nach Fabric
Nehmen Sie einen häufigen Ausgangspunkt: ein SQL-Server-Data-Warehouse auf einem lokalen Server, mit Power-BI-Desktop-Reports, die im Power-BI-Dienst veröffentlicht sind und über das lokale Datengateway aktualisiert werden.
Prüfen, was tatsächlich umziehen muss. Listen Sie jede Tabelle auf, die die Power-BI-Reports nutzen, nicht jede Tabelle im Warehouse. Eine Migration ist ein guter Zeitpunkt, Tabellen zu streichen, die niemand abfragt.
Die Daten in Fabric ablegen. Bauen Sie eine Data-Factory-Pipeline, die die Quelltabellen in ein Fabric Lakehouse oder Warehouse kopiert. Das lokale Datengateway, das Power BI bereits für die geplante Aktualisierung nutzt, funktioniert auch für diese Pipeline, ein neuer Netzwerkpfad ist also nicht nötig. Zur Funktionsweise von Pipelines lesen Sie unseren Vergleich Data Factory im Vergleich: Fabric vs. Azure.
Das Semantic Model auf die neue Quelle zeigen lassen. Setzen Sie die Datenquelle des vorhandenen Power-BI-Modells auf den SQL-Endpunkt des Fabric Warehouse um oder bauen Sie es gegen das Lakehouse neu, wenn sich die Tabellenstrukturen geändert haben. Behalten Sie die DAX-Ebene, nur die Quelle ändert sich.
Import oder DirectQuery für die neue Quelle festlegen. Der SQL-Endpunkt von Fabric unterstützt beides. Die Abwägung beschreibt unser Leitfaden zu Import vs. DirectQuery. Die meisten migrierten Warehouse-Reports bleiben bei Import, es sei denn, ein bestimmter Report braucht nahezu Live-Daten.
Beide Systeme vor der Umstellung parallel betreiben. Aktualisieren Sie das neue Modell im selben Rhythmus wie das alte und vergleichen Sie Zeilenzahlen und wichtige Summen, bis sie über mehrere Aktualisierungen in Folge übereinstimmen.
Umstellen und abschalten. Stellen Sie die Report-Nutzer um und schalten Sie die lokale Quelle erst ab, wenn sie einen vollen Reporting-Zyklus lang niemand abgefragt hat.
Das ist ein Replatform: Die Reports ändern ihre Form nicht, aber die Quelle zieht von einer selbst verwalteten SQL-Server-Instanz in ein Fabric-Element mit eigener Rechenleistung, und die Pipeline läuft nun auf Fabric-Kapazität statt in einem geplanten Agent-Job. Was Ihnen diese Kapazität bringt, lesen Sie unter Warum Microsoft Fabric.
Phasen einer Migration
Phase | Was passiert |
|---|---|
Bewertung | Erfassen Sie die Quellen, Reports und Pipelines im Umfang. Klären Sie, wem jede gehört und ob sie noch genutzt wird. |
Planung | Wählen Sie Rehost, Replatform oder Refactor pro Workload. Legen Sie eine Reihenfolge für die Umstellung und für jeden Schritt einen Rollback-Punkt fest. |
Migration | Verschieben Sie die Daten, bauen Sie neu, was neu gebaut werden muss, und validieren Sie gegen das Quellsystem, bevor sich jemand auf das neue verlässt. |
Parallelbetrieb | Halten Sie beide Systeme live und vergleichen Sie die Ergebnisse, bis das Vertrauen für die Umstellung hoch genug ist. |
Umstellung und Abschaltung | Stellen Sie die Nutzer um und schalten Sie das alte System dann planmäßig ab, nicht sofort. |
Häufige Probleme und ihre Ursachen
Kein Verantwortlicher für die Entscheidungsregel. Ohne vereinbarte Rehost-/Replatform-/Refactor-Regel pro Workload migrieren verschiedene Personen ähnliche Dinge unterschiedlich, und der Bestand ist am Ende schwerer zu pflegen als vor der Migration.
Den Parallelbetrieb überspringen. Die Umstellung, bevor das neue System mindestens einen vollen Reporting-Zyklus gegen das alte validiert wurde, ist die häufigste Ursache dafür, dass eine Migration teilweise wiederholt werden muss.
Das Gateway als verzichtbar behandeln. Das lokale Datengateway, das die alten Reports speiste, wird während der Migration oft noch gebraucht, weil die neue Pipeline dieselbe lokale Quelle erreichen muss, bevor etwas umzieht.
FAQs
Was ist eine Cloud-Migrationsstrategie?
Es ist der dokumentierte Plan, welche Workloads in die Cloud ziehen, wie jeder einzelne umzieht (Rehost, Replatform oder Refactor) und in welcher Reihenfolge, damit die Migration nicht zu spontanen Entscheidungen mitten im Projekt wird.
Was ist der Unterschied zwischen Rehosting und Replatforming?
Rehosting verschiebt einen Workload ohne strukturelle Änderung. Replatforming verschiebt ihn und ersetzt einzelne Teile durch ein cloudnatives Gegenstück, etwa ein Power-BI-Modell auf ein Fabric Warehouse statt auf eine lokale SQL-Server-Instanz zu richten, ohne das Modell selbst neu zu bauen.
Wie lange sollte ein Parallelbetrieb vor der Umstellung dauern?
Lange genug, um mindestens einen vollen Reporting-Zyklus auf dem neuen System abzudecken und bei jeder Aktualisierung seine Ergebnisse mit dem alten zu vergleichen, sodass eine Abweichung auffällt, bevor sich jemand nachgelagert auf die neuen Zahlen verlässt.
Quellen
Cloud Adoption Framework: migrate methodology - Microsoft Learn
OneLake overview - Microsoft Learn
