Companies still spend large amounts of staff time re-keying data between systems, and every ERP, CRM or HR replacement starts with a painful migration project: understanding the old schema, mapping fields, cleaning duplicates, loading and reconciling. An LLM agent drafts the mapping, writes and runs the transformation code, reads unstructured sources, enters data via API or screen and proves completeness through reconciliation, while humans approve mappings, exceptions and the go-live.
Problem & value
- Today: two distinct jobs. (1) Recurring data entry: staff copy data from emails, PDFs, spreadsheets or one system into another where no integration exists (supplier master data, employee records, product data). (2) One-off migration: consultants and data-migration specialists map hundreds of tables, write ETL scripts and run several test loads before cut-over. Both are slow, error-prone and hard to audit.
- AI value: mapping suggestions from schema names, sample data and documentation; generated and tested transformation code; semantic duplicate detection and normalisation (addresses, units, codes); extraction from unstructured sources; GUI-level entry where APIs are missing; automated reconciliation.
- Evidence: no neutral benchmark of end-to-end migration savings is known to us; measure on a pilot.
Variants
- ERP/CRM migration (enterprise): S/4HANA, Dynamics 365, Salesforce or Workday cut-overs with staging tables, multiple mock loads and formal sign-off.
- Master-data onboarding (SMB): supplier, customer or article lists from spreadsheets into accounting or shop systems.
- Recurring swivel-chair entry: portal-to-ERP keying handled by a computer-use agent (see AGENT-003).
- Document-to-system entry: forms and contracts parsed then keyed (see DOC-003, DOC-001, AGENT-004).
- Public sector / private: register consolidation under strict archive duties; moving contacts or notes between apps.
How it works
- 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 and code generation: the LLM reads schema, field descriptions and sample rows and proposes mappings; a code model writes SQL/Python/dbt transformations that are executed deterministically. The model should write the pipeline, not push every row through the LLM; this keeps cost, latency and reproducibility under control.
- Row-level LLM use: only for fuzzy tasks (free-text normalisation, classification into target code lists, extraction from documents), always with schema-constrained output and validation.
- GUI entry: a computer-use agent fills screens for systems without API or import interface; slower and less reliable than API loads, so it is the fallback.
- Human-in-the-loop: mapping approval, rules for merges/deletions, low-confidence records, sandbox sign-off and the production go-live decision. Destructive actions are never autonomous.
Data preparation
The data here is the work itself: source exports (CSV, Excel, XML, database dumps) from the legacy system, scanned forms and contracts, and the target schema with its code tables. In an SMB these typically live in the old ERP or CRM, on file shares, in mailboxes and in paper folders. Typical gaps are duplicates, free-text fields that should be codes, inconsistent spellings, missing mandatory fields, scans without text layer and unclear ownership of the master data. Expect data preparation to be the largest part of the project, often more than half of the effort.
Concrete steps: first inventory the sources and extract them cleanly (see PREP-005), then digitise and OCR paper files (PREP-006) and convert legacy formats and mail archives (PREP-007). Restructure spreadsheets into tidy tables (PREP-011) and agree a glossary of fields and codes (PREP-012). Profile the data with open tools such as OpenRefine or pandas, deduplicate, and let the agent propose the field mapping, which the data owner approves. Define a test set of reconciled records (PREP-018) before the first load. Pseudonymise personal data for test runs (PREP-022). Document-extraction details are covered in DOC-014. For the overall check use GUIDE-003.
Implementation paths
Which path for whom
- SMB: B. Migrations must fit the company's own ERP/CRM schemas and no off-the-shelf product knows them; a cloud-API pipeline with human review of the mapping fits best.
- Enterprise: B. Volume and custom target schemas favour an own pipeline on cloud APIs, often on a shared internal AI platform; commodity ETL tools complement it.
- Developer: B. Mapping logic, validation and reconciliation are code; cloud LLM APIs plus an open workflow tool give the most control.
- Public sector: C. Citizen and staff records in a legacy system should stay on sovereign infrastructure, so open-weight models and a self-hosted workflow engine are the safer default.
Path A — Buy (off-the-shelf)
- Vendor migration tooling: SAP Migration Cockpit (S/4HANA), Salesforce Data Loader [1] and Data Import Wizard, Microsoft Dynamics 365 data management and Power Query dataflows, Workday and SuccessFactors loaders. Choose when the target is one of these suites.
- Data integration / ETL platforms: Informatica, Talend (Qlik), Fivetran, Airbyte, Boomi, Celonis-adjacent migration tools; European: Talend origin (France), Airbyte (EU-founded, cloud or self-host), Syniti (data migration specialist, offices in EU). Many now include AI mapping assistants.
- RPA / agentic automation: UiPath, Automation Anywhere, Blue Prism (SS&C), Microsoft Power Automate computer use, SAP Joule agents; EU: Scheer PAS, Robocorp-style open source options.
- Choose A when: the target vendor provides a supported migration path and the data volume is moderate.
Path B — Build on cloud APIs (recommended for most SMBs with custom needs)
- Models: a frontier LLM for mapping, code generation and structured extraction (Claude, GPT, Gemini, Mistral as EU provider) in EU regions via Azure OpenAI, Amazon Bedrock Frankfurt/Ireland, Google Vertex EU or Mistral La Plateforme. Vision extraction via the same APIs or document AI services.
- Agent frameworks: Anthropic Claude Agent SDK / OpenAI Agents SDK, LangGraph, with tool access via MCP servers for databases and SaaS APIs; computer-use tools for GUI fallback [3][4].
- Data tooling: dbt, SQL engines (Postgres, DuckDB), Great Expectations or Soda for validation [5], Pydantic/JSON Schema for structured outputs, n8n for orchestration.
- Choose B when: heterogeneous sources, custom target rules, or no suitable packaged tool; keep agent permissions limited to a sandbox until reconciliation passes.
Path C — Self-host (open source)
- Models: open-weight coding and general models (e.g. Qwen3-Coder / Qwen3, Mistral, gpt-oss, Llama family) served via vLLM or Ollama; Docling for document parsing [6]; Qwen-VL class models for scanned forms.
- Stack: Airbyte OSS, dbt Core, Apache NiFi/Airflow, DuckDB, Great Expectations, Playwright or browser-use for GUI work, OpenRefine for interactive cleansing.
- Hardware: HW3 for strong coding models; HW2 suffices for a small model plus rules where most transformation logic is deterministic. Useful when migrating sensitive HR, patient or citizen data.
Path D — Custom training
Rarely needed; only for entity matching or code-list classification with thousands of confirmed pairs from earlier migrations.
State of the art (2026)
- Agents can reliably generate and test transformation code from schema plus samples, and propose mappings that experts mostly confirm on clean, well-documented schemas. Poorly documented legacy schemas (cryptic column names, overloaded fields, business rules hidden in application code) remain hard.
- Computer-use agents operate GUIs but are slower and less accurate than API calls; on public benchmarks such as OSWorld they have improved strongly but still fail a meaningful share of long tasks [4]. Use them for low-volume or last-resort entry with screenshots and logs as evidence.
- MCP has become the common way to give agents governed access to databases and business systems.
- Failure modes: hallucinated mappings that look plausible, silent type/unit/currency conversion errors, over-eager merges of distinct entities, prompt injection hidden in source documents or free-text fields, partial loads without rollback, and agents with write access to production.
- Principle: the LLM proposes, deterministic code executes, reconciliation proves.
Shared resources & combinations
- Same stack: AGENT-003 (GUI agents), AGENT-002 (workflow engine), AGENT-004 (order entry), AGENT-011 (CRM hygiene), DOC-001/DOC-003/DOC-014 (document parsing), CODE-005 (legacy code modernisation).
Effort, cost & KPIs
- Path A: weeks; licence plus implementation partner; cost scales with scope and number of mock loads.
- Path B: 1-3 months for a reusable pipeline; LLM cost is small when the model writes code and only fuzzy fields go row-by-row; main cost is testing and business validation.
- Path C: 2-4 months plus GPU operations.
- KPIs: share of mappings accepted without change, record reconciliation rate (loaded vs. expected), reject rate and time to fix, duplicate rate before/after, number of mock loads needed, manual hours per 1,000 records, post-go-live data defects found by users.
People & change
Involve management early for scope and budget, and the department lead and data owners from the start, because they approve the mapping and the cut-over rules. IT and information security set up accounts, least-privilege access and the load environment; the data protection officer checks the legal basis and the processor contract (AVV, Art. 28 GDPR) and decides on a DPIA (Art. 35 GDPR) when HR or customer data is migrated at scale. End users should review the exception queue and test the migrated records before go-live.
Works council: depends. A one-off migration does not monitor staff, but if the agent logs individual user actions or operates through employees' screens, §87(1) no. 6 BetrVG applies as objective suitability suffices; in any case inform the council in good time under §90(1) no. 3 and consider an expert under §80(3). Public bodies involve the Personalrat.
Start with a small pilot (one table or one department), compare results to manual entry, and keep a human release step before every bulk load. Typical concerns are job loss and fear of errors in master data; address them by reallocating time to review and quality work and by showing the reconciliation report. Support AI literacy with short training (AI Act Art. 4 requires measures to support it). See GUIDE-009, GUIDE-004 and GUIDE-008.
Risks, regulation & compliance
- EU AI Act: typically minimal risk (Art. 4 AI literacy applies). It becomes high-risk if the migrated data feeds Annex III decisions (e.g. HR selection systems) and the agent itself influences them; document the classification.
- GDPR: migrations process personal data (employees, customers, patients). Apply data minimisation (Art. 5), purpose limitation, processing agreements with model providers, EU region or self-hosting, and deletion of obsolete records according to retention rules rather than migrating everything [2]. Data transfers to non-EU model endpoints need a transfer mechanism.
- Bookkeeping/audit: financial master and open-item data requires traceability (e.g. GoBD in Germany); keep mapping specs, load logs and reconciliation evidence as migration documentation.
- Security: least-privilege service accounts, sandbox first, no secrets in prompts, treat source content as untrusted input (prompt injection), prefer API over GUI, human approval for deletes and bulk updates.
- Mitigations: versioned mappings, dry runs, reconciliation gates, rollback snapshots, full audit trail of agent actions.
Getting started
- Inventory sources and target; choose one bounded object (e.g. supplier master data) as pilot.
- Profile the data and let the agent draft a mapping; have the data owner review every line.
- Generate transformations as code with tests; run a dry-run load into a sandbox and reconcile.
- Add a review queue for exceptions and log every agent action; define go/no-go thresholds.
- Extend to further objects; use a GUI agent only where no API or import tool exists.
Sources
- 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