Altes ERP ohne API anbinden – wie Legacy-Systeme trotzdem Teil moderner Prozesse werden

Viele mittelständische Unternehmen arbeiten mit ERP-Systemen, die seit Jahren oder Jahrzehnten zuverlässig laufen. Das System kennt Kunden, Artikel, Preise, Bestände, Aufträge, Sonderlogiken. Es ist tief im Tagesgeschäft verankert.

Drumherum entsteht trotzdem ständig Bedarf an moderner Software: ein B2B-Portal, ein Shop, automatischer Auftragseingang, EDI zu Großkunden, KI-gestützte Bestellverarbeitung, Dashboards, mobile Lageranwendungen. Und dann fällt der Satz, der viele Projekte bremst: „Unser ERP hat keine API."

Für viele klingt das nach Automatisierungsstopp. In der Praxis stimmt das selten. Ein altes ERP ohne moderne REST-API lässt sich fast immer anbinden – nur eben nicht über den idealen Weg aus dem Lehrbuch. Es braucht eine pragmatische Integrationsschicht, die mit den real verfügbaren Zugängen arbeitet: Dateiimport, Exportverzeichnisse, Datenbankzugriff, vorhandene Importmodule, EDI, SFTP, API-Wrapper oder im Ausnahmefall RPA.

Die entscheidende Frage lautet deshalb nicht: „Hat unser ERP eine moderne API?" Sondern: Welche Daten müssen in welchem Prozess zuverlässig gelesen, geschrieben, geprüft und überwacht werden – und welcher technische Zugang ist dafür stabil genug?

Warum ein altes ERP selten das Problem ist – aber oft der Engpass

Ein altes ERP ist nicht automatisch schlecht. Viele Legacy-Systeme sind über Jahre an die Abläufe eines Unternehmens angepasst worden und enthalten Regeln, die nirgendwo sonst vollständig dokumentiert sind: kundenspezifische Preise, Sonderrabatte, Artikelnummernlogik, Mengeneinheiten, Lieferbedingungen, Auftragsarten, Freigaben, Sperrkennzeichen, Lagerlogik, Rechnungsläufe, Exportformate für die Buchhaltung.

Im Tagesgeschäft funktioniert das System oft besser, als es von außen aussieht.

Das Problem entsteht nicht durch das ERP selbst, sondern wenn moderne Prozesse Daten daraus brauchen oder hineinschreiben müssen – und das ERP dafür keinen zeitgemäßen Zugang anbietet. Sie merken das daran, dass irgendwo in Ihrem Unternehmen die folgenden Brücken entstanden sind:

Ohne saubere Anbindung bleibt das ERP zwar der Kern. Es wird aber zur Bremse für alles, was außen herum wachsen soll.

Wenn Sie hier den größeren Rahmen suchen – wie Bestellungen aus Mail, PDF, Webshop und Telefon überhaupt strukturiert ins ERP gelangen – ist der Überblicksartikel Auftragseingang automatisieren im Mittelstand der passende Einstieg. Dieser Artikel betrachtet den Sonderfall: Das ERP existiert, läuft, ist im Kern stabil – aber es spricht nicht modern.

Was „ERP ohne API anbinden" wirklich bedeutet

Wenn ein ERP „keine API" hat, kann das Verschiedenes heißen. Manchmal gibt es tatsächlich gar keinen dokumentierten technischen Zugang. Häufiger gibt es ältere oder indirekte Möglichkeiten: CSV-Importe, XML-Exporte, SFTP-Verzeichnisse, Importordner, ODBC- oder JDBC-Datenbankzugriff, gespeicherte Prozeduren, EDI-Module, Batchjobs, alte SOAP-Services, Hersteller-Tools, Übergabetabellen.

Das ist keine moderne API. Aber es reicht oft, um Prozesse kontrolliert zu automatisieren.

