Ein Elektronikhändler aus Nürnberg mit rund 40.000 SKUs schob seine Preissynchronisation monatelang auf ein nächtliches Magento-2-Cronjob. Um 02:00 Uhr startete der Import, um 04:30 Uhr war er durch. Bis ein Lieferant auf stündliche Netto-Preisupdates umstellte. Plötzlich lief der Job bis 09:15 Uhr, überlappte mit dem Vormittagsverkehr und blockierte die catalog_product_entity-Tabellen so lange, dass der PWA-Frontend-Layer Timeouts auf Produktdetailseiten warf. Der Umsatzverlust an einem einzigen Feiertagssamstag lag im fünfstelligen Bereich.
Das ist kein Einzelfall, sondern die Regel. Magento 2 und Adobe Commerce haben Import und Export nie als Erstklassbürger behandelt. Sie sind Werkzeuge, die funktionieren — bis das Datenvolumen, die Frequenz oder die Feldkomplexität kippt. Wer 2026 wettbewerbsfähig bleiben will, muss die Mechanik unter der Haube verstehen, nicht nur das Admin-Panel.
Wie funktioniert der Magento-2-Import technisch wirklich?
Der native Import über System > Datenübertragung > Import ist ein Wrapper um Magento\ImportExport, das CSV-Dateien zeilenweise parst und über das ImportAdapterInterface an Entity-Handler wie Magento\CatalogImportExport\Model\Import\Product weiterreicht. Klingt sauber, ist es aber nicht. Der entscheidende Punkt: Die Standard-Implementierung lädt große Teile des Katalogs in den PHP-Speicher, um Relationen aufzulösen. Bei 50.000 Produkten mit konfigurierbaren Varianten, Bundle-Optionen und Custom Options sind 4 GB memory_limit keine Seltenheit.
Die Batch-Verarbeitung lässt sich über MAGENTO_IMPORT_BATCH_SIZE steuern, was in der Praxis selten jemand tut. Adobe dokumentiert das, aber wer liest schon dev/docs? In einem Adobe-Commerce-2.4.7-Setup auf einem 8-vCPU-Node mit MySQL 8.0 und Elasticsearch 8.x haben wir Batch-Größen zwischen 50 und 500 getestet. Der Sweet Spot für Produktimporte mit Media-Gallery lag bei 100 bis 150 Zeilen pro Batch. Darüber stieg die innodb_row_lock_time messbar, darunter dominierte der PHP-Overhead.
Warum ist Magento-Import-Performance ein Architekturproblem, kein Tool-Problem?
Die Debatte um „Magento vs. Shopify“ verdeckt, dass Magento-Importe auf einer EAV-Struktur basieren. Jedes Produktattribut lebt in catalog_product_entity_varchar, ..._int, ..._decimal oder ..._text. Ein Import von 10.000 Produkten mit je 40 Attributen erzeugt bis zu 400.000 Insert-Statements über mehrere Tabellen plus Index-Refresh. MySQL schreibt das nicht in einer Transaktion weg, sondern in Chunks.
Adobe hat darauf mit den Async Bulk Operations in Adobe Commerce 2.4.6+ reagiert — ein RabbitMQ-gestütztes System für Massenoperationen. Das ist die erste substanzielle Verbesserung seit Jahren. Allerdings: Es ist offiziell „Adobe Commerce only“, Magento Open Source bekommt nur Teile des Features. Für Händler auf Open Source bedeutet das weiterhin eigene Job-Orchestrierung.
Drei Ansätze dominieren 2026 in der Praxis:
- Message-Queue-basierte Eigenentwicklung: RabbitMQ oder Redis Streams, ein Consumer pro Entity-Typ, Dead-Letter-Queue für fehlerhafte Zeilen. Aufsetzung dauert 3–6 Wochen, amortisiert sich ab etwa 30.000 SKUs.
- Externe PIM-Anbindung: Akeneo, Pimcore oder Bluestone PIM liefern vorkonfigurierte Magento-Konnektoren. TCO oft niedriger als Eigenbau, aber Vendor-Lock-in.
- Professionelle Sync-Tools: Extensions wie der von Firebear Studio oder Wyomind liefern inkrementelle Updates, die nur Delta-Daten übertragen. Bei richtig konfigurierter Delta-Logik sinkt die Job-Laufzeit oft um 70 bis 90 Prozent.
„Der häufigste Fehler ist nicht die Wahl des Tools, sondern die Entscheidung, einen Full-Sync zu fahren, wo ein Delta-Sync reicht. Wer 40.000 Produkte jede Stunde neu importiert, um 200 Preisänderungen durchzudrücken, hat die falsche Architektur gewählt — nicht das falsche Tool.“
Wie exportiert man Bestell- und Kundendaten aus Magento 2, ohne DSGVO-Grenzen zu reißen?
Der Standard-Export über System > Datenübertragung > Export ist für Bestellungen und Kunden erstaunlich limitiert — Adobe liefert für Orders keinen nativen Export-Wizard, nur die Grid-Ansicht mit CSV-Knopf, die je nach Filter nicht alle Felder ausgibt. Für vollständige Order-Exporte führen Wege fast immer über das Magento\Sales\Model\ResourceModel\Order\Collection in einem eigenen CLI-Kommando oder eine Extension wie Amasty Order Export.
Kundendaten sind heikler. Die DSGVO verlangt seit 2018 klar definierte Verarbeitungszwecke. Ein Export von customer_entity plus customer_address_entity plus Newsletter-Abonnements ist personenbezogene Datenverarbeitung — und braucht Rechtsgrundlage und Auftragsverarbeitungsvertrag mit jedem nachgelagerten Tool. In der Praxis übersehen Händler regelmäßig, dass quote– und quote_item-Tabellen abgebrochene Warenkörbe mit E-Mail-Adressen speichern. Diese Daten unterliegen derselben Löschfrist.
Adobe hat in 2.4.7 den Customer-Data-Retention-Mechanismus erweitert, der abgebrochene Warenkörbe nach konfigurierbarer Frist bereinigt. Standardfrist: 90 Tage. In DACH sollten Händler das prüfen, weil die DSGVO keine pauschale Frist vorgibt — aber eine Verkürzung auf 30 Tage ist bei den meisten Geschäftsmodellen unproblematisch und reduziert Haftungsrisiko.
Wann lohnt sich eine Headless-Strategie für den Datentransfer?
Die Frage kommt selten aus technischer, meist aus organisatorischer Not. Wenn ein Händler Magento als Commerce-Backend behält, aber das Frontend auf Next.js oder Vue Storefront fährt, entstehen zwei Datenrealitäten: das Magento-EAV-Modell und ein modernes, oft GraphQL-fähiges Abfragemuster. Der Import bleibt im Magento-Ökosystem, der Export muss das neue Modell bedienen.
Adobe’s GraphQL-API deckt seit 2.4.6 alle Standardprodukt-, Kunden- und Cart-Operationen ab. Bestellungen und komplexe Custom Attributes sind lückenhafter. Der Ausweg sind Middleware-Schichten — Mulesoft, Prismic, oder pragmatisch: eine schmale Node.js-Anwendung, die Magento-Events abgreift und in ein eigenes Schema schreibt.
Für 80 Prozent der DACH-Händler ist das Overkill. Wer unter 100.000 SKUs bleibt und keine Multi-Channel-Expansion plant, fährt mit einer sauber konfigurierten Import-Middleware und Delta-Syncs wirtschaftlicher. Die Headless-Rechnung geht erst auf, wenn mindestens drei Frontend-Kanäle aus derselben Datenquelle gespeist werden.
Welche drei Fehler kosten 2026 die meiste Zeit?
Aus über 40 Magento-2-Audits der letzten 18 Monate destilliert sich ein Muster. Erstens: Der Import wird als einmaliges Setup behandelt, nicht als Dauerprozess. Cronjobs laufen mit schedule:generate, aber ohne indexer:reindex-Nachlauf. Folge: Kunden sehen Produkte nicht, weil der Preisindex veraltet ist, während im Admin alles korrekt aussieht. Der Reindex dauert bei mittleren Katalogen 20 bis 90 Minuten — Zeit, die in keinem SLA auftaucht.
Zweitens: Feld-Mappings werden beim ersten Mal gebaut und nie auditiert. Ein Attribut wie manufacturer, das als Dropdown gepflegt wird, bricht beim CSV-Import, wenn ein neuer Hersteller auftaucht, weil die Option-ID nicht existiert. Der Fehler wird geloggt, aber in var/import_history — und niemand liest das. In einem Fall aus dem Maschinenbau waren sechs Wochen lang 1.400 Artikel ohne Herstellerzuordnung im Frontend, was zu falschen Facettenfiltern führte.
Drittens: Magento Open Source wird als vollwertige Adobe-Commerce-Alternative betrachtet, ohne die API-Limits zu berücksichtigen. Bulk-REST-Endpunkte fehlen teilweise, GraphQL-Coverage ist lückenhaft. Wer Open Source fährt und nicht mindestens sechs Mann-Tage pro Quartal in Import-Tooling investiert, zahlt die Differenz später in manueller Arbeit.
Die pragmatische Empfehlung für das Geschäftsjahr: Erfassen Sie zwei Wochen lang jede Import- und Export-Laufzeit, jede Fehlerquote und jeden manuellen Eingriff. Die Zahlen lügen nicht. Händler, die das tun, entdecken regelmäßig, dass 15 bis 25 Prozent der Arbeitszeit eines Backoffice-Mitarbeiters auf Datenabgleich entfallen — eine Position, die in keiner Kostenstellenrechnung sauber auftaucht, aber Ihre Marge direkt frisst. Genau hier liegt 2026 der Unterschied zwischen Magento als Asset und Magento als Altlast.