Unternehmen verbringen noch immer viel Arbeitszeit damit, Daten zwischen Systemen neu zu erfassen, und jede Ablösung eines ERP-, CRM- oder HR-Systems beginnt mit einem mühsamen Migrationsprojekt: das alte Schema verstehen, Felder zuordnen, Dubletten bereinigen, laden und abstimmen. Ein LLM-Agent entwirft das Mapping, schreibt und führt den Transformationscode aus, liest unstrukturierte Quellen, erfasst Daten per API oder Bildschirm und belegt die Vollständigkeit durch Abstimmung, während Menschen Mappings, Ausnahmen und den Go-live freigeben.
Problem & Nutzen
- Heute: zwei verschiedene Aufgaben. (1) Wiederkehrende Dateneingabe: Mitarbeitende kopieren Daten aus E-Mails, PDFs, Tabellen oder einem System in ein anderes, wo keine Integration besteht (Lieferantenstammdaten, Personalakten, Produktdaten). (2) Einmalige Migration: Berater und Datenmigrationsspezialisten ordnen Hunderte von Tabellen zu, schreiben ETL-Skripte und fahren mehrere Testläufe vor der Umstellung. Beides ist langsam, fehleranfällig und schwer nachzuprüfen.
- KI-Nutzen: Mapping-Vorschläge aus Schemanamen, Beispieldaten und Dokumentation; erzeugter und getesteter Transformationscode; semantische Dublettenerkennung und Normalisierung (Adressen, Einheiten, Codes); Extraktion aus unstrukturierten Quellen; Eingabe auf Oberflächenebene, wo APIs fehlen; automatisierte Abstimmung.
- Belege: uns ist kein neutraler Benchmark für die Einsparungen bei Migrationen über den gesamten Ablauf bekannt; messen Sie in einem Pilotprojekt.
Varianten
- ERP-/CRM-Migration (Großunternehmen): Umstellungen auf S/4HANA, Dynamics 365, Salesforce oder Workday mit Staging-Tabellen, mehreren Probeläufen und formaler Abnahme.
- Stammdaten-Onboarding (KMU): Lieferanten-, Kunden- oder Artikellisten aus Tabellen in Buchhaltungs- oder Shop-Systeme.
- Wiederkehrende Eingabe zwischen Systemen: Erfassung vom Portal ins ERP durch einen Computer-Use-Agenten (siehe AGENT-003).
- Eingabe aus Dokumenten: Formulare und Verträge werden ausgelesen und anschließend erfasst (siehe DOC-003, DOC-001, AGENT-004).
- Öffentliche Verwaltung / privat: Registerbereinigung unter strengen Archivpflichten; Verschieben von Kontakten oder Notizen zwischen Anwendungen.
So funktioniert es
- source discovery (schemas, exports, docs, samples)
- profiling (types, nulls, duplicates, outliers, code values)
- mapping proposal (source field
- target field + transformation rule + confidence)
- human review of mapping (data owner / migration lead approves)
- transformation code generation + unit tests on samples
- cleansing & dedup (rules first, LLM for fuzzy cases)
- dry-run load into sandbox target (API / import tool / UI agent)
- reconciliation (row counts, checksums, business totals, sample audit)
- exception queue
- human fix
- re-run
- production load + audit log + rollback plan
- Mapping und Codeerzeugung: Das LLM liest Schema, Feldbeschreibungen und Beispielzeilen und schlägt Mappings vor; ein Code-Modell schreibt SQL-/Python-/dbt-Transformationen, die deterministisch ausgeführt werden. Das Modell soll die Pipeline schreiben, nicht jede Zeile durch das LLM schicken; so bleiben Kosten, Latenz und Reproduzierbarkeit unter Kontrolle.
- LLM-Einsatz auf Zeilenebene: nur für unscharfe Aufgaben (Normalisierung von Freitext, Einordnung in Ziel-Codelisten, Extraktion aus Dokumenten), immer mit schemabeschränkter Ausgabe und Validierung.
- Eingabe über die Oberfläche: Ein Computer-Use-Agent füllt Masken für Systeme ohne API oder Importschnittstelle; das ist langsamer und weniger zuverlässig als Ladevorgänge per API und daher nur die Rückfalllösung.
- Mensch-in-der-Schleife (Human-in-the-Loop): Freigabe des Mappings, Regeln für Zusammenführungen/Löschungen, Datensätze mit geringer Sicherheit, Abnahme im Sandbox-System und die Entscheidung über den Produktiv-Go-live. Destruktive Aktionen laufen nie autonom.
Datenaufbereitung
Die Daten sind hier die Arbeit selbst: Quellexporte (CSV, Excel, XML, Datenbank-Dumps) aus dem Altsystem, gescannte Formulare und Verträge sowie das Zielschema mit seinen Codetabellen. In einem KMU liegen diese typischerweise im alten ERP oder CRM, auf Dateifreigaben, in Postfächern und in Papierordnern. Typische Lücken sind Dubletten, Freitextfelder, die Codes sein sollten, uneinheitliche Schreibweisen, fehlende Pflichtfelder, Scans ohne Textebene und unklare Verantwortung für die Stammdaten. Rechnen Sie damit, dass die Datenaufbereitung den größten Teil des Projekts ausmacht, oft mehr als die Hälfte des Aufwands.
Konkrete Schritte: Zuerst die Quellen inventarisieren und sauber extrahieren (siehe PREP-005), dann Papierakten digitalisieren und per OCR erfassen (PREP-006) sowie Altformate und Mailarchive umwandeln (PREP-007). Tabellen in saubere Tabellenstrukturen überführen (PREP-011) und ein Glossar der Felder und Codes vereinbaren (PREP-012). Die Daten mit offenen Werkzeugen wie OpenRefine oder pandas profilieren, Dubletten bereinigen und den Agenten das Feld-Mapping vorschlagen lassen, das die Datenverantwortlichen freigeben. Vor dem ersten Ladevorgang einen Testsatz abgestimmter Datensätze definieren (PREP-018). Personenbezogene Daten für Testläufe pseudonymisieren (PREP-022). Details zur Dokumentenextraktion stehen in DOC-014. Für die Gesamtprüfung nutzen Sie GUIDE-003.
Umsetzungswege
Welcher Weg für wen
- KMU: B. Migrationen müssen zu den eigenen ERP-/CRM-Schemata passen, und kein Standardprodukt kennt sie; eine Pipeline auf Cloud-APIs mit menschlicher Prüfung des Mappings passt am besten.
- Großunternehmen: B. Volumen und individuelle Zielschemata sprechen für eine eigene Pipeline auf Cloud-APIs, oft auf einer gemeinsamen internen KI-Plattform; gängige ETL-Werkzeuge ergänzen sie.
- Entwickler: B. Mapping-Logik, Validierung und Abstimmung sind Code; Cloud-LLM-APIs plus ein offenes Workflow-Werkzeug bieten die meiste Kontrolle.
- Öffentliche Verwaltung: C. Bürger- und Personaldaten in einem Altsystem sollten auf souveräner Infrastruktur bleiben; Modelle mit offenen Gewichten und eine selbst betriebene Workflow-Engine sind daher die sicherere Standardwahl.
Weg A — Kaufen (Standardsoftware)
- Migrationswerkzeuge der Hersteller: SAP Migration Cockpit (S/4HANA), Salesforce Data Loader [1] und Data Import Wizard, Microsoft Dynamics 365 Datenverwaltung und Power-Query-Dataflows, Lader für Workday und SuccessFactors. Wählen, wenn das Ziel eine dieser Suiten ist.
- Datenintegrations-/ETL-Plattformen: Informatica, Talend (Qlik), Fivetran, Airbyte, Boomi, Celonis-nahe Migrationswerkzeuge; europäisch: Talend (Ursprung Frankreich), Airbyte (in der EU gegründet, Cloud oder selbst betrieben), Syniti (Spezialist für Datenmigration, Niederlassungen in der EU). Viele enthalten inzwischen KI-Assistenten für das Mapping.
- RPA / agentische Automatisierung: UiPath, Automation Anywhere, Blue Prism (SS&C), Microsoft Power Automate Computer Use, SAP-Joule-Agenten; EU: Scheer PAS, Open-Source-Optionen im Stil von Robocorp.
- A wählen, wenn: der Zielhersteller einen unterstützten Migrationsweg bietet und das Datenvolumen moderat ist.
Weg B — Auf Cloud-KI-Diensten aufbauen (für die meisten KMU mit individuellem Bedarf empfohlen)
- Modelle: ein Frontier-LLM für Mapping, Codeerzeugung und strukturierte Extraktion (Claude, GPT, Gemini, Mistral als EU-Anbieter) in EU-Regionen über Azure OpenAI, Amazon Bedrock Frankfurt/Irland, Google Vertex EU oder Mistral La Plateforme. Bildextraktion über dieselben APIs oder Dokumenten-KI-Dienste.
- Agenten-Frameworks: Anthropic Claude Agent SDK / OpenAI Agents SDK, LangGraph, mit Werkzeugzugriff über MCP- Server für Datenbanken und SaaS-APIs; Computer-Use-Werkzeuge als Rückfall für die Oberfläche [3][4].
- Datenwerkzeuge: dbt, SQL-Engines (Postgres, DuckDB), Great Expectations oder Soda zur Validierung [5], Pydantic/JSON Schema für strukturierte Ausgaben, n8n zur Orchestrierung.
- B wählen, wenn: heterogene Quellen, individuelle Zielregeln oder kein passendes Standardwerkzeug vorliegen; die Berechtigungen des Agenten auf eine Sandbox beschränken, bis die Abstimmung bestanden ist.
Weg C — Selbst betreiben (Open Source)
- Modelle: Coding- und Allzweckmodelle mit offenen Gewichten (z. B. Qwen3-Coder / Qwen3, Mistral, gpt-oss, Llama-Familie), bereitgestellt über vLLM oder Ollama; Docling zum Auslesen von Dokumenten [6]; Modelle der Klasse Qwen-VL für gescannte Formulare.
- Stack: Airbyte OSS, dbt Core, Apache NiFi/Airflow, DuckDB, Great Expectations, Playwright oder browser-use für Oberflächenarbeit, OpenRefine für interaktive Bereinigung.
- Hardware: HW3 für starke Coding-Modelle; HW2 genügt für ein kleines Modell plus Regeln, wenn der größte Teil der Transformationslogik deterministisch ist. Nützlich bei der Migration sensibler Personal-, Patienten- oder Bürgerdaten.
Weg D — Eigenes Training
Selten nötig; nur für Entity Matching oder die Einordnung in Codelisten mit Tausenden bestätigter Paare aus früheren Migrationen.
Stand der Technik (2026)
- Agenten können aus Schema und Beispielen Transformationscode zuverlässig erzeugen und testen und Mappings vorschlagen, die Fachleute bei sauberen, gut dokumentierten Schemata meist bestätigen. Schlecht dokumentierte Altschemata (kryptische Spaltennamen, mehrfach belegte Felder, im Anwendungscode versteckte Geschäftsregeln) bleiben schwierig.
- Computer-Use-Agenten bedienen Oberflächen, sind aber langsamer und ungenauer als API-Aufrufe; in öffentlichen Benchmarks wie OSWorld haben sie sich stark verbessert, scheitern aber weiterhin an einem spürbaren Anteil langer Aufgaben [4]. Setzen Sie sie für Eingaben mit geringem Volumen oder als letzten Ausweg ein, mit Screenshots und Protokollen als Nachweis.
- MCP hat sich als üblicher Weg etabliert, Agenten kontrollierten Zugriff auf Datenbanken und Geschäftssysteme zu geben.
- Fehlerbilder: halluzinierte Mappings, die plausibel aussehen, stille Fehler bei der Umrechnung von Typ/Einheit/Währung, übereifrige Zusammenführung verschiedener Entitäten, in Quelldokumenten oder Freitextfeldern versteckte Prompt Injection, Teilladungen ohne Rollback und Agenten mit Schreibzugriff auf die Produktion.
- Grundsatz: Das LLM schlägt vor, deterministischer Code führt aus, die Abstimmung belegt.
Gemeinsame Bausteine & Kombinationen
- Gleicher Stack: AGENT-003 (GUI-Agenten), AGENT-002 (Workflow-Engine), AGENT-004 (Auftragserfassung), AGENT-011 (CRM-Pflege), DOC-001/DOC-003/DOC-014 (Dokumentenverarbeitung), CODE-005 (Modernisierung von Altcode).
Aufwand, Kosten & Kennzahlen
- Weg A: Wochen; Lizenz plus Umsetzungspartner; die Kosten steigen mit Umfang und Anzahl der Probeläufe.
- Weg B: 1-3 Monate für eine wiederverwendbare Pipeline; die LLM-Kosten sind gering, wenn das Modell Code schreibt und nur unscharfe Felder zeilenweise verarbeitet werden; Hauptkosten sind Tests und fachliche Validierung.
- Weg C: 2-4 Monate plus GPU-Betrieb.
- Kennzahlen: Anteil der ohne Änderung akzeptierten Mappings, Abstimmquote der Datensätze (geladen vs. erwartet), Rückweisungsquote und Zeit bis zur Korrektur, Dublettenquote vorher/nachher, Anzahl nötiger Probeläufe, manuelle Stunden pro 1.000 Datensätze, nach dem Go-live von Anwendern gefundene Datenfehler.
Menschen & Veränderung
Beziehen Sie die Geschäftsführung früh für Umfang und Budget ein, die Abteilungsleitung und die Datenverantwortlichen von Anfang an, denn sie geben das Mapping und die Umstellungsregeln frei. IT und Informationssicherheit richten Konten, Zugriffe nach dem Prinzip der minimalen Rechte und die Ladeumgebung ein; die oder der Datenschutzbeauftragte prüft die Rechtsgrundlage und den Auftragsverarbeitungsvertrag (AVV, Art. 28 DSGVO) und entscheidet über eine Datenschutz-Folgenabschätzung (DSFA, Art. 35 DSGVO), wenn Personal- oder Kundendaten in großem Umfang migriert werden. Endanwender sollten die Ausnahmewarteschlange prüfen und die migrierten Datensätze vor dem Go-live testen.
Betriebsrat: abhängig vom Einzelfall. Eine einmalige Migration überwacht keine Beschäftigten; protokolliert der Agent jedoch einzelne Nutzeraktionen oder arbeitet er über die Bildschirme der Beschäftigten, greift § 87 Abs. 1 Nr. 6 BetrVG, da die objektive Eignung genügt; in jedem Fall ist der Betriebsrat nach § 90 Abs. 1 Nr. 3 rechtzeitig zu informieren und die Hinzuziehung eines Sachverständigen nach § 80 Abs. 3 zu erwägen. Öffentliche Stellen beteiligen den Personalrat.
Beginnen Sie mit einem kleinen Pilotprojekt (eine Tabelle oder eine Abteilung), vergleichen Sie die Ergebnisse mit der manuellen Eingabe und behalten Sie vor jedem Massenladen einen menschlichen Freigabeschritt bei. Typische Sorgen sind Arbeitsplatzverlust und die Angst vor Fehlern in den Stammdaten; begegnen Sie ihnen, indem Sie Zeit für Prüf- und Qualitätsarbeit umwidmen und den Abstimmbericht zeigen. Fördern Sie die KI-Kompetenz mit kurzen Schulungen (die KI-Verordnung (AI Act) verlangt in Art. 4 Maßnahmen dazu). Siehe GUIDE-009, GUIDE-004 und GUIDE-008.
Risiken, Regulierung & Compliance
- KI-Verordnung (AI Act): in der Regel minimales Risiko (Art. 4 KI-Kompetenz gilt). Hochrisiko liegt vor, wenn die migrierten Daten in Entscheidungen nach Anhang III einfließen (z. B. Auswahlsysteme im Personalwesen) und der Agent selbst sie beeinflusst; dokumentieren Sie die Einstufung.
- DSGVO: Migrationen verarbeiten personenbezogene Daten (Beschäftigte, Kunden, Patienten). Wenden Sie Datenminimierung (Art. 5), Zweckbindung, Auftragsverarbeitungsverträge mit Modellanbietern, EU-Region oder eigenen Betrieb an und löschen Sie überholte Datensätze nach den Aufbewahrungsregeln, statt alles zu migrieren [2]. Datenübermittlungen an Modell-Endpunkte außerhalb der EU brauchen einen Übermittlungsmechanismus.
- Buchführung/Prüfung: Finanzstamm- und Offene-Posten-Daten erfordern Nachvollziehbarkeit (z. B. GoBD in Deutschland); bewahren Sie Mapping-Spezifikationen, Ladeprotokolle und Abstimmnachweise als Migrationsdokumentation auf.
- Sicherheit: Servicekonten mit minimalen Rechten, zuerst Sandbox, keine Geheimnisse in Prompts, Quellinhalte als nicht vertrauenswürdige Eingabe behandeln (Prompt Injection), API der Oberfläche vorziehen, menschliche Freigabe für Löschungen und Massenänderungen.
- Gegenmaßnahmen: versionierte Mappings, Probeläufe, Abstimmungsschranken, Rollback-Snapshots, vollständige Protokollierung der Agentenaktionen.
Erste Schritte
- Quellen und Ziel inventarisieren; ein abgegrenztes Objekt (z. B. Lieferantenstammdaten) als Pilot wählen.
- Die Daten profilieren und den Agenten ein Mapping entwerfen lassen; die Datenverantwortlichen prüfen jede Zeile.
- Transformationen als Code mit Tests erzeugen; einen Probelauf in einer Sandbox laden und abstimmen.
- Eine Prüfwarteschlange für Ausnahmen ergänzen und jede Agentenaktion protokollieren; Go/No-go-Schwellen festlegen.
- Auf weitere Objekte ausweiten; einen GUI-Agenten nur dort einsetzen, wo es keine API oder kein Importwerkzeug gibt.
Quellen
- Salesforce — Data Loader guide — https://developer.salesforce.com/docs/atlas.en-us.dataLoader.meta/dataLoader/data_loader.htm
- Regulation (EU) 2016/679 (GDPR) — https://eur-lex.europa.eu/eli/reg/2016/679/oj
- Anthropic — Computer use tool documentation — https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/computer-use-tool
- OSWorld benchmark — https://os-world.github.io/
- Great Expectations — https://github.com/great-expectations/great_expectations
- Docling project — https://github.com/docling-project/docling
- Model Context Protocol — https://modelcontextprotocol.io
- Airbyte — https://github.com/airbytehq/airbyte
- Regulation (EU) 2024/1689 (AI Act) — https://eur-lex.europa.eu/eli/reg/2024/1689/oj