Legacy-Systeme an KI anbinden: Wege ohne Komplettmigration

Das Warenwirtschaftssystem läuft seit zwanzig Jahren, der Hersteller existiert nicht mehr, und der einzige Mitarbeiter, der die Anpassungen versteht, geht bald in Pension. Trotzdem steckt in diesem System das operative Wissen des Unternehmens: Artikel, Kunden, Aufträge, Historie. Wer heute Legacy-Systeme an KI anbinden will, steht vor einer scheinbaren Wahl: erst migrieren, dann modernisieren. Diese Reihenfolge ist in den meisten Fällen falsch.

Eine Komplettmigration dauert Jahre, bindet die besten Leute und liefert erst am Ende Nutzen. Eine KI-Anbindung an das bestehende System liefert in Wochen erste Ergebnisse und beantwortet nebenbei die Frage, welche Daten und Prozesse überhaupt migrationswürdig sind. Das Altsystem muss dafür nicht weg. Es muss nur lesbar werden. Dafür gibt es vier Wege, nach Aufwand gestaffelt, und für jeden gibt es Fälle, in denen er der richtige ist.

Weg eins: Export-Import-Brücken

Fast jedes Altsystem kann irgendetwas exportieren: CSV-Dateien, Druckdateien, Berichte, notfalls Datenbank-Dumps. Eine Export-Import-Brücke nutzt genau das. Ein geplanter Export legt die Daten regelmäßig in einem Austauschverzeichnis ab, ein kleines Skript liest sie ein, bereinigt sie und stellt sie dem KI-System zur Verfügung, etwa als durchsuchbaren Index oder als Tabellen in einer modernen Datenbank.

Das klingt unelegant und ist genau deshalb unterschätzt. Die Brücke greift nicht in das Altsystem ein, braucht keine Herstellerunterstützung und ist in Tagen gebaut. Ihre Grenzen sind klar: Die Daten sind so aktuell wie der letzte Export, und es fließt nichts zurück. Für Auswertungen, Assistenten mit Wissenszugriff und alle Anwendungsfälle, die mit täglicher oder stündlicher Aktualität auskommen, reicht das vollkommen. Wer hier anfängt, hat den geringsten Einsatz und das geringste Risiko.

Weg zwei: Datenbankzugriff im Lesemodus

Viele Altsysteme setzen auf gängige relationale Datenbanken auf. Dann liegt ein direkter Zugriff nahe: ein eigener Datenbankbenutzer, strikt auf Lesen beschränkt, idealerweise auf eine Replika statt auf die Produktivdatenbank. Damit stehen die Daten nahezu in Echtzeit bereit, ohne Exportfenster und ohne Dateihandling.

Der Preis ist Wissen. Gewachsene Datenbankschemata sind selten dokumentiert, Spaltennamen wie F17 oder STATUS2 erzählen nichts über ihre Bedeutung, und Geschäftslogik steckt oft in der Anwendung statt in der Datenbank. Ein Feld korrekt zu interpretieren kann länger dauern als die gesamte technische Anbindung. Bewährt hat sich, eine eigene Zwischenschicht aufzubauen: Sichten oder Abfragen, die die kryptischen Rohtabellen in fachlich benannte, dokumentierte Strukturen übersetzen. Diese Übersetzungsschicht ist die eigentliche Arbeit, und sie ist zugleich das wertvollste Nebenprodukt, denn sie dokumentiert erstmals, was in dem System wirklich steckt.

Zwei Regeln sind nicht verhandelbar: nie schreibend auf die Datenbank eines Altsystems zugreifen, dessen interne Logik man nicht vollständig kennt, und die Last der eigenen Abfragen so begrenzen, dass der Produktivbetrieb unberührt bleibt.

Weg drei: eine nachgerüstete API-Schicht

Wenn das KI-System nicht nur lesen, sondern auch Aktionen auslösen soll, etwa einen Auftrag anlegen oder einen Status ändern, braucht es eine kontrollierte Schnittstelle. Bietet das Altsystem keine, lässt sich eine API-Schicht davorsetzen: ein schlanker Dienst, der definierte Operationen anbietet und sie intern über die Wege umsetzt, die das Altsystem hergibt, etwa Datenbankprozeduren, Importschnittstellen oder vorhandene Modulaufrufe.

Der Wert dieser Schicht liegt in der Verengung. Statt das ganze System zu öffnen, gibt sie genau die fünf oder zehn Operationen frei, die der Anwendungsfall braucht, mit Validierung, Protokollierung und Berechtigungsprüfung an einer Stelle. Für KI-Agenten ist das die passende Form: klar definierte Werkzeuge mit klaren Grenzen statt freiem Zugriff. Der Aufwand ist deutlich höher als bei den ersten beiden Wegen, dafür entsteht ein Baustein, der bleibt.

Weg vier: Automatisierung über die Benutzeroberfläche

Manche Systeme geben schlicht nichts her: keine Exporte, keine zugängliche Datenbank, keine Andockpunkte. Dann bleibt die Automatisierung über die Oberfläche, also Software, die das Altsystem bedient wie ein Mensch, Masken ausfüllt und Werte abliest. Das funktioniert, und es ist zu Recht die letzte Option. Oberflächenautomatisierung ist fragil: Jede Layoutänderung, jedes unerwartete Dialogfenster kann den Ablauf brechen, und Fehler fallen oft erst spät auf. Wer diesen Weg geht, sollte ihn auf wenige, stabile Abläufe begrenzen, jede Aktion protokollieren und Kontrollen einbauen, die Abweichungen sofort stoppen. Als Dauerlösung taugt der Weg selten, als Überbrückung bis zu einer besseren Anbindung durchaus.

Die Anbindung migrationsfest bauen

Die berechtigte Sorge lautet: Wir investieren in die Anbindung, und wenn das Altsystem in drei Jahren doch abgelöst wird, ist alles wertlos. Das lässt sich vermeiden, wenn man eine Regel konsequent einhält: Das KI-System spricht nie direkt mit dem Altsystem, sondern immer mit einer eigenen Zwischenschicht in fachlichen Begriffen. Kunde, Auftrag, Lieferstatus statt Tabellennamen und Maskenfeldern.

Wird das Altsystem später ersetzt, tauscht man nur die Innenseite dieser Schicht aus. Die KI-Anwendungen, die Prompts, die Werkzeugdefinitionen und die Prozesse darüber bleiben unverändert. Die Übersetzungsschicht mit ihrer Dokumentation der Felder und Regeln ist dann sogar die beste Vorlage für die Migration selbst, weil sie festhält, was das alte System fachlich geleistet hat.

Fazit

Ein zwanzig Jahre altes System ist kein Ausschlusskriterium für KI, sondern eine Integrationsaufgabe mit vier abgestuften Antworten: Export-Brücken für den schnellen Start, lesender Datenbankzugriff für aktuelle Daten, eine nachgerüstete API-Schicht für kontrollierte Aktionen und Oberflächenautomatisierung als begrenzte Notlösung. Die Wahl richtet sich nach Aktualitätsbedarf, Schreibbedarf und dem, was das System technisch hergibt. Wer dabei konsequent über eine fachliche Zwischenschicht arbeitet, verliert nichts, wenn der Systemwechsel irgendwann doch kommt. Er hat ihn im Gegenteil vorbereitet.