SOLUTIONS.transformer

Datenmigration und Schnittstellen

Daten aus dem Altsystem übernehmen und im Austausch halten

Die teuerste Zeile im Angebot sind die Schnittstellen

Eine neue Fachanwendung scheitert selten an der Fachanwendung. Sie scheitert daran, dass zwanzig Jahre Bestandsdaten nicht sauber herüberkommen, und daran, dass danach niemand die Verbindung zum ERP pflegen will.

Wenn ein Unternehmen ein Altsystem ablöst, dreht sich das Gespräch zuerst um Masken, Rollen und Auswertungen. Über Termin und Budget entscheidet ein anderer Posten: die Datenübernahme und die Schnittstellen zu allem, was weiterläuft. Klassisch ist jede dieser Verbindungen ein eigenes kleines Programm: geschrieben, getestet, gepflegt. Was das kostet, steht auf den Preisseiten deutscher Anbieter.

Warum Schnittstellen im Angebot eine eigene Zeile bekommen

Alle Zahlen von den Preisseiten deutscher Softwaredienstleister, nicht von uns.

Pro Schnittstelle ERP, Personalsystem, Lieferantenportal
3.500 bis 21.000 €
Internes Werkzeug / MVP zum Vergleich: die Anwendung selbst
14.000 bis 28.000 €
Wartung pro Jahr Anteil der Projektsumme, Schnittstellen inbegriffen
15 bis 25 %

August 2026, öffentliche Kostenseiten deutscher Softwaredienstleister, unter anderem Groenewold IT Solutions, GRAPHEK, GECKO, XMETHOD und trinidat.

Was ein Datentransformator tut

Er liest Daten aus einer Quelle, überführt sie in eine andere Struktur und schreibt sie an ein Ziel. Der Unterschied zum Importskript ist nicht die Fähigkeit, sondern die Form: Der Ablauf ist eine Konfiguration, die man ansehen, kopieren und ändern kann, und keine Datei mit Code.

Eine Datenquelle ist dabei ausdrücklich beides: Quelle und Ziel. Ob gelesen oder geschrieben wird, entscheidet erst der Ablauf. Derselbe Weg, über den die Bestandsdaten einwandern, führt später fertige Vorgänge zurück ins ERP. Acht Adaptertypen decken das ab, von SQL-Datenbanken und Dateien über REST und SOAP bis zu Verzeichnisdiensten. Intern verarbeiten wir alles als JSON-Dokument, sodass die Formatunterschiede an der Adaptergrenze enden.

Eine Datenquelle ist Quelle und Ziel zugleich

Im Beispiel eine MongoDB-Quelle: Adresse, Anmeldung, Datenbank und Sammlung, dazu die Strenge der Zertifikatsprüfung. Eine REST-Quelle bekommt stattdessen Verb und Adresse, Kopfzeilen, Parameter, eine fest hinterlegte oder je Aufruf berechnete Anmeldung und eine Begrenzung der Aufrufe pro Minute. Dateiquellen holen CSV, JSON, XML oder Excel aus einem überwachten Verzeichnis, einem Upload oder per SFTP.

Zwei Schaltflächen sparen dabei die meiste Zeit: Verbindung testen und Vorschau mit echten Datensätzen, bevor der erste Ablauf entsteht. Zugangsdaten liegen verschlüsselt.

Jede Feldzuordnung ist eine gezogene Leitung

Ein Ablauf wird gezeichnet, nicht geschrieben. Links liegt die Palette, gegliedert in Eingabe, Daten, Aktionen und Ausgabe; unter den Aktionen stehen Skript ausführen, HTTP-Anfrage, Subprozess aufrufen, Prüfsumme berechnen, Filter, Typwandlung und eine Rechteprüfung. Ein Knoten wird auf die Fläche gezogen und verdrahtet, Ausgang auf Eingang, mit Typprüfung, damit ein Zahlenfeld nicht an einem Textfeld landet.

