Power BI Report Server statt Crystal Reports: Druck und Dashboards im eigenen Netz.

Die Frage kommt aus drei Richtungen: Datenschutz (personenbezogene Daten in Berichten, Betriebsvereinbarungen), Regulierung (Bankaufsicht, Gesundheitsdaten, kritische Infrastruktur) und schlicht Vertragslage (ein Konzern erlaubt keine Cloud-Freigabe für diese Datenklasse). In allen drei Fällen scheidet der Power-BI-Dienst als Ziel aus, und Crystal Reports verliert trotzdem am 31. Dezember 2026 die Mainstream-Wartung.

Power BI Report Server ist Microsofts Antwort darauf: dieselbe Berichtstechnik wie im Dienst, aber auf Servern, die Sie betreiben. Er trägt paginierte Berichte (RDL, die Nachfolger der Crystal-Druckberichte) und interaktive Berichte (PBIX) in einem Portal mit Ordnern, Berechtigungen, Abonnements und Zeitplänen. Was er nicht hat: die Dienstfunktionen der letzten Jahre wie Dataflows, Copilot, Fabric-Artefakte, und er bekommt neue Power-BI-Features mit Verzögerung in drei Releases pro Jahr.

Deshalb ist die Entscheidung keine Glaubensfrage, sondern eine Datenklassen-Frage: Welche Berichte tragen Daten, die das Haus nicht verlassen dürfen? Oft sind es wenige; dann läuft Report Server für diese Berichte, und der Rest darf später in den Dienst oder nach Fabric. Der Entscheidungsbaum im Arbeitsmaterial führt durch genau diese Abwägung.

• Report Server passt, wenn Daten rechtlich oder vertraglich on-premises bleiben müssen, wenn Druck und PDF den Alltag bestimmen und wenn SQL Server Enterprise mit Software Assurance ohnehin lizenziert ist.
• Der Dienst passt, wenn Self-Service, Dataflows, Copilot oder Teilen mit Externen gebraucht werden und die Datenklasse es erlaubt.
• Hybrid passt, wenn nur eine Datenklasse im Haus bleiben muss: Report Server für diese, Dienst für den Rest, verbunden über das Gateway.

Der häufigste Fehler bei Crystal-Ablösungen ist der Versuch, aus jedem Bericht ein Dashboard zu machen. Eine Rechnung, ein Lieferschein, ein Monatsabschluss mit fester Seitenstruktur und Summen je Seite ist ein Druckbericht und bleibt einer: als paginierter RDL-Bericht, gebaut im Report Builder, mit Abonnement und PDF-Export. Steuerung, KPI und Drilldown sind der zweite Korb: interaktive PBIX-Berichte auf einem semantischen Modell. Beide liegen im selben Portal, der Nutzer merkt den Unterschied nur am Verhalten.

Die Tabelle zeigt, was aus den Crystal-Objekten wird. Entscheidend ist die Zeile Formeln: Was in Crystal je Bericht als Formel existiert, wird einmal als Measure im Modell gebaut und von RDL und PBIX gleichermaßen genutzt. Das ist der Punkt, an dem drei Berichte aufhören, drei Werte zu zeigen.

Report Server wird nicht einzeln verkauft. Es gibt zwei Wege: Er ist in Fabric-Kapazitäten ab F64 enthalten, dem Nachfolger der Premium-P-SKUs, oder er kommt mit SQL Server Enterprise Edition und aktiver Software Assurance, mit so vielen Kernen, wie der Report Server nutzt. In beiden Fällen brauchen die Personen, die Berichte veröffentlichen, eine Pro-Lizenz; reine Leser nicht.

Welcher Weg günstiger ist, hängt davon ab, was schon im Haus ist: Wer SQL Server Enterprise mit Software Assurance betreibt, zahlt für Report Server oft nichts zusätzlich. Wer ohnehin Fabric-Kapazität plant, bekommt Report Server als Beigabe. Die Lizenzseite von Microsoft ändert sich; DBI prüft die Stufe im Scoping gegen den aktuellen Stand und schreibt das Ergebnis ins Angebot.