„ERP ohne API anbinden" heißt deshalb in der Praxis: die vorhandenen Ein- und Ausgänge des Systems identifizieren, den gewünschten Geschäftsprozess klar begrenzen, Daten aus modernen Systemen in ein Format übersetzen, das das ERP versteht, ERP-Daten so bereitstellen, dass moderne Systeme damit arbeiten können – und Fehler, Dubletten und Sonderfälle sichtbar machen.

Eine gute Legacy-Integration akzeptiert die Realität des bestehenden Systems. Sie versucht nicht, aus einem alten ERP über Nacht eine moderne Cloud-Plattform zu machen. Sie baut eine stabile Brücke zwischen dem, was vorhanden ist, und dem, was das Unternehmen als Nächstes braucht.

In der Praxis sieht das so aus: Ein Shop erzeugt Auftragsdaten als JSON. Eine Middleware prüft Kunden, Artikel und Pflichtfelder. Sie schreibt eine CSV-Datei in ein Importverzeichnis. Das ERP importiert diese Datei alle fünf Minuten. Nach erfolgreichem Import wird die ERP-Auftragsnummer zurückgemeldet. Fehlerhafte Datensätze landen in einer Prüfliste, der Innendienst korrigiert nur noch Ausnahmen.

Von außen sieht das aus wie eine moderne Schnittstelle. Intern arbeitet das ERP weiterhin mit seinen bekannten Mechanismen.

Lesen, schreiben oder Prozesse auslösen – die wichtigste Unterscheidung

Bevor über Technik gesprochen wird, lohnt eine fachliche Frage: Was genau soll die Anbindung tun? Drei Grundarten sind zu unterscheiden, und sie haben sehr unterschiedliche Risiken.

1. Daten aus dem ERP lesen

Der risikoärmste Einstieg. Artikelstammdaten exportieren, Preise bereitstellen, Kundenstammdaten abrufen, Bestände für ein Portal anzeigen, Auftragsstatus in ein Dashboard übertragen, Rechnungsdaten für Auswertungen.

Lesende Zugriffe sind einfacher abzusichern. Wenn etwas in der Integration schiefgeht, werden keine operativen ERP-Daten verändert. Typische Wege: CSV-Export, Datenbank-Read-only, Report-Export, SFTP-Ablage, periodischer Batchjob, Replikation in eine Zwischendatenbank.

2. Daten ins ERP schreiben

Wertvoller, aber sensibler. Neue Aufträge anlegen, Kunden aktualisieren, Lieferadressen übertragen, Versandstatus zurückschreiben, Trackingnummern ergänzen.

Schreibende Anbindungen brauchen klare Regeln: Welche Felder dürfen automatisch geschrieben werden? Welche Daten müssen vorher validiert werden? Wie wird Dublettenbildung verhindert? Was passiert, wenn der Import teilweise fehlschlägt? „Eine Datei rüberschieben" reicht hier selten – es braucht Protokolle, Status, Wiederholbarkeit und eine klare Fehlerlogik.

3. Prozesse im ERP auslösen

Anspruchsvoller. Auftrag freigeben, Lieferschein erzeugen, Rechnungslauf starten, Lagerreservierung auslösen, Produktionsauftrag erzeugen.

Diese Prozesse hängen oft an ERP-internen Regeln und sollten nicht blind von außen angestoßen werden. Es ist meist klüger, zunächst nur vorbereitete Daten ins ERP zu schreiben und die eigentliche Freigabe im ERP-Prozess zu lassen. Erst wenn die Regeln klar sind, kann mehr automatisiert werden.

Welche Anbindungswege es ohne moderne API gibt

Auch ohne moderne API gibt es mehrere technische Wege. Welcher passt, hängt vom ERP, vom Prozess und vom Risiko ab.

