API-First: Wie Legacy-Systeme moderne Oberflächen bekommen ohne neu geschrieben zu werden

Die Warenwirtschaft rechnet seit 2009 korrekt. Jede Sonderregel für Staffelpreise, jede Ausnahme für Stammkunden steckt im Code. Nur die Oberfläche sieht aus wie 2009. Neue Mitarbeiter brauchen Wochen, bis sie sich zurechtfinden. Auf dem Tablet im Lager läuft sie gar nicht.

Wer so ein System hat, hört oft denselben Rat: neu schreiben. Das ist meistens der teuerste Weg. API-First Legacy-Modernisierung ist die Alternative. Das Backend mit der erprobten Logik bleibt. Davor entsteht eine API-Schicht. Darüber kommt eine neue Oberfläche. Dieser Artikel erklärt, wie das funktioniert und wann es die beste Option ist.

Was API-First bei Legacy-Systemen bedeutet

Eine API (Application Programming Interface) ist eine Schnittstelle. Über sie sprechen Programme miteinander, ohne die Oberfläche zu benutzen. Ein Beispiel: Die neue Oberfläche fragt "Gib mir Auftrag 4711". Die API holt den Auftrag aus dem alten System und liefert ihn als sauberes Datenpaket zurück.

API-First heißt: Diese Schnittstelle wird zuerst entworfen. Erst danach entstehen die Oberflächen, die sie nutzen. Bei einem neuen Produkt ist das üblich. Bei Legacy Software ist es ungewöhnlicher, aber genauso sinnvoll.

Das Ergebnis sind drei Schichten. Unten das bestehende System mit Datenbank und Geschäftslogik. In der Mitte die API, die diese Logik nach außen anbietet. Oben die Oberfläche, die nur noch mit der API redet. Die Oberfläche weiß nicht, wie alt das System darunter ist. Das muss sie auch nicht.

Warum das alte Backend oft besser ist als sein Ruf

Viele Legacy-Systeme haben ein Problem mit der Oberfläche, nicht mit der Logik. Die Logik hat 15 Jahre lang Rechnungen gestellt, Lagerbestände verwaltet und Sonderfälle abgefangen. Jeder dieser Sonderfälle hat einmal jemanden Geld gekostet. Deshalb steht er im Code.

Bei einer Neuentwicklung müssen Sie all diese Fälle neu entdecken. Oft steht das nirgends dokumentiert. Die Person, die es wusste, ist seit Jahren weg. Ein Neubau wirkt am Anfang sauber. Die Sonderfälle findet er dann im Betrieb, einen nach dem anderen.

Mit einer API-Schicht behalten Sie dieses Wissen. Sie packen es nur in eine Form, mit der moderne Werkzeuge arbeiten können.

Was passiert, wenn Sie nichts tun

Eine alte Oberfläche kostet jeden Tag Geld, auch wenn keine Rechnung dafür kommt. Neue Kollegen brauchen länger in der Einarbeitung. Erfahrene Kollegen bauen Umwege mit Excel, weil die Software einen Schritt nicht kann. Im Außendienst gibt es keine mobile Ansicht, also wird abends nachgetragen.

Dazu kommt das Technik-Risiko. Alte Oberflächen hängen oft an Techniken, die niemand mehr pflegt: Flash, Silverlight, alte Java-Applets, Browser-Plugins. Irgendwann läuft die Oberfläche auf keinem aktuellen Rechner mehr. Dann muss es schnell gehen, und schnell ist teuer.

Und jedes Jahr wächst der Abstand. Die technischen Schulden sammeln sich an. Wer 2026 anfängt, hat weniger Arbeit als wer 2028 anfängt.

So läuft eine API-First Legacy-Modernisierung ab

Der Weg hat vier Schritte. Keiner davon erfordert, das alte System abzuschalten.

Schritt 1: Geschäftslogik finden und abgrenzen

Zuerst klären wir, welche Funktionen das System nach außen anbieten soll. Nicht jeder Bildschirm braucht einen Zugang über die API. Meist reichen 20 bis 40 Funktionen für den Anfang. Etwa: Kunden lesen, Aufträge anlegen, Bestände abfragen, Preise berechnen.

Dabei zeigt sich, wo Logik und Oberfläche verwoben sind. In vielen alten Systemen steckt die Preisberechnung direkt im Klick-Handler des Formulars. Diese Stellen lösen wir heraus, damit die API sie aufrufen kann. Das ist der aufwendigste Teil und lässt sich vorher nur grob schätzen.