Das Herzstück ist der Modellknoten. Er fächert eine Datendefinition feldweise auf, ein Ausgang je Quellfeld, ein Eingang je Zielfeld. Eine Umbenennung ist damit buchstäblich eine Leitung. Ein Skript kommt nur dort dazu, wo gerechnet wird, und ist dann ein einzelner Knoten mit sichtbaren Ein- und Ausgängen statt einer Datei, die niemand mehr öffnet.

Der Ausschnitt stammt aus keinem Lehrbuchbeispiel: Der Ablauf holt wöchentlich die Benutzer aus dem Verzeichnisdienst und schreibt sie nach SOLUTIONS.user. Der Dienst arbeitet also auch innerhalb unserer eigenen Familie, dort, wo sonst jemand ein Importskript pflegen müsste.

Was zwischen Quelle und Ziel tatsächlich passiert

Diese Schritte kommen in jedem Ablauf vor, beim Umzug wie beim laufenden Abgleich.

Lesen
Die Daten kommen in Stapeln herein, standardmäßig 500 Datensätze je Seite. So scheitert auch eine Millionentabelle nicht am Speicher.
vollständig oder nur die Änderungen seit dem letzten Lauf
Struktur beschreiben
Eine Datendefinition legt fest, welche Felder ankommen, automatisch erkannt aus einer Beispieldatei.
Filtern
Eine Bedingung teilt den Strom in Treffer und Nicht-Treffer. Was nicht übernommen wird, lässt sich protokollieren.
Umrechnen
Aus „1.234,56“ wird eine Zahl, aus „31.12.2025“ ein Datum. Trennzeichen, Datumsformate und Typwechsel sind Konfiguration; Ableitungen bekommen ein Skript.
Abgleichen statt doppeln
Jeder Datensatz wird im Ziel gesucht und nur geschrieben, wenn sich wirklich etwas geändert hat. Fehlt ein eindeutiger Schlüssel, bildet eine Prüfsumme über mehrere Felder einen.
derselbe Lauf zweimal ergibt nicht zwei Datensätze
Schreiben und protokollieren
Das Ergebnis geht ins Ziel, der Lauf ins Protokoll: Status je Knoten, Dauer, Bilanz aus gelesen, angelegt, geändert, gelöscht.

Stand 12.08.2026 im eigenen Betrieb: 50 eingerichtete Datenquellen, 8 Adaptertypen, 93 protokollierte Läufe.

Auslöser und Protokoll: wann ein Lauf startet, was er hinterlässt

Womit sich ein Ablauf auslösen lässt

Von Hand über eine Schaltfläche, nach Zeitplan per Cron-Ausdruck, über einen Webhook, beim Auftauchen einer Datei in einem überwachten Verzeichnis, beim Hochladen in der Oberfläche oder bei einer Änderung in einer Datenbank.

Der Webhook nimmt JSON oder XML entgegen und antwortet im selben Format; als öffentlicher Endpunkt geschützt über ein Geheimnis in der Adresse und wahlweise eine IP-Freigabeliste. Ein Schalter am Ablauf hält jeden Lauf so fest, dass er sich später noch einmal abspielen lässt, mit denselben Daten wie beim ersten Mal. In der Praxis mischt man das: Der Personalstamm kommt nachts nach Zeitplan, die Bestellbestätigung geht hinaus, sobald der Vorgang fertig ist.

Was sich geändert hat, steht Feld für Feld

Ein Lauf ist ein Datensatz mit Status, Startzeit, Dauer und vier Zählern: gelesen, angelegt, geändert, gelöscht. Darunter liegt die Feinsicht: je berührtem Datensatz ein Eintrag, und darin je Feld der Wert vorher und der Wert nachher, das Entfernte rot und das Neue grün.

Bleibt ein Ablauf irgendwo hängen, zeigt die Ansicht des Ablaufs, an welchem Knoten es war, mit dessen Fehlermeldung und einer Stichprobe der Daten, die dort ankamen. Damit wird eine Datenübernahme testbar: denselben Lauf gegen eine Kopie fahren, die Bilanz mit der Erwartung vergleichen, erst dann umschalten.

Wo die Grenzen eines Transformators liegen