Dateiimport und Dateiexport. Der Klassiker bei älteren Systemen. Das ERP liest oder erzeugt Dateien in Formaten wie CSV, TXT, XML, fixed-width oder EDI. Übertragung über Importordner oder SFTP. Vorteile: oft schon vorhanden, gut nachvollziehbar, robust für Stapelverarbeitung. Nachteile: nicht immer echtzeitfähig, Mapping muss exakt passen, Teilimporte und Kodierung müssen sauber behandelt werden.

Datenbankzugriff. Viele alte ERP-Systeme speichern Daten in SQL-Datenbanken. Mit gesichertem Zugriff kann eine Middleware lesen oder in klar definierten Fällen schreiben. Lesend praktikabel und schnell. Schreibend deutlich kritischer – dazu gleich mehr.

Importmodule des ERP. Viele alte ERP haben zwar keine API, aber Importfunktionen für Aufträge, Kunden, Artikel, Bestände, Preislisten, EDI, Buchhaltung. Das ist oft der beste Weg, weil vorhandene ERP-Logik genutzt wird – Validierung, Nummernkreise, Buchungslogik bleiben beim ERP.

SFTP und Importverzeichnisse. Besonders nützlich, wenn Systeme nicht direkt miteinander sprechen können oder dürfen. Eine Middleware legt Dateien in einem abgesicherten Verzeichnis ab, das ERP liest sie periodisch ein. Wichtig: eindeutige Dateinamen, atomare Ablage (keine halbfertigen Dateien lesen), Archivierung verarbeiteter Dateien, Fehlerordner, Wiederholbarkeit, Zugriff über Schlüssel statt Passwörter.

EDI. In vielen Branchen gibt es bereits EDI-Prozesse für Bestellungen, Lieferavise, Rechnungen oder Stammdaten. Wenn das ERP EDI-Dateien erzeugen oder verarbeiten kann, lassen sich diese in moderne Formate übersetzen.

API-Wrapper. Eine moderne Schicht vor dem alten System. Moderne Anwendungen sprechen nicht direkt mit Tabellen oder Dateiformaten, sondern mit einer kontrollierten Zwischenschicht (/customers, /orders, /stock). Der Wrapper übersetzt diese Anfragen in das, was das ERP wirklich kann.

RPA und UI-Automation. Wenn alle anderen Wege ausscheiden, bedient ein Bot die ERP-Oberfläche wie ein Mitarbeiter. Funktioniert für seltene Abläufe, ist aber empfindlich gegenüber Maskenänderungen, langsam und schwer parallel zu betreiben.

Der eigentliche Trick liegt nicht im Kanal selbst, sondern im sauberen Betrieb: Mapping, Fehlerlogik, Idempotenz, Monitoring. Eine schlecht überwachte API ist riskanter als ein gut betriebener CSV-Import.

Wenn Sie an dieser Stelle in die Detailfrage gehen wollen, wann Datei-Schnittstellen tatsächlich der bessere Weg sind als eine API: dazu gibt es einen eigenen Artikel zu CSV-, XML- und SFTP-Schnittstellen fürs ERP und eine breitere Einordnung in ERP-Schnittstelle programmieren lassen – Kosten, Ablauf, Risiken.

Wann Dateiimport ausreicht – und was er trotzdem braucht

Dateiimport klingt im Vergleich zu Webhooks und Echtzeitintegration weniger modern. Für viele Mittelstandsprozesse ist er trotzdem der wirtschaftlich bessere Weg.

Vor allem dann, wenn Daten nicht sekundengenau übertragen werden müssen, Aufträge in Stapeln verarbeitet werden können, das ERP bereits stabile Importfunktionen hat, Formate dokumentiert sind und Fehlerfälle manuell nachbearbeitet werden können.

Konkret: ein B2B-Portal übergibt Bestellungen alle fünf Minuten als CSV. Das ERP exportiert nachts Artikel und Preise. Bestände werden stündlich bereitgestellt. Lieferstatus kommt als Datei zurück. Rechnungsinformationen wandern täglich ins DMS.

