SSRS-Migration mit AI: So bringt Ihr Eure Berichte nach Power BI und die Logik in die Datenplattform

Autor:in: Paul Christ
Lesezeit: 5 Minuten
Ein junger Mann mit Brille in einem schwarzen Anzug vor einem unscharfen Hintergrund.

Zusammenfassung: SSRS 2016 ist seit Juli 2026 ohne Support und SSRS 2022 ist die letzte Version, die aber auch 2033 ausläuft. Wer jetzt migriert, sollte nicht nur die Berichte umziehen, sondern auch die Geschäftslogik in die Datenplattform holen. So geht Ihr vor, und so teilen sich AI, Skript und Mensch die Arbeit.

SSRS läuft aus: Warum das Thema jetzt auf den Tisch gehört

Microsoft hat das Ende von SQL Server Reporting Services (SSRS) klar terminiert:

  • SSRS 2016 ist seit dem 14. Juli 2026 ohne Support. Kostenpflichtige Extended Security Updates verschaffen Zeit bis Juli 2029, lösen das Problem aber nicht.
  • SSRS 2017 endet am 12. Oktober 2027.
  • SSRS 2019 am 8. Januar 2030.
  • SSRS 2022 läuft bis zum 11. Januar 2033 und ist die letzte Version. Ab SQL Server 2025 übernimmt der Power BI Report Server.
Abbildung 1: Support-Ende der SSRS-Versionen (eigene Darstellung nach Angaben von Microsoft)

Zwei Ziele: Power BI Report Server oder Power BI Service

Für SSRS-Berichte (paginierte Berichte, also seitengenaue Berichte zum Drucken und Exportieren) gibt es bei Microsoft zwei Nachfolger:

  • Power BI Report Server: der Nachfolger im eigenen Rechenzentrum.
  • Power BI Service: der Weg in die Cloud, direkt neben Euren Power-BI-Berichten.

In beide lassen sich die Berichtsdateien (.rdl) weitgehend eins zu eins umziehen. Das geht schnell, löst aber das eigentliche Problem nicht: Die Logik bleibt in jedem einzelnen Bericht. Wir zeigen deshalb den Weg in den Power BI Service, bei dem die Logik in die Datenplattform wandert. Das macht Euch auch bereit für AI: Sauber definierte Kennzahlen an einer Stelle können auch AI-Anwendungen direkt nutzen.

Das eigentliche Problem: Die Logik steckt in den Berichten

In SSRS hat jeder Bericht sein eigenes SQL. Über die Jahre wird es kopiert und angepasst, bis dieselbe Kennzahl in drei Berichten auf drei Arten gerechnet wird. Dazu kommen Custom Assemblies (eigene DLL-Dateien mit Programmcode), die im Power BI Service gar nicht laufen.

Die Lösung: Die Geschäftslogik zieht in Views (gespeicherte Abfragen) in der Datenplattform. Der Bericht behält Layout und Parameter und holt seine Daten nur noch aus diesen Views. Abos richtet Ihr im Power BI Service neu ein. Das bringt Euch:

  • Eine Definition je Kennzahl statt Kopien in Dutzenden Berichten.
  • Prüfbarkeit: Views lassen sich testen, versionieren und reviewen.
  • Wiederverwendung: Auch Eure Power-BI-Semantikmodelle können die Views nutzen.
  • Tempo: Werden die Parameter bis in die Abfrage durchgereicht, filtert die Datenplattform statt des Berichts.

Das funktioniert mit Databricks genauso wie mit Snowflake, Fabric oder Azure SQL.

Abbildung 2: Vorher steckt die Logik in jedem Bericht, nachher zentral in Views der Datenplattform.

Der Ablauf: Skript, AI und Mensch

Was feste Regeln hat, macht ein Skript. Wo Verständnis gefragt ist, arbeitet AI. Was entschieden werden muss, entscheidet ein Mensch. Und: AI prüft nie ihre eigene Arbeit. Ob die Zahlen stimmen, belegt ein Skript.

Abbildung 3: Der Ablauf in sieben Schritten, farbig nach Rolle.
  1. Inventar: Berichte, Abos und Nutzung auslesen und nach Aufwand einteilen. Was niemand nutzt, fällt weg.
  2. Logik-Katalog: gleiche und abweichende Logik finden, Views vorschlagen.
  3. Freigabe: Der Fachbereich entscheidet, welche Rechnung gilt.
  4. Views: AI schreibt das SQL, ein Skript legt die Views an und prüft Kontrollsummen.
  5. Berichte umbauen: neue Datenquelle, das Layout bleibt.
  6. Zahlenvergleich: alt gegen neu, Zelle für Zelle.
  7. Veröffentlichen und Abnahme: Upload per Schnittstelle, Stichprobe, Parallelbetrieb.

Wo AI den Unterschied macht

AI ist überall dort stark, wo viel Code gelesen, verglichen und übersetzt werden muss:

  • Logik verstehen: Sie liest Berichte, SQL und Stored Procedures und zeigt, wo dieselbe Kennzahl unterschiedlich berechnet wird.
  • Risiken erkennen: SQL Server ignoriert Groß-/Kleinschreibung meist, andere Datenplattformen oft nicht. Gleiche Abfragen liefern dort dann andere Zahlen.
  • Views schreiben: im SQL der Zielplattform, nach Themen statt je Bericht.
  • Umbau beschreiben: je Bericht, welche Daten und Parameter er braucht. Ein Skript baut daraus die neue Datei. Mit diesem Vorgehen braucht Ihr den Report Builder nur noch für Sonderfälle.
  • Abweichungen erklären: Oft liegen sie genau dort, wo der Fachbereich bewusst vereinheitlicht hat.
Abbildung 4: Wer macht was: Skript, AI und Mensch.

Was beim Menschen bleibt

  • Fachliche Entscheidungen: welche Definition künftig gilt.
  • Review: Ein Mensch liest das SQL jeder View, bevor sie produktiv geht.
  • Abnahme: durch die Menschen, die täglich mit den Berichten arbeiten.
  • Organisation: Workspaces, Rechte, Lizenzen, Tenant-Einstellungen und Abos.

AI ersetzt keine Fachleute. Sie verschafft ihnen Zeit für die Fragen, die nur sie beantworten können.

Drei Stolpersteine

  1. Alles eins zu eins übernehmen: Viele Berichte nutzt kaum noch jemand. Was niemand braucht, migriert Ihr nicht.
  2. Abweichende Zahlen nicht erklären: Wird Logik vereinheitlicht, ändern sich Zahlen, oft zu Recht. Dokumentiert, warum, und sagt es den Nutzern früh.
  3. Annehmen, dass alles in der Cloud läuft: Manche SSRS-Funktionen gibt es im Power BI Service nicht oder nur anders, etwa eigene Programmbibliotheken oder datengesteuerte Abos. Prüft das vor dem Umbau.

Fazit

Das Ende von SSRS steht fest. Nutzt die Migration, um gewachsene Logik aufzuräumen und an einer Stelle zu bündeln. AI übernimmt die Fleißarbeit, Skripte machen jeden Schritt belegbar, Menschen entscheiden. Das Ergebnis: Berichte, die weitgehend aussehen wie immer, aber auf einer sauberen, prüfbaren Logik stehen.

Ist die Ablösung von SSRS bei Euch ein Thema?

Dann meldet Euch gern. Wir sprechen in einem Termin darüber, wie das bei Euch aussehen kann.

Jetzt unverbindliche Beratung anfragen

Ähnliche Beiträge