AS/400-Wartung 2026: Was tun wenn das IBM-i-System altert
Die AS/400-Wartung ist in vielen Unternehmen eine stille Angelegenheit. Das System läuft. Es verarbeitet Aufträge, Lagerbestände und Rechnungen. Seit zwanzig Jahren, manchmal seit dreißig. Und genau deshalb schaut kaum jemand hin.
Bis der Kollege in Rente geht, der als Einziger wusste, wie die Nachtverarbeitung funktioniert.
Dieser Artikel erklärt, warum AS/400-Systeme technisch selten das Problem sind. Und warum die Wartung trotzdem zunehmend schwierig wird. Wir zeigen Ihnen die realistischen Optionen für 2026.
Was ist die AS/400 heute eigentlich?
Kurz zur Einordnung, denn die Namen verwirren.
IBM brachte die AS/400 im Jahr 1988 auf den Markt. AS steht für "Application System". Die Plattform wurde später mehrfach umbenannt: erst iSeries, dann System i, heute IBM i auf Power-Hardware.
Viele Anwender sagen weiterhin AS/400. Gemeint ist meist dasselbe: eine integrierte Plattform aus Betriebssystem, Datenbank (Db2 for i) und Anwendungslogik. Häufig in RPG oder COBOL geschrieben.
IBM i ist kein totes Produkt. IBM entwickelt die Plattform aktiv weiter und veröffentlicht regelmäßig neue Releases. Wer von einem "abgekündigten System" spricht, liegt falsch.
Das Problem liegt woanders.
Warum die AS/400-Wartung 2026 schwieriger wird
Die Hardware ist robust. Die Software ist stabil. Trotzdem melden sich Unternehmen bei uns, weil die Betreuung ins Wanken gerät. Dafür gibt es vier Gründe.
Das Wissen geht in Rente
Die Menschen, die diese Systeme gebaut haben, sind heute zwischen 55 und 70. Viele davon haben ihr gesamtes Berufsleben auf einer Plattform verbracht. Dieses Wissen ist wertvoll und schwer zu ersetzen.
RPG wird an deutschen Hochschulen praktisch nicht mehr unterrichtet. Der Nachwuchs kommt mit Java, Python und JavaScript. Wer heute einen IBM-i-Entwickler sucht, sucht lange.
Das ist kein AS/400-Problem allein. Wir beschreiben es ausführlicher im Artikel kein Entwickler für alten Code. Bei IBM i ist der Effekt aber besonders deutlich, weil der Kreis der Fachleute klein ist.
Die Hardware kommt in die Jahre
Power-Systeme laufen lange. Aber sie laufen nicht ewig.
IBM legt für jede Hardware-Generation ein Support-Ende fest. Danach gibt es keine Ersatzteile mehr aus offiziellen Quellen und keine Firmware-Updates. Ältere Power7- und Power8-Maschinen haben diesen Punkt erreicht oder nähern sich ihm.
Was End of Life bei Hardware praktisch bedeutet, haben wir im Beitrag zum Hardware-Lifecycle beschrieben. Kurz gesagt: Der Betrieb bleibt möglich, das Risiko steigt.
Betriebssystem-Releases laufen aus
Auch IBM i selbst hat einen Lebenszyklus. Ältere Releases wie 7.2 sind seit Jahren ohne Support. Wer darauf noch produktiv arbeitet, bekommt keine Sicherheits-Patches mehr.
Das ist relevant, sobald das System mit dem Netz spricht. Und das tun heute fast alle AS/400-Installationen, sei es über Schnittstellen zu Webshops, Speditionen oder Buchhaltung.
Die Dokumentation existiert nur im Kopf
Über dreißig Jahre wächst jede Anwendung. Sonderfälle werden eingebaut. Ausnahmen für einzelne Kunden. Workarounds für Probleme, die längst gelöst sind.
Dokumentiert wurde davon selten etwas. Das Wissen sitzt in Köpfen und in ein paar Textdateien. Das ist eine Form von technischen Schulden, die man erst bemerkt, wenn der Zugriff darauf wegfällt.
Was passiert, wenn Sie nichts tun?
Die ehrliche Antwort: erst einmal nichts. Und das ist die Falle.
AS/400-Systeme fallen nicht plötzlich aus. Sie verschlechtern sich langsam. Das Risiko wächst still, ohne Warnsignal.
Der Ausfall trifft Sie zum ungünstigsten Zeitpunkt. Wenn ein Netzteil stirbt und kein Ersatz verfügbar ist, steht die Auftragsabwicklung. Nicht für Stunden, sondern für Tage.
Die Handlungsfähigkeit sinkt. Ohne jemanden, der den Code versteht, wird jede Anpassung zum Projekt. Eine neue Mehrwertsteuerregel, eine neue Schnittstelle, ein neues Meldeformat: alles wird teuer und langsam.
Die Verhandlungsposition wird schlechter. Wer unter Zeitdruck einen IBM-i-Spezialisten sucht, zahlt Notfallpreise. Wer zwei Jahre Vorlauf hat, sucht in Ruhe.
Compliance wird zum Thema. Ein System ohne Sicherheits-Patches, das personenbezogene Daten verarbeitet, ist DSGVO-technisch schwer zu verteidigen. Spätestens bei einem Vorfall stellt die Aufsichtsbehörde genau diese Frage.
Ihre Optionen für die AS/400-Wartung
Es gibt keinen richtigen Weg für alle. Es gibt vier Wege, und einer davon passt zu Ihrer Situation.
Option 1: Weiterbetreiben und absichern
Das System bleibt. Sie sorgen dafür, dass der Betrieb belastbar wird.
Konkret heißt das: IBM-i-Release auf eine unterstützte Version heben. Hardware auf eine aktuelle Power-Generation umziehen. Backup- und Restore-Prozess einmal vollständig testen, nicht nur auf dem Papier.
Dazu gehört ein Wartungsvertrag mit klaren Reaktionszeiten. Und mindestens zwei Menschen, die im Ernstfall handlungsfähig sind.
Das ist der günstigste Weg, wenn die Anwendung fachlich passt. Und das tut sie überraschend oft.
Option 2: Drittwartung für die Hardware
Wenn IBM den Support für Ihre Maschine beendet hat, ist der Betrieb nicht zwangsläufig vorbei. Drittanbieter warten Power-Hardware über das offizielle Ende hinaus. Sie halten Ersatzteile vor und stellen Techniker.
Das kostet deutlich weniger als ein Hardware-Tausch. Es verschafft Ihnen Zeit, typischerweise drei bis fünf Jahre.
Die Grenzen sollten Sie kennen. Drittwartung deckt Hardware ab, nicht das Betriebssystem. Firmware-Updates und IBM-i-Patches bekommen Sie darüber nicht. Als Brücke funktioniert das gut, als Dauerlösung nicht.
Option 3: Wissen sichern und Betreuung neu aufstellen
Der oft unterschätzte Schritt. Bevor Sie über Technik reden, sichern Sie das Wissen.
Das bedeutet: Programme inventarisieren. Schnittstellen dokumentieren. Die kritischen Batch-Läufe beschreiben. Aufschreiben, welche Programme welche Datenbank-Tabellen anfassen.
Wir übernehmen genau solche Bestandsaufnahmen im Rahmen der Software-Wartung. Der Aufwand liegt meist bei wenigen Wochen. Der Nutzen hält Jahre.
Wichtig: Machen Sie das, solange der erfahrene Kollege noch im Haus ist. Danach wird es deutlich teurer.
Option 4: Modernisieren oder ablösen
Wenn die Anwendung fachlich nicht mehr trägt, hilft Absichern nur begrenzt. Dann geht es um Veränderung.
Dafür gibt es abgestufte Wege. Sie können RPG-Code auf der Plattform modernisieren, etwa von starrem RPG III auf freies RPG IV. Sie können einzelne Funktionen herauslösen und neu bauen, während der Rest weiterläuft. Oder Sie ersetzen die Anwendung durch eine Standardlösung.
Was fast nie funktioniert: alles auf einmal neu bauen. Solche Projekte scheitern regelmäßig, weil das fachliche Wissen in dreißig Jahren Code steckt und nirgends sonst.
Ein schrittweiser Umbau ist realistischer. Wie das aussieht, beschreiben wir bei der Migration und im Artikel zur Wartung von Java-EE-Anwendungen, wo das gleiche Prinzip gilt.
So gehen Sie die nächsten Monate an
Ein pragmatischer Fahrplan, ohne Beratersprache.
Schritt 1: Bestand aufnehmen. Welche Hardware-Generation läuft? Welches IBM-i-Release? Bis wann gibt es Support?
Schritt 2: Personenrisiko klären. Wer kann das System betreuen? Wie lange ist diese Person noch da? Was passiert bei Krankheit?
Schritt 3: Wissen festhalten. Interviews führen, mitschreiben, ablegen. Auch unvollständig ist besser als gar nicht.
Schritt 4: Fachliche Zukunft bewerten. Erfüllt die Anwendung noch, was das Geschäft braucht? Oder arbeiten Menschen längst mit Excel daneben?
Schritt 5: Entscheiden und terminieren. Absichern, überbrücken oder umbauen. Mit Datum, Budget und Verantwortlichem.
Diese fünf Schritte kosten Sie ein paar Wochen. Sie ersparen Ihnen im Zweifel ein Notfallprojekt.
Fazit: Alte Systeme sind kein Fehler
Eine AS/400, die seit dreißig Jahren zuverlässig läuft, ist kein Versäumnis. Sie ist ein Beleg dafür, dass damals jemand gut gearbeitet hat.
Das Problem ist nicht das Alter des Systems. Das Problem ist, dass die Betreuung nicht mitgewachsen ist. Genau das lässt sich reparieren, und zwar planbar.
Sie müssen sich nicht zwischen "alles bleibt" und "alles neu" entscheiden. Zwischen diesen Polen liegen mehrere gangbare Wege. Welcher zu Ihnen passt, hängt von Hardware, Personal und fachlichem Bedarf ab.
Wir betreuen Legacy Software, die andere ablehnen. Auch dann, wenn die Dokumentation dünn und der letzte Entwickler längst weg ist.
Sprechen Sie uns an. Wir schauen uns Ihre Situation an und sagen ehrlich, was sinnvoll ist. Das Erstgespräch ist kostenlos und unverbindlich.