Eine saubere Datei-Integration braucht klares Mapping, Pflichtfeldprüfung, eindeutige Schlüssel, definierte Kodierung, Versionslogik fürs Format, Archiv der übertragenen Dateien, Protokoll je Datensatz, Fehlerdateien und Monitoring. Klingt nach bürokratischem Protokollkram. Genau das verhindert die Anrufe vom Kunden, der gerade vergeblich auf seine Bestellbestätigung wartet.

Der häufigste Fehler ist, Dateiimporte zu technisch zu betrachten. Es reicht nicht, dass eine Datei im richtigen Ordner liegt. Sie muss fachlich korrekt sein: Existiert der Kunde im ERP? Ist die Artikelnummer eindeutig? Stimmt die Mengeneinheit? Sind Preise und Rabatte zulässig? Wurde die Bestellung bereits importiert? Wenn diese Fragen beantwortet sind, läuft eine Datei-Integration sehr stabil.

Beispiel: Shop-Bestellung ins alte ERP übertragen

Ein Online-Shop erzeugt eine Bestellung. Das ERP hat keine API, aber einen Auftragsimport. Der Prozess sieht so aus:

1. Shop sendet Bestellung an die Middleware.
2. Middleware prüft Kundennummer, Artikelnummern, Pflichtfelder.
3. Middleware ergänzt ERP-spezifische Felder: Auftragsart, Versandart, Zahlungsbedingung.
4. Middleware erzeugt eine CSV im ERP-Importformat und legt sie per SFTP ab.
5. ERP importiert die Datei und erzeugt eine Auftragsnummer.
6. Middleware liest das Importprotokoll und meldet ERP-Auftragsnummer und Status an den Shop zurück.
7. Fehlerhafte Aufträge landen in einer Prüfliste.

Das ist keine Hochglanz-API. Es entlastet den Auftragseingang trotzdem deutlich.

Wer denselben Mechanismus konkret für WooCommerce sucht, findet das in WooCommerce-Bestellungen automatisch ins ERP übertragen.

Wann Datenbankzugriff sinnvoll ist – und wann nicht

Datenbankzugriff ist verlockend. Wenn alle ERP-Daten in Tabellen liegen, scheint der direkte Zugriff der schnellste Weg. Für lesende Zugriffe ist das oft auch wahr: Dashboard für Auftragsbestand, Kundenportal mit Status, Bestandsabgleich für Shop, Export ins Data Warehouse, Synchronisation von Artikelstammdaten, KI-Suche über Kunden- oder Produktdaten.

Wichtig: read-only Benutzer, nur benötigte Tabellen oder Views, Zugriff über VPN oder privates Netzwerk, keine direkten Schreibrechte, Abfragen so bauen, dass das ERP nicht belastet wird – bei kritischer Last besser über Replikation oder Zwischendatenbank.

Schreibender Datenbankzugriff ist deutlich riskanter. Viele ERP-Systeme haben Geschäftslogik, die nicht in Tabellen steckt: Beim Anlegen eines Auftrags werden Nummernkreise gezogen, Lagerreservierungen erzeugt, Preisfindung ausgeführt, Steuerlogik berechnet, Kreditlimit geprüft, Belege verknüpft, Status gesetzt, Historien geschrieben.

Ich habe das schon gesehen – eine externe Integration befüllte direkt eine ERP-Tabelle, alles sah sauber aus, bis zwei Wochen später die ersten Mahnungen rausgingen, weil die Belegverknüpfung fehlte und niemand die offenen Posten dem richtigen Auftrag zuordnen konnte.

Direkt in eine ERP-Datenbank schreiben sollte nur erfolgen, wenn der Weg vom Hersteller vorgesehen, dokumentiert und betrieblich abgesichert ist. Besser sind offizielle Importtabellen, Stored Procedures, vorhandene Importmodule oder vom Hersteller freigegebene Schnittstellenlogik.