Schritt 2: API-Schicht bauen

Die API-Schicht ist ein eigenes, kleines Programm. Es nimmt Anfragen entgegen, ruft die alte Logik auf und gibt saubere Antworten zurück. Meist als REST-Schnittstelle mit JSON, einem einfachen Textformat für Daten.

Wichtig ist der Vertrag. Welche Felder gibt es? Welche Werte sind erlaubt? Was passiert bei Fehlern? Diesen Vertrag schreiben wir vor dem Code auf, zum Beispiel als OpenAPI-Dokument. Die Frontend-Entwickler können damit sofort loslegen. Welche Fragen bei Schnittstellen sonst noch anstehen, steht im Artikel zur API-Integration.

Schritt 3: Neue Oberfläche aufsetzen

Erst jetzt entsteht die neue Oberfläche. Sie kennt nur die API. Ob sie als Web-Anwendung, als App oder als beides gebaut wird, ist eine freie Entscheidung. Das alte System merkt davon nichts.

Praktisch beginnen wir mit einem Bereich, der den Nutzern am meisten weh tut. Oft ist das die Auftragserfassung oder die Lageransicht. Diese Oberfläche geht in den Betrieb, während der Rest noch alt aussieht. Die Nutzer arbeiten eine Zeit lang in zwei Welten. Das ist unschön, aber verkraftbar.

Schritt 4: Schrittweise ablösen

Bereich für Bereich wandert in die neue Oberfläche. Das alte Frontend wird kleiner, bis es abgeschaltet werden kann. Das Backend bleibt, solange es seinen Dienst tut. Wer später auch das Backend ersetzen will, hat mit der API bereits die Sollbruchstelle. Dieses Vorgehen beschreibt das Strangler-Fig-Pattern genauer.

Wann API-First die beste Option ist

Der Ansatz passt, wenn drei Dinge zusammenkommen. Die Geschäftslogik ist stabil und tut, was sie soll. Die Oberfläche ist das Hauptproblem. Und das Backend lässt sich von außen ansprechen. Etwa über Funktionsaufrufe, Datenbankzugriff oder eine vorhandene Schnittstelle.

Er passt nicht, wenn die Logik selbst kaputt ist. Wenn Berechnungen falsch sind, hilft eine neue Oberfläche wenig. Gleiches gilt, wenn das Datenmodell die heutigen Prozesse nicht mehr abbildet. Dann lohnt ein Blick auf andere Wege, die wir im Überblick zu Modernisierungsstrategien vergleichen. Manchmal ist auch ein Neubau mit KI-Unterstützung der ehrlichere Weg.

Ein zweiter Stolperstein ist die Leistung. Alte Systeme wurden für einen Nutzer pro Sitzung gebaut. Eine API, die 50 mobile Geräte gleichzeitig bedient, kann das System überfordern. Das lässt sich lösen, mit Zwischenspeichern oder Warteschlangen. Man muss es aber vorher einplanen.

Was der Weg kostet und was er bringt

Die API-Schicht kostet je nach System einige Wochen bis wenige Monate. Der Neubau einer Oberfläche ist danach ein normales Frontend-Projekt mit planbarem Aufwand. Verglichen mit einer kompletten Neuentwicklung sparen Sie meist die Hälfte oder mehr. Vor allem tragen Sie nicht das Risiko, dass ein Neubau nach zwei Jahren noch Sonderfälle vermisst.

Nebenbei bekommen Sie etwas, das Sie vorher nicht hatten: eine dokumentierte Schnittstelle. Damit lassen sich auch der Online-Shop, das Kassensystem oder ein Partnerportal anbinden. Das alte System wird zum Baustein statt zur Sackgasse.

Fazit

API-First bei Legacy-Systemen heißt: Behalten, was funktioniert. Ersetzen, was stört. Sie bekommen eine moderne Oberfläche, ohne 15 Jahre Geschäftslogik neu zu erfinden. Der Weg braucht eine saubere Analyse am Anfang und Geduld beim schrittweisen Umstieg. Dafür bleibt das Risiko klein.

Sie haben ein System mit guter Logik und alter Oberfläche? Sprechen Sie uns an. Das Erstgespräch ist kostenlos. Wir schauen gemeinsam, ob eine API-Schicht bei Ihnen trägt.