COBOL und RPG in 2026: Warum alte Programmiersprachen nicht verschwinden
COBOL 2026 klingt nach einem Widerspruch. Eine Sprache aus dem Jahr 1959, die im Jahr 2026 noch produktiv läuft. Trotzdem ist genau das die Realität in vielen Banken, Versicherungen und Industriebetrieben.
Ihre Buchung am Geldautomaten läuft mit hoher Wahrscheinlichkeit durch COBOL-Code. Ihre Lohnabrechnung womöglich auch. Und in tausenden Mittelstandsbetrieben verarbeitet RPG auf IBM-i-Systemen Aufträge, Lagerbestände und Rechnungen.
Seit dreißig Jahren wird das Ende dieser Sprachen angekündigt. Sie laufen weiter. Dieser Artikel erklärt, warum das so ist, welche Risiken daraus entstehen und wann ein Umstieg wirklich Sinn ergibt.
Was COBOL und RPG überhaupt sind
COBOL steht für "Common Business Oriented Language". Die Sprache wurde 1959 für kaufmännische Anwendungen entwickelt. Ihre Stärke: exakte Rechenoperationen mit Dezimalzahlen. Genau das braucht man im Finanzwesen.
Moderne Sprachen rechnen intern oft mit Fließkommazahlen. Dabei entstehen winzige Rundungsfehler. Bei Milliarden von Transaktionen summieren sich diese Fehler. COBOL hat dieses Problem nicht, weil es von Anfang an anders rechnet.
RPG heißt ursprünglich "Report Program Generator". Die Sprache stammt von IBM und läuft auf der Plattform IBM i, früher bekannt als AS/400. Sie ist eng mit der integrierten Datenbank des Systems verwoben. Wir haben die Besonderheiten dieser Plattform im Artikel AS/400-Wartung: Wenn IBM i altert ausführlicher beschrieben.
Beide Sprachen haben eine Eigenschaft gemeinsam. Sie wurden für Stabilität gebaut, nicht für Mode.
Warum diese Sprachen nicht verschwinden
Der Code funktioniert einfach
Ein COBOL-Programm aus dem Jahr 1994 läuft heute noch. Ohne Abstürze. Ohne Sicherheitslücken durch fremde Bibliotheken, weil es kaum fremde Bibliotheken nutzt. Es hat vier Jahrzehnte Fehlerkorrekturen hinter sich.
Neue Software ist selten so zuverlässig. Jede Neuentwicklung bringt neue Fehler mit. Bei einem System, das den Zahlungsverkehr abwickelt, ist das ein ernstes Argument.
Die Geschäftslogik steckt im Code, nicht in Dokumenten
Das ist der eigentliche Grund. In diesen Programmen stecken Regeln, die niemand mehr vollständig beschreiben kann. Sonderfälle aus Tarifverträgen. Steuerregelungen aus verschiedenen Jahrzehnten. Ausnahmen für einzelne Großkunden.
Vieles davon steht nirgendwo dokumentiert. Der Code ist die Dokumentation. Wer ihn ersetzen will, muss ihn zuerst verstehen. Das ist der teure Teil, nicht das Programmieren.
Migrationen scheitern häufiger als sie gelingen
Große Kernbanken-Migrationen sind mehrfach öffentlich gescheitert. Budgets im dreistelligen Millionenbereich, jahrelange Verzögerungen, am Ende ein Rückbau auf das Altsystem. Jeder IT-Leiter in der Branche kennt diese Geschichten.
Nach zwei gescheiterten Anläufen entscheidet sich das Management gegen einen dritten. Das ist keine Bequemlichkeit. Das ist eine nachvollziehbare Risikoabwägung.
Der Ersatz bringt eigene Schulden mit
Ein neu geschriebenes Java-System ist nicht automatisch schuldenfrei. Es hat nur andere technische Schulden. Frameworks veralten. Abhängigkeiten müssen ständig aktualisiert werden. Nach zehn Jahren steht die nächste Modernisierung an.
COBOL-Code aus den Neunzigern läuft dagegen unverändert weiter. Aus Sicht der Betriebskosten ist das ein Vorteil, den man ehrlich benennen sollte.
Wo das Problem wirklich liegt
Die Sprachen sind nicht das Problem. Das Umfeld ist es.
Die Menschen gehen in Rente
Wer 1990 COBOL gelernt hat, ist heute Mitte sechzig. Universitäten lehren diese Sprachen kaum noch. Der Nachwuchs fehlt nicht, weil COBOL schwer wäre. Er fehlt, weil niemand seine Karriere auf einer Sprache aufbauen möchte, die als Auslaufmodell gilt.
Das Ergebnis kennen viele Betriebe: Ein einzelner Mitarbeiter versteht das System. Fällt er aus, steht die Fachabteilung still. Wie Sie mit dieser Situation umgehen, beschreibt unser Artikel Kein Entwickler für alten Code.
Die Hardware und das Betriebssystem altern mit
Die Sprache selbst hat kein Verfallsdatum. Die Umgebung schon. Compiler-Versionen erreichen ihr End of Life. Betriebssystem-Releases werden abgekündigt. Hardware-Wartungsverträge laufen aus.
Hier entsteht der echte Zeitdruck. Nicht bei der Sprache, sondern bei allem drumherum.
Die Anbindung an neue Systeme fehlt
Ein Kunde erwartet heute eine App, eine Bestellverfolgung, eine Schnittstelle zum Onlineshop. Das Kernsystem kann das nicht liefern, weil es dafür nie gebaut wurde.
Also entstehen Zwischenlösungen. Nächtliche Dateiexporte. Manuelle Übertragungen in Excel. Jede dieser Brücken ist eine zusätzliche Fehlerquelle.
Wann ein Umstieg wirklich sinnvoll ist
Nicht jedes alte System muss weg. Diese Anzeichen sprechen aber für Handlungsbedarf:
Der Hersteller-Support endet. Für Compiler, Betriebssystem oder Hardware. Ab diesem Punkt gibt es keine Sicherheits-Updates mehr.
Nur noch eine Person versteht das System. Und diese Person hat einen Rentenbescheid im Schreibtisch.
Fachliche Änderungen dauern Monate. Wenn eine neue Preisregel ein halbes Jahr braucht, bremst die IT das Geschäft aus.
Die Compliance-Anforderungen steigen. Prüfer fragen inzwischen konkret nach Nachvollziehbarkeit und Zugriffsschutz. Ältere Systeme können das oft nicht sauber belegen.
Gegen einen Umstieg spricht dagegen: Das System läuft stabil, die Anforderungen ändern sich selten, und es gibt mehr als eine Person, die den Code beherrscht. Dann ist konsequente Pflege die günstigere Entscheidung.
Vier realistische Wege nach vorn
Weg 1: Pflegen und absichern
Sie ändern die Sprache nicht. Sie sichern das System ab. Aktuelle Compiler-Version, gepflegtes Betriebssystem, dokumentierte Abläufe, getestete Backups.
Das ist der günstigste Weg und für viele stabile Systeme der richtige. Wichtig ist nur, dass er bewusst gewählt wird und nicht aus Verdrängung entsteht.
Weg 2: Wissen sichern, bevor es geht
Bevor der letzte Kenner in Rente geht, wird sein Wissen dokumentiert. Fachliche Regeln, Sonderfälle, Betriebsabläufe, kritische Programmteile.
Das ist unspektakulär und rettet Unternehmen regelmäßig vor größerem Schaden. Am besten beginnen Sie damit, solange die Person noch verfügbar ist.
Weg 3: Schnittstellen ergänzen
Das Kernsystem bleibt. Darüber legen Sie eine moderne Schnittstelle, eine sogenannte API. Neue Anwendungen sprechen mit dieser Schnittstelle statt direkt mit dem Altsystem.
So bekommen Sie App, Shop-Anbindung und Auswertungen, ohne den bewährten Kern anzufassen. Für IBM-i-Systeme haben wir die konkreten Optionen in RPG-Modernisierung: Wege für IBM i beschrieben.
Weg 4: Schrittweise ablösen
Wenn eine Ablösung unvermeidlich ist, dann in Etappen. Einzelne Funktionsbereiche werden nacheinander herausgelöst und ersetzt. Das Altsystem schrumpft über Jahre, statt an einem Wochenende abgeschaltet zu werden.
Dieses Vorgehen nennt sich Strangler Fig Pattern. Es dauert länger als ein Komplettaustausch. Es scheitert dafür deutlich seltener.
Fazit: Alt ist nicht dasselbe wie kaputt
COBOL 2026 ist kein Fehler im System. Diese Sprachen laufen weiter, weil sie ihre Aufgabe zuverlässig erfüllen. Wer sie belächelt, hat meist nie ein System betreut, das seit dreißig Jahren fehlerfrei abrechnet.
Das Risiko liegt woanders. Es liegt beim fehlenden Nachwuchs, beim auslaufenden Support und bei Wissen, das nur in einem Kopf existiert. Diese Punkte lassen sich angehen, und zwar bevor sie dringend werden.
Sie betreiben ein COBOL- oder RPG-System und wissen nicht, wie kritisch die Lage wirklich ist? Wir schauen uns Ihr System an und sagen Ihnen ehrlich, was zu tun ist und was warten kann. Auch dann, wenn die Antwort lautet: vorerst nichts.
Sprechen Sie uns an. Das Erstgespräch ist kostenlos und unverbindlich. Mehr zu unserem Vorgehen finden Sie unter Software-Wartung und Modernisierung.