Was ein API-Wrapper für ein altes ERP leisten kann

Ein API-Wrapper ist eine moderne Schicht vor einem alten System. Er gibt neuen Anwendungen eine saubere Schnittstelle, ohne dass das ERP selbst modernisiert werden muss.

Statt dass ein Shop, Portal oder Dashboard direkt mit CSV-Dateien, Datenbanktabellen oder ERP-Sonderlogik arbeitet, sprechen diese Systeme mit einer kontrollierten API. Beispiel:

• Das Kundenportal fragt /products/{id}/availability ab.
• Der Wrapper liest Bestand aus einer replizierten ERP-Tabelle oder Exportdatei.
• Die Antwort kommt als JSON zurück.
• Intern bleibt das ERP unverändert.

Oder umgekehrt: Ein Shop sendet eine Bestellung an /orders, der Wrapper validiert die Daten, erzeugt eine ERP-Importdatei, das ERP verarbeitet sie, der Wrapper gibt Status und Auftragsnummer zurück.

Der Wrapper kann mehr als nur übersetzen: Datenmodelle vereinheitlichen, alte Feldnamen in verständliche Begriffe übersetzen, Pflichtfelder prüfen, moderne Authentifizierung ermöglichen, Fehler standardisieren, Caching nutzen, ERP-Last reduzieren, mehrere moderne Systeme an eine einheitliche Schnittstelle anbinden.

Besonders wertvoll, wenn nicht nur ein System angebunden wird. Wenn heute ein Shop kommt, morgen ein Portal und übermorgen eine KI-Auswertung, sollte nicht jedes System einzeln an das alte ERP gekoppelt werden – sonst entsteht Punkt-zu-Punkt-Chaos. Ein Wrapper schafft eine kontrollierte Integrationszone.

Ein Wrapper macht das ERP allerdings nicht automatisch moderner. Er kann nur stabil bereitstellen, was technisch und fachlich möglich ist. Wenn Stammdaten schlecht gepflegt sind oder Preislogik nur manuell funktioniert, muss das im Projekt mitgeplant werden.

Warum RPA nur der letzte Ausweg sein sollte

Wenn ein altes ERP keine API, keinen Import, keinen Export und keinen sicheren Datenbankzugriff bietet, kann ein Bot die Oberfläche bedienen. Er klickt wie ein Mitarbeiter, liest Felder, trägt Daten ein.

Für manche Prozesse ist das besser als gar keine Automatisierung – vor allem für klar begrenzte, seltene Abläufe oder als Übergangslösung bis zur richtigen Schnittstelle.

Bei ERP-Kernprozessen ist RPA aber fragil: Benutzeroberflächen ändern sich, Fensterpositionen und Dialoge sind empfindlich, Bots sind langsam im Vergleich zu technischen Schnittstellen, parallele Verarbeitung ist schwer, Fehler sind schwerer zu erkennen, Berechtigungen werden oft wie bei echten Nutzern vergeben.

Eine Faustregel: Wenn ein Prozess über Daten oder Dateien automatisiert werden kann, sollte er nicht über Bildschirmklicks automatisiert werden.

Die Zielarchitektur: Middleware statt Punkt-zu-Punkt-Chaos

Der größte Fehler bei Legacy-ERP-Projekten ist nicht der fehlende API-Zugang. Es ist die unkontrollierte Kopplung.

Ein Shop liest direkt aus einer Tabelle. Ein Portal nutzt einen anderen Export. Ein Dashboard importiert eine eigene CSV. Eine Excel-Liste korrigiert Sonderfälle. Nach kurzer Zeit weiß niemand mehr genau, welches System welche Datenquelle nutzt, welches Feld führend ist, warum ein Auftrag fehlt oder welche Datei die richtige ist. Bei Fehlern weiß auch niemand, wer eigentlich zuständig ist.

Die bessere Architektur ist eine Integrationsschicht – Middleware, Adapter, API-Wrapper, Integrationsservice. Der Name ist egal, die Aufgabe nicht: Verbindung zum alten ERP, Übersetzung von Datenformaten, Mapping, Validierung vor Übergabe, Fehlerbehandlung, Protokollierung, Wiederholung fehlgeschlagener Übergaben, Dublettenprüfung, Statusverwaltung, Sicherheitsregeln, moderne Schnittstellen für neue Systeme.

So entsteht eine klare Grenze:

Moderne Systeme sprechen mit der Middleware. Die Middleware spricht mit dem Legacy-ERP.

Das ERP muss nicht jede neue Anwendung kennen. Neue Anwendungen müssen nicht jede Eigenheit des ERP kennen.

Ein konkretes Beispiel: Ein Unternehmen nutzt ein altes ERP, einen WooCommerce-Shop und plant ein B2B-Portal. Ohne Middleware bekommt jeder Kanal eine eigene ERP-Logik, Bestandsdaten werden zweimal synchronisiert, Fehler tauchen in verschiedenen Systemen auf, jede Änderung am ERP betrifft mehrere Integrationen. Mit Middleware sendet WooCommerce Bestellungen an die Middleware, das B2B-Portal fragt Preise und Verfügbarkeit über sie ab, Aufträge laufen über den vorgesehenen Importweg ins ERP, Fehler und Status laufen zentral zusammen. Neue Systeme werden an dieselbe Logik angebunden.

Diese Architektur ist nicht nur sauberer. Sie ist langfristig günstiger zu betreiben.

Sicherheit, Rechte und Betrieb

Bei alten ERP-Systemen geht es um geschäftskritische Daten. Eine schnelle Integration darf nicht zum Sicherheits- oder Betriebsrisiko werden.

Minimale Rechte. Für lesende Prozesse: read-only Benutzer, Zugriff nur auf benötigte Tabellen, Views oder Exportverzeichnisse, keine administrativen Rechte. Für schreibende Prozesse: eigener technischer Benutzer, begrenzte Schreibrechte, klare Importwege, keine Mitarbeiter-Logins, Protokoll aller Änderungen.

Getrennte Umgebungen. Wenn möglich, nicht direkt gegen Produktiv entwickeln. Testdatenbank, ERP-Testsystem, Import-Testverzeichnis, Pilotmandant, abgesicherter Parallelbetrieb. Gerade bei Auftragsimporten ist eine Testphase nicht verhandelbar.

Protokollierung. Jede Übergabe nachvollziehbar: externe Referenz, ERP-Referenz, Zeitstempel, Status, Fehlertext, Wiederholversuche, Auslöser. Bürokratisch klingende Protokolldaten – genau das, was Sie brauchen, sobald irgendwer fragt: „Warum ist dieser Auftrag doppelt, falsch oder gar nicht im ERP?"

Idempotenz. Ein Auftrag darf nicht doppelt entstehen, nur weil eine Datei erneut verarbeitet, ein Webhook zweimal ausgelöst oder ein Import wiederholt wurde. Eindeutige Schlüssel: externe Bestellnummer, Shop-ID, Portal-Auftragsnummer, EDI-Referenz, ERP-Auftragsnummer. Vor jedem Schreiben prüfen, ob der Vorgang schon verarbeitet wurde.

Monitoring. Eine Integration ist nicht fertig, wenn sie einmal funktioniert. Läuft der Importjob? Liegen Dateien im Fehlerordner? Sind Exportdaten aktuell? Gerade bei dateibasierten Integrationen ist Monitoring entscheidend – sonst arbeitet das Team gegen ein Logfile, das morgens niemand öffnet.

Dokumentation. Legacy-Wissen steckt in Köpfen. Datenquellen, Feldmapping, führende Systeme, Fehlerlogik, Ansprechpartner, Wiederanlauf nach Störung, bekannte Sonderfälle, Grenzen der Automatisierung – das gehört in ein Dokument, das auch der nächste Kollege lesen kann.

Typische Fehler bei der Anbindung alter ERP-Systeme

Viele ERP-Integrationsprojekte scheitern nicht an der Technik. Sie scheitern an falschen Annahmen.

Ein realistischer Pilot für den Mittelstand

Ein gutes Legacy-ERP-Projekt beginnt nicht mit der vollständigen Modernisierung. Es beginnt mit einem Prozess, der heute spürbar Aufwand erzeugt und technisch gut eingrenzbar ist.

Welcher Pilot eignet sich? Shop-Bestellungen ins ERP übertragen, B2B-Portal-Bestellungen importieren, Artikelstammdaten für ein Portal exportieren, Bestände für einen Shop bereitstellen, E-Mail-Bestellungen strukturiert vorbereiten, Lieferstatus zurückmelden, Kundendaten für den Vertrieb. Wählen Sie keinen Prozess, der alle Sonderfälle enthält. Wählen Sie einen, der häufig genug ist, um Nutzen zu erzeugen, aber klar genug, um beherrschbar zu bleiben.

Wann Integration besser ist als ERP-Ablösung

Wenn ein ERP keine API hat, wirkt eine Ablösung manchmal wie die konsequente Lösung. Manchmal ist sie das auch. Eine ERP-Migration betrifft aber fast alle Bereiche: Stammdaten, Buchhaltung, Lager, Einkauf, Vertrieb, Produktion, Prozesse, Rollen, Berechtigungen, Schnittstellen, Reporting, Schulung, Change Management.

Eine Integration ist sinnvoller, wenn das ERP im Kernprozess stabil läuft, nur einzelne Datenflüsse fehlen, das Unternehmen kurzfristig Entlastung braucht, eine Migration zu riskant oder zu teuer wäre, moderne Kanäle angebunden werden sollen oder schrittweise modernisiert werden soll.

Eine gut gebaute Integrationsschicht ist auch dann nützlich, wenn später ein neues ERP kommt – sie klärt Datenmodelle, Prozesse, Fehlerfälle und Verantwortlichkeiten. Genau diese Klarheit braucht jede Migration ohnehin.

Eine Ablösung sollte hingegen geprüft werden, wenn das System nicht mehr wartbar ist, keine sicheren Zugänge möglich sind, der Hersteller nicht mehr existiert, Datenqualität dauerhaft schlecht ist, Kernprozesse nur noch mit Workarounds laufen oder rechtliche Anforderungen nicht erfüllbar sind. Auch dann hilft eine Übergangsintegration – aber nicht als Dauerlösung.

Fazit

Ein altes ERP ohne API ist kein Automatisierungsstopp. Es bedeutet, dass die Integration anders geplant werden muss.

Statt von einer idealen REST-API auszugehen, prüfen Sie die real verfügbaren Zugänge: Exportdateien, Importmodule, SFTP-Verzeichnisse, Datenbank-Read-only, EDI, Übergabetabellen, API-Wrapper, Middleware – und RPA als letzte Option.

Der wichtigste Erfolgsfaktor ist nicht der technische Kanal. Es ist die fachliche Klarheit: Welcher Prozess soll entlastet werden? Welche Daten sind wirklich nötig? Welches System ist führend? Welche Sonderfälle müssen sichtbar bleiben? Wie wird überwacht, ob die Integration funktioniert?

Eine gute Legacy-Anbindung schützt das bestehende System, macht moderne Prozesse möglich und vermeidet Punkt-zu-Punkt-Chaos. Nicht alles ersetzen. Nicht alles automatisieren. Einen wertvollen Standardprozess sauber anbinden, Fehler sichtbar machen, dann Schritt für Schritt erweitern.

So bleibt das ERP der stabile Kern – und moderne Software kann trotzdem für Sie arbeiten.

FAQ zu alten ERP-Systemen ohne API