Das Finance-DWH lief on-premises auf einer gewachsenen MS-SQL-Server-Landschaft: SSIS-Pakete zogen und transformierten die Daten, T-SQL-Stored-Procedures trugen die Geschäftslogik, SSAS-Cubes lieferten die multidimensionalen Auswertungen und SSRS die Standardberichte. Als zentrale Finance-Plattform band es Daten aus vielen Business Units und heterogenen Quellsystemen an: Salesforce, SAP R/3, SAP S/4HANA, Teradata und weitere. Über Jahre waren daraus 90+ Pipelines und Use Cases entstanden, jede mit eigener Historie, eigenen Abhängigkeiten und eigenen Workarounds. Die Systeme funktionierten, aber die Belastung stieg schneller als die verfügbare Kapazität. Reporting-Zyklen wurden enger, Datenmengen größer, Anforderungen an Aktualität höher.
Neue Analytics-Anforderungen aus dem Finance-Bereich landeten auf einer Infrastruktur, die weder für moderne Workloads noch für die anfallenden Datenmengen ausgelegt war. Skalieren bedeutete: teurer Server, mehr Wartung, gleiche Architektur. Optimieren bedeutete: einzelne Skripte umbauen, ohne die Gesamtlage zu verbessern. Jede Anfrage aus dem Fachbereich kostete Ressourcen, jeder Ausfall kostete Reporting-Fenster.
Dem Team fehlte die Erfahrung mit Databricks und Lakehouse-Konzepten, um die Modernisierung selbst zu starten. Das Wissen war intern schlicht nicht vorhanden, und der Alltag ließ keinen Raum, es sich nebenbei anzueignen. Externe Beratungsprojekte hatten in der Vergangenheit einzelne Punkte gelöst, den strukturellen Umbau aber nicht in Gang gebracht.
Die eigentliche Frage betraf den Weg: Wie migriert man ein gewachsenes DWH mit 90+ Pipelines strukturiert, ohne den laufenden Betrieb zu gefährden und ohne dass die Migration im nächsten Reorg wieder auf Halde landet?
Solange das DWH auf einer Infrastruktur läuft, die weder skaliert noch von einem erfahrenen Team gepflegt wird, entscheidet der Zufall, wann der nächste Ausfall die Reports blockiert.
