Magento 2 bringt einen Datenimport mit. Für viele Händler reicht er nicht. Die Entscheidung zwischen Bordmitteln, Adobe-Commerce-Funktionen, Drittanbieter-Extensions oder Eigenentwicklung ist 2026 keine Geschmacksfrage mehr, sondern eine Kostenfrage — und eine Frage der Datenkomplexität. Wer 50.000 SKUs mit konfigurierbaren Varianten und mehreren Shops pro Woche abgleichen muss, fährt mit einer anderen Lösung als ein Händler mit 800 Artikeln.
Was Magento von Haus aus mitbringt — und wo es endet
Der native Import in Magento Open Source verarbeitet CSV-Dateien über die Konsole, etwa per bin/magento import:run, oder im Admin über Data Transfer. Für Erstbefüllungen und einfache Stammdaten genügt das. Die Grenzen zeigen sich im Betrieb: Bei großen Katalogen brechen Imports regelmäßig an PHP-Limits, Speichergrenzen und der Single-Thread-Verarbeitung ab. Wer Bilder, Custom Attributes und Multi-Store-Zuordnungen gleichzeitig synchronisieren will, stößt schnell an die Decke des Bordwerkzeugs.
Adobe Commerce (ehemals Magento Commerce) erweitert das Feld um zusätzliche Data-Transfer-Funktionen und Scheduled Import/Export. Diese sind an die kostenpflichtige Lizenz gebunden. Händler auf Open Source zahlen also entweder den Adobe-Preis oder investieren in eine Extension — oder eben in Entwicklung.
Warum hängt die Tool-Wahl vom Datenvolumen ab?
Weil jede Kategorie andere Durchsatzraten und Fehlertoleranz verlangt. Ein Beispiel aus der Praxis: Eine Agentur aus dem DACH-Raum berichtete 2025 von einem Kunden mit 120.000 SKUs, bei dem der native Import für einen vollständigen Katalog-Refresh rund 14 Stunden benötigte. Nach Umstieg auf eine indexoptimierte Extension sank die Laufzeit auf unter zwei Stunden — bei gleicher Datenbasis.
Der zweite Hebel ist die Frequenz. Tägliche Preis-Updates über die Konsole sind machbar. Stündliche Bestandsabgleiche mit ERP, PIM oder Marketplace-Anbindung überleben ohne batching und Queueing nicht.
- Produktdaten, Preise, Bestände: Inkonsistenzen zwischen PIM und Shop kosten Conversion.
- Bilder und Medien: Meist der unterschätzte Flaschenhals im Import.
- Custom Attributes: Ohne Mapping-Vorlagen wird jeder Import zum manuellen Projekt.
- Multi-Store: Ein Datenstamm, mehrere Länderversionen — nur mit sauberer Scope-Verwaltung.
Welche Optionen stehen 2026 zur Auswahl?
Vier Wege dominieren. Erstens der native Importer, wenn Katalog und Frequenz überschaubar bleiben. Zweitens die Adobe-Commerce-Data-Transfer-Funktionen für Lizenzkunden mit Bedarf an geplanten Jobs. Drittens spezialisierte Extensions wie die Firebear Improved Import & Export, der Magento 2 Import-Export-Suite oder vergleichbare Tools, die Mapping, Scheduling und große Dateien abdecken. Viertens Eigenentwicklung über die Magento-APIs, sinnvoll nur bei sehr spezifischen Anforderungen, die keine Extension erfüllt.
Der Blick auf Gesamtkosten lohnt. Eine Extension mit Lizenzkosten von ein- bis dreitausend Euro pro Jahr schlägt in der Regel ein halbes Entwicklerjahr, sobald individuelle Mapping-Logik und Fehlerbehandlung nötig sind. Umgekehrt zahlen Händler für Extensions, deren Features sie nie nutzen — weil ein Mapping zu PIM und ERP auch individuell oft schlanker ausfällt.
„Die Frage ist nicht, ob ein Tool importieren kann. Die Frage ist, ob es morgen um 3 Uhr noch korrekt importiert, wenn niemand hinschaut.“
Vor der Entscheidung stehen drei Prüfungen: Wie groß ist der Katalog realistisch in 24 Monaten? Welche Systeme liefern die Daten, und in welcher Struktur? Wer betreut den Import betrieblich — Agentur, interner Developer oder Fachabteilung? Wer diese Fragen ohne belastbare Zahlen beantwortet, wählt am Ende nach Bauchgefühl — und zahlt in der Migration.
Für Open-Source-Händler ohne Adobe-Lizenz bleibt die pragmatische Reihenfolge: native Tools testen, Engpass konkret messen, dann gezielt in eine Extension oder Custom-Logik investieren. Wer die Adobe-Commerce-Variante ohnehin lizenziert, sollte die integrierten Data-Transfer-Funktionen ernsthaft prüfen, bevor eine weitere Extension den Stack verbreitert.