Crystal Reports verliert 2026 die Wartung: zählen, sortieren, migrieren.

Mainstream-Wartung heißt bei SAP: Support Packages, Sicherheitskorrekturen, Anpassungen an neue Betriebssysteme und Datenbanktreiber. Mit dem Stichtag endet das für Crystal Reports 2020 und Crystal Server 2020; am selben Tag endet die Wartung für SAP BusinessObjects BI 4.3, auf dessen Plattform viele Crystal-Installationen laufen. Crystal Reports 2025 bekommt ein Jahr mehr, bis zum 31. Dezember 2027. Die Termine stammen aus der SAP Product Availability Matrix und werden vor jeder Entscheidung dort geprüft.

Praktisch bedeutet das drei Risiken, die nicht am Stichtag eintreten, sondern danach, eines nach dem anderen: Ein Windows-Update bricht die Runtime auf dem Druckserver. Ein Datenbank-Upgrade verändert einen Treiber, und Berichte liefern leere Seiten. Und der Kollege, der die 400 Formeln eines Monatsberichts erklären konnte, geht in Rente. Keines dieser Risiken lässt sich mit einem Supportvertrag kaufen; alle drei verschwinden, sobald die Logik in einem semantischen Modell liegt, das jemand lesen kann.

Der Stichtag ist deshalb weniger Deadline als Takt: Wer im ersten Quartal 2026 zählt, hat bis Dezember zwei bis drei Wellen abgenommen und Crystal für den Rest in einem kontrollierten Parallelbetrieb.

Crystal-Berichte bestehen aus wenigen Objektarten, und jede hat ein Gegenstück oder eine klare Entscheidung. Die Tabelle ist die Grundlage des Inventars: ABIS zählt je .rpt, wie viele Objekte je Zeile vorkommen, und daraus entsteht die Komplexitätsklasse des Berichts. Entscheidend ist die Logik in Formeln und Record Selection; sie wandert ins semantische Modell und existiert danach einmal statt in jedem Bericht.

Kein Bericht wird eins zu eins nachgebaut. Jeder bekommt einen von drei Pfaden, und die Entscheidung folgt drei Fragen: Wird er gedruckt oder als PDF verschickt? Wird er gefiltert und zum Nachbohren genutzt? Wurde er in den letzten 18 Monaten überhaupt geöffnet? Die Antworten liefert das Inventar aus Nutzungsdaten des Crystal Servers und Fileshare-Zugriffen, nicht ein Workshop, in dem jeder seinen Bericht für unverzichtbar erklärt.

Erfahrungswert aus Inventaren der letzten Jahre: 50 bis 60 Prozent der Berichte sind direkter Rebuild, 25 bis 35 Prozent haben Formeln, Unterberichte oder Cross-Tabs, die Aufwand brauchen, 10 bis 15 Prozent sind Redesign wegen UFL, COM oder Layout-Sonderfällen. Ein Viertel bis ein Drittel des Bestands wird abgeschaltet, weil ihn niemand mehr öffnet oder weil er die dritte Variante derselben Liste ist.

Eine Schätzung für 1.000 Crystal Reports ist entweder zu hoch, weil sie das Risiko einpreist, oder zu niedrig, weil sie die Unterberichte nicht kennt. Ein Inventar ist beides nicht. ABIS liest jede .rpt-Datei strukturell und zählt je Bericht Formeln, Record Selection, Parameter, Unterberichte, Datenquellen; dazu kommt die Nutzung aus dem Crystal Server. Daraus entstehen Cluster: Berichte mit denselben Parametern und Views sind Varianten, nicht Einzelstücke, und ein Cluster wird einmal gebaut.

Zwei Angebote aus diesem Jahr zeigen den Unterschied. Für einen Banken-IT-Dienstleister mit rund 1.000 Crystal Reports ohne Inventar haben wir die Vermessung je Bericht vor das Angebot gestellt, Migration in Wellen bei parallel laufendem Crystal. Für einen Industriekonzern mit rund 80 paginierten Berichten lag der gezählte Festpreis bei rund der Hälfte der konventionellen Schätzung, mit Deckel, und eine Überschreitung trägt DBI. Beides sind Angebote, keine abgeschlossenen Projekte; die Methode ist dieselbe wie im abgeschlossenen Maschinenbau-Projekt.

• Schritt 1: Bestand sammeln (Fileshares, Crystal Server, Anwendungen mit eingebetteten Berichten).
• Schritt 2: Jede .rpt strukturell lesen, Objekte zählen, Datenquellen auflösen.
• Schritt 3: Nutzung je Bericht aus Server-Protokollen und Zugriffen der letzten 18 Monate.
• Schritt 4: Cluster bilden, Pfad je Bericht vorschlagen, Besitzer bestätigen.
• Schritt 5: Festpreis je Welle, Wellen nach Fachdomäne und Druckkalender, Parallelbetrieb eingeplant.

Beide liefern pixelgenaue, mehrseitige Druckberichte. Der Unterschied liegt nicht im Ausdruck, sondern darunter: Paginated Reports laufen im Power-BI-Dienst oder auf Power BI Report Server, lesen das semantische Modell oder eine Datenbank direkt, brauchen keine Crystal-Runtime auf Druckservern und werden mit demselben Berechtigungsmodell verwaltet wie die interaktiven Berichte. Crystal-Formeln werden dabei Measures oder Ausdrücke; was einmal im Modell liegt, rechnet in Druck und Dashboard gleich.

Ein Maschinen- und Anlagenbauer betrieb eine gewachsene Landschaft aus SAP-Crystal-Reports: Fertigungsaufträge, Lieferpapiere, Qualitätsnachweise, dazu Auswertungen, die über die Jahre aus Druckberichten herausgewachsen waren. Wir haben die rund 120 Berichte strukturell eingelesen, Formeln und Unterberichte automatisch extrahiert und je Bericht den Pfad festgelegt. Die Druckberichte wurden Power BI Paginated Reports auf einem gemeinsamen Modell, die Steuerungsberichte interaktiv.

Die automatische Metadatenextraktion sparte gegenüber manueller Analyse rund 40 Prozent der Migrationskosten; Crystal lief parallel, bis jede Welle gegen die Altzahlen abgenommen war. Die vollständige Fallstudie beschreibt Ausgangslage, Vorgehen und Ergebnis.

Der Fahrplan geht von einem mittleren Bestand aus, 200 bis 500 Berichte, und davon, dass der Monatsabschluss der kritische Pfad ist. Größere Bestände bekommen mehr Wellen, nicht längere. Alles vor der ersten Welle ist Inventar; alles nach der letzten Abnahme ist Abschaltung mit Rollback.