Wer heute SQL Server Reporting Services betreibt, hat die einfachste Migration: SSRS-Kataloge wandern direkt auf Power BI Report Server, die RDL-Berichte bleiben, dazu kommt der PBIX-Korb. Crystal-Berichte wandern nicht, sie werden neu gebaut, deshalb lohnt der Blick auf SSRS als Zwischenziel nicht. Die Entscheidung heißt: SSRS weiterbetreiben (nur RDL, kein PBIX, Support an SQL Server gekoppelt) oder Report Server (beides, eigener Releasezyklus).

Bei einem Lebensmittelhersteller haben wir beide Wege inklusive Lizenzkosten durchgerechnet, bevor entschieden wurde: SSRS behalten und die Druckberichte modernisieren, oder Report Server mit interaktiven Berichten für die Werke. Die Rechnung gehört vor die Entscheidung, nicht in den Nachtrag. Mit dem Supportende von SQL Server 2016 im Juli 2026 ist SSRS 2016 ohnehin kein Ziel mehr.

Das On-Premises Data Gateway verbindet lokale Quellen mit dem Power-BI-Dienst. Für den reinen Report-Server-Pfad ist es nicht nötig: Report Server und Quellen stehen im selben Netz. Es wird erst gebraucht, wenn Teile der Organisation den Dienst nutzen dürfen und dort Berichte auf lokale Daten zugreifen, also im Hybridbetrieb. Dann läuft das Gateway als Cluster mit zwei Knoten, mit Dienstkonto, Protokollierung und einem Verantwortlichen für die Zeitpläne.

Die Architekturregel aus unseren Projekten: Erst entscheiden, welche Datenklassen im Haus bleiben; dann Report Server für diese Berichte; dann, falls gewünscht, Gateway und Dienst für den Rest. Wer mit dem Gateway anfängt, baut die Ausnahme vor der Regel.

Ausgangslage: ein gewachsenes Reporting auf Dynamics AX, dessen Logik niemand mehr vollständig kannte, und die Vorgabe, dass Produktions- und Finanzdaten das Haus nicht verlassen. Wir haben das alte Reporting reverse-engineered, ein Data Warehouse mit SSIS und Logging aufgebaut und Power BI Report Server auf zwei VMs des Kunden installiert: paginierte Berichte für den Monatslauf, interaktive Berichte für Vertrieb und Controlling.

Ergebnis nach acht Monaten: produktiv, ein Fehler in 25 Tickets, Übergabe an die eigene IT mit Betriebshandbuch. Der Aufwand lag nicht im Report Server, sondern in der Logik des Altsystems; genau dort setzt heute das Inventar mit ABIS an, das diese Arbeit vorzieht und zählbar macht.

• Plattform: Report Server auf zwei Kunden-VMs, SQL Server Enterprise, SSIS-Warehouse mit Logging.
• Berichte: Monatslauf paginiert, Steuerung interaktiv, beides im selben Portal mit Ordnerrechten.
• Qualität: 1 Fehler in 25 Tickets; Abnahme je Bericht gegen die Zahlen des Altsystems.

Bevor Crystal-Schedules abgeschaltet werden, prüfen wir je Druckbericht acht Punkte. Die Liste ist kurz, aber jeder Punkt hat in Projekten schon einen Monatsabschluss gekostet, wenn er fehlte.

• Zahlenabgleich je Parameterkombination gegen den Crystal-Bericht, dokumentiert mit Datum und Datenstand.
• Abonnements und Zeitpläne übertragen: Empfänger, Format, Uhrzeit, Fehlerbenachrichtigung.
• Seitenlayout: Ränder, Seitenumbrüche, Kopf- und Fußzeilen, Summen je Seite und am Ende.
• Parameterketten: Kaskaden, Standardwerte, Pflichtparameter, Verhalten bei leerem Ergebnis.
• Exportformate: PDF, Excel, CSV wie bisher; Dateinamen und Spaltenbreiten geprüft.
• Berechtigungen: Ordnerrechte im Portal entsprechen den Crystal-Gruppen; Datenrechte über RLS im Modell.
• Betrieb: Dienstkonto, Backup der Report-Server-Datenbank, Logging, Verantwortlicher für Updates.
• Rollback: Crystal bleibt bis zur Abnahme lauffähig; Abschaltung erst nach zwei fehlerfreien Monatsläufen.