Kaum eine Magento-2-Migration endet beim Launch. Sie endet in dem Moment, in dem ein Shop-Betreiber das erste Mal versucht, 8.000 Produkte per CSV zu aktualisieren und feststellt, dass die Datei stillschweigend abgelehnt wird — ohne Fehlermeldung, ohne Rollback, ohne Hinweis, dass ein einziges Anführungszeichen in einer Beschreibungsspalte das gesamte Import-Verhalten umdreht.
Der Magento-2-Import und -Export gehört damit zu den unterschätztesten Dauerbaustellen im E-Commerce-Stack. Wer Produktdaten, Kundendaten oder Bestellungen zuverlässig zwischen Magento 2, Adobe Commerce und angrenzenden Systemen bewegen will, braucht mehr als die Admin-Oberfläche unter System → Datenübertragung. Er braucht ein Verständnis dafür, was das native Modul leistet, wo es 2026 an Grenzen stößt und wann der Wechsel auf eine externe Datenpipelines-Lösung günstiger ist als jede Nachtarbeit am CSV-Delimiter.
Was leistet der native Magento-2-Import — und was nicht?
Die eingebaute Import-Funktion deckt eine definierte Menge an Entitäten ab: Produkte (einfach, konfigurierbar, gruppiert, Bundle, virtuell, downloadbar), Kunden, Kundenadressen, erweiterte Preise, Bestellungen sowie eine Reihe von Adobe-Commerce-spezifischen Typen wie CMS-Blöcke und -Seiten. Bestellungen lassen sich dabei ausschließlich importieren, nicht exportieren — ein Punkt, der in vielen Migrationsprojekten erst spät auffällt.
Technisch arbeitet das native Modul ausschließlich mit CSV. Adobe Commerce liefert daneben ein Experimental-Feature für tabellarische Importe, aber die Format-Flexibilität bleibt gering. Wer JSON-Payloads aus einem PIM, XML-Feeds aus einem ERP oder REST-Streams aus einem OMS verarbeiten will, muss konvertieren. Das ist konzeptionell kein Problem, kostet in der Praxis aber genau dann Zeit, wenn Datenmengen und Feldfrequenz steigen.
Ein oft übersehener Punkt betrifft den Import von Bestellungen. Adobe Commerce unterstützt seit Version 2.4.6 Importe über die API für Bestellungen mit Ursprung in externen Systemen, was DACH-Händler mit bestehender ERP-Landschaft vor neue Entscheidungen stellt: Bleibt der Bestellabgleich im Magento-Admin, oder wandert er in eine Middleware? Wer 2026 auf Adobe Commerce Cloud setzt, sollte diese Frage vor dem Anschluss an ein Warenwirtschaftssystem klären, nicht danach.
Warum scheitern Importe in der Praxis — und wie verhindert man es?
Die häufigsten Fehlerquellen sind selten spektakulär. Sie sind banal — und genau deshalb gefährlich:
CSV-Kodierung ist der Klassiker. Magento erwartet UTF-8, oft ohne BOM. Deutsche Umlaute, die in Excel als ANSI gespeichert werden, landen als Mojibake im Shop. Ein Shop mit 40.000 SKUs und fehlerhafter Zeichenkodierung produziert reihenweise Support-Tickets, weil Produktnamen unlesbar werden.
Spaltenreihenfolge wird vom nativen Importer nicht erzwungen, aber Spaltennamen müssen exakt den Attributcodes entsprechen. Ein Tippfehler im Header — sku statt sku in einem Excel-Header mit Leerzeichen — führt dazu, dass die Spalte ignoriert wird, ohne dass der Importer warnt.
Mehrdeutige Werte in Auswahl-Attributen: Wer einen Import mit einer Attributoption ausführt, die im Shop noch nicht existiert, kann das Verhalten über die Einstellung Felder erstellen steuern. Ohne aktivierte Option wird der Wert verworfen, und die Produkte landen ohne Merkmal im Katalog.
Bestands- und Preisabgleich erfolgt bei aktivierter Option in Echtzeit, kann aber bei mehreren Tausend betroffenen SKUs zu Indexer-Konflikten führen, wenn parallel Cron-Jobs laufen. Wer Importe timing-technisch nicht vom Reindexing entkoppelt, produziert inkonsistente Preise im Frontend — zeitweise, oft schwer reproduzierbar.
- Vor jedem Import: ein Probe-Datensatz. Ein einzelnes Produkt, eine Bestellung, ein Kunde. Wenn das funktioniert, skalieren.
- Immer Dry-Run-fähig arbeiten. Magento bietet keinen nativen Dry-Run — also extern validieren, bevor die Datei in die Admin-Oberfläche geht.
- Datenvolumen splitten. Über 5.000 Zeilen pro Datei steigt die Wahrscheinlichkeit von Timeouts. 2.000 bis 3.000 Zeilen sind im DACH-Umfeld üblich als sichere Batch-Größe.
Wie unterscheiden sich Produkt-, Kunden- und Bestellimporte?
Produktimporte sind das bekannteste Einsatzfeld und gleichzeitig das komplexeste. Ursache: Magento 2 speichert Attribute in einem EAV-Modell (Entity-Attribute-Value). Ein Import schreibt also nicht in eine Zeile, sondern potenziell in dutzende Tabellen. Konfigurierbare Produkte erfordern zusätzlich eine Verknüpfung zwischen Parent-SKU und Simple-Varianten — wer das Schema nicht kennt, importiert 400 Varianten und wundert sich, dass im Frontend keine Konfiguration erscheint.
Kundenimporte wirken einfacher und sind es auch, bis Multi-Store-Views ins Spiel kommen. Ein Kunde kann pro Website existieren, nicht nur global. Wer Kundendaten aus einem CRM synchronisiert, stolpert regelmäßig darüber, dass website_id und store_id unterschiedlich interpretiert werden. In DACH-Setups mit einer B2B- und einer B2C-Website ist das ein Strukturproblem, kein Datenproblem.
Bestellimporte sind der am wenigsten beachtete Bereich — und der, wo 2026 die größten Sicherheits- und Compliance-Fragen liegen. Bestellungen enthalten personenbezogene Daten im Sinne der DSGVO. Wer sie per CSV zwischen Systemen bewegt, muss die Verarbeitungsverhältnisse sauber dokumentieren. Adobe Commerce selbst erlaubt keinen Bestellexport über die Admin-Oberfläche; der Ausweg führt über die REST- oder GraphQL-API. Wer das umgeht, arbeitet mit Tools, die im Support-Fall nicht abgedeckt sind.
„Der gefährlichste Satz in einem Magento-Projekt lautet: ‚Das haben wir früher auch mit einem Plugin gelöst.‘“ — Projekterfahrung aus zahlreichen Adobe-Commerce-Migrationen.
Wann lohnt sich der Wechsel zu externen Integrationstools?
Adobe selbst bietet mit dem Data Transfer-Tool für Adobe Commerce Cloud einen auf S3 basierenden Bulk-Mechanismus, der deutlich performanter ist als der Admin-Import. Für kleinere Händler ist das irrelevant. Für Shops mit mehreren zehntausend SKUs, täglichen Aktualisierungen aus einem PIM und mehreren Verkaufskanälen ist es oft die einzige tragfähige Option.
Der Markt jenseits von Adobe ist 2026 breiter geworden. Werkzeuge wie das Magento-2-Modul von Firebear Studio oder die Plattformen von Akeneo, Pimcore oder Celigo positionieren sich als Middleware zwischen Quellsystem, Magento und nachgelagerten Zielen. Ihr Vorteil liegt nicht in der Funktion allein, sondern in der Fehlerbehandlung: Logging pro Feld, Rollback-Fähigkeit, Mapping-Versionierung. Genau diese Punkte fehlen dem nativen Importer.
Die Entscheidung lässt sich an einer einfachen Zahl festmachen. Wer pro Monat mehr als 20 Stunden mit manueller Importpflege, CSV-Debugging und Datenkorrekturen verbringt, bezahlt jede externe Lösung nach wenigen Quartalen zurück. Wer quartalsweise Preise aktualisiert, für den ist der native Import weiterhin ausreichend.
Was ändert sich 2026 konkret?
Adobe forciert seit den Versionen 2.4.7 und 2.4.8 die Abkehr von veralteten PHP-Praktiken sowie die Konsolidierung der API-Layer. Für Import- und Exportprozesse bedeutet das zweierlei: Erstens steigen die Mindestanforderungen an Serverumgebung und PHP-Version, was ältere Erweiterungen aus dem Ökosystem obsolet macht. Zweitens wächst die Bedeutung von GraphQL — auch für Bulk-Operationen, die bisher klassisch über REST liefen.
Für DACH-Händler kommt ein zweiter Faktor hinzu: die zunehmende Regulierung von Produktdaten im Kontext der EU-Produktsicherheitsverordnung und erweiterter Sorgfaltspflichten. Produktdatenimporte transportieren 2026 mehr Compliance-relevante Felder als vor fünf Jahren — Herstellerinformationen, Sicherheitshinweise, verantwortliche Wirtschaftsakteure. Wer sein Import-Schema starr hält, wird es in den nächsten 18 Monaten anpassen müssen. Wer es von Anfang an erweiterbar konzipiert, spart sich den Umbau.
Die pragmatische Empfehlung lautet daher: Behandeln Sie Magento-2-Importe nicht als Admin-Aufgabe, sondern als Teil Ihrer Datenarchitektur. Mit einem validierten CSV-Schema, dokumentiertem Mapping und einer klaren Grenze zwischen nativem Import und externer Middleware. Wer das einmal sauber aufsetzt, verbringt die nächsten Jahre nicht mit Debugging — sondern mit dem Ausbau des Shops.