Er löst das Formatproblem, nicht das Fachlichkeitsproblem. Aus dem Fachlichkeitsproblem kommt die häufigste böse Überraschung in Migrationsprojekten. Steht dieselbe Firma im Altsystem als „Meier GmbH“, „Meier GmbH & Co. KG“ und „meier gmbh alt“, lassen sich Schreibweisen vereinheitlichen und Dubletten vorschlagen. Ob es dieselbe Firma ist, weiß nur Ihr Fachbereich. Diese Klärung gehört in den Plan, nicht in die Woche vor dem Umschalttag.

Der gefährlichste Fehler ist außerdem nicht der Absturz, sondern der stille Erfolg: Eine fremde Schnittstelle meldet „alles in Ordnung“, liefert die Nutzdaten aber unter einem anderen Schlüssel. Der Lauf ist grün, die Felder sind leer. Strukturprüfungen finden das nicht. Sichtbar wird es erst im Abgleich gegen die Rohantwort für einen bekannten Datensatz. Wir nehmen Anbindungen deshalb an echten Daten ab, nicht an einem grünen Häkchen.

Zuletzt zwei technische Grenzen: Ein Fehler bricht standardmäßig den ganzen Lauf ab, damit kein halb übertragener Bestand entsteht. Und der Transformator ist ein eigener Dienst, nicht Teil des generierten Codes. Er läuft bei uns oder in Ihrem Rechenzentrum, und ein Ablauf gegen ein internes System muss auch aus diesem Netz laufen.

Was Sie davon haben

Eine Anbindung statt eines Programms

Was sonst ein Schnittstellenprojekt wäre, ist eine Datenquelle plus ein Ablauf.

Wiederholbar und damit testbar

Sie spielen die Übernahme durch, statt am Umschalttag zum ersten Mal zu sehen, was ankommt.

Lesbar für den Nächsten

Wer in zwei Jahren nachsieht, warum ein Feld so gefüllt wird, braucht keine Entwicklungsumgebung.

In beide Richtungen

Aus der einmaligen Übernahme wird der dauerhafte Abgleich.

Weiterlesen

Häufige Fragen

Wie bekomme ich die Daten aus meinem Altsystem in eine neue Anwendung?

Über eine konfigurierte Datenquelle statt über ein Importprogramm: Sie hinterlegen, wie das Altsystem erreichbar ist, und verbinden die Felder grafisch mit denen der neuen Anwendung. Der Lauf ist wiederholbar: erst gegen eine Testkopie, dann produktiv.

Was kostet eine Schnittstelle?

Deutsche Softwaredienstleister veranschlagen auf ihren eigenen Preisseiten 3.500 bis 21.000 Euro je Schnittstelle, weil klassisch für jede Anbindung Code geschrieben und gepflegt wird. Konfiguriert statt programmiert bleibt die fachliche Klärung, der Bau entfällt.

Welche Systeme lassen sich anbinden?

Acht Adaptertypen: SQL-Datenbanken, MongoDB, CouchDB, Dateien in CSV, JSON, XML und Excel, REST, SOAP, LDAP-Verzeichnisdienste und weitere Anwendungen aus unserem Framework. Damit sind ERP- und Personalsysteme, Fuhrpark- oder Zeiterfassungsdienste erreichbar.

Ist das ein ETL-Tool?

Der Sache nach ja: extrahieren, transformieren, laden. Klassische ETL-Werkzeuge sind allerdings eigene Produkte mit eigener Lizenz, angeschafft für ein Data Warehouse. SOLUTIONS.transformer ist dagegen ein Dienst neben der Fachanwendung, für laufende Fachprozesse.

Was passiert, wenn dieselbe Sache im Altsystem dreimal anders geschrieben steht?

Dann muss jemand entscheiden, was gilt. Schreibweisen lassen sich vereinheitlichen und Dubletten vorschlagen. Ob zwei ähnliche Kundensätze dieselbe Firma sind, weiß nur Ihr Fachbereich. An dieser Klärung laufen Migrationsprojekte am häufigsten aus dem Zeitplan.