Der Produktdaten-Import ist für die meisten Magento-Händler ein manuell ausgelöster Prozess. Jemand zieht die CSV aus dem ERP, loggt sich im Backend ein, klickt auf „Import starten“, wartet. Bei zehn Produkten ist das eine Randnotiz. Bei 40.000 SKUs, die täglich Preis- und Bestandsänderungen aus einem PIM erhalten, ist es ein organisatorisches Risiko, das regelmäßig eskaliert: Der Mitarbeiter ist krank, der Import läuft nicht, die Preise im Shop sind 48 Stunden alt, und der Kundenservice erklärt an einem Montagmorgen, warum ein Artikel auf Lager war, der längst ausverkauft ist.
Adobe hat dieses Problem für Commerce-Kunden vor Jahren gelöst. Magento Open Source hat es bis heute nicht.
Warum Magento Open Source keinen nativen Scheduled Import hat, und was das kostet?
Die Antwort ist unspektakulär, aber konsequent. Adobe reserviert Automatisierungsfunktionen für die kommerzielle Edition. Der Scheduled Import gehört dazu, ebenso wie Scheduled Export, Staging und Content-Preview. Open Source erhält die Import-Engine, aber keine Zeitsteuerung: Der Admin-Bereich kennt nur „jetzt importieren“.
Für Händler, die auf Open Source setzen, bedeutet das einen indirekten Kostentreiber. Der manuelle Import ist nicht kostenlos, er ist nur unsichtbar in der Buchhaltung. Rechnen Sie konservativ: Ein Mitarbeiter benötigt für einen vollständigen Produktimport mit Validierung, Log-Prüfung und Fehlerkorrektur 20 bis 45 Minuten. Bei täglicher Frequenz sind das jährlich zwischen 120 und 270 Arbeitsstunden, je nach Kataloggröße.
Dazu kommt die logische Schwachstelle manueller Prozesse: Sie laufen nicht, wenn niemand da ist. Wochenenden, Feiertage, Urlaubsvertretungen. Ein Shop, der Preisänderungen aus dem Lieferanten-EDI tagesaktuell abbilden will, kann das mit manuellem Import strukturell nicht leisten.
Wie funktioniert ein automatisierter Produktimport in Magento 2 technisch?
Magento liefert die Bausteine bereits mit. Die Import-Logik läuft über die Kommandozeile, nicht über das Admin-UI. Der relevante Befehl lautet:
php bin/magento import:import, entity-type=products, import-file=/pfad/zum/import.csv
Dieser CLI-Aufruf ist die Grundlage jeder Automatisierung in Open Source. Er nimmt eine CSV-Datei entgegen, validiert sie gegen die Attributstruktur und schreibt die Datensätze in die jeweiligen EAV-Tabellen. Entscheidend: Der Befehl ist idempotent, was bedeutet, dass derselbe Datensatz mit gleicher SKU aktualisiert und nicht dupliziert wird. Das macht wiederholte Läufe unkritisch.
Die Zeitsteuerung übernimmt Cron. In der crontab des Server-Users steht dann etwa:
0 4 * * * /usr/bin/php /var/www/magento/bin/magento import:import, entity-type=products, import-file=/var/import/products.csv >> /var/log/magento-import.log 2>&1
Das ist die einfachste Variante eines Scheduled Imports: täglich um 04:00 Uhr, Log-Ausgabe in eine eigene Datei, Fehler landen im selben Log. Ohne Cron wäre jeder Import ein manueller Aufruf, mit Cron wird er ein Hintergrunddienst.
Der kritische Teil: Woher kommt die Datei?
Der Cron-Job importiert nur, was bereits auf dem Server liegt. In der Praxis braucht es eine vorgeschaltete Kette. Typische Konstellation für DACH-Händler:
- Ein ERP (Sage, Scopevisio, Microsoft Dynamics) oder PIM exportiert nächtlich eine CSV auf einen SFTP-Server.
- Ein zweiter Cron-Job zieht die Datei per
rsyncoderscpin das Magento-Import-Verzeichnis. - Der Import-Job läuft erst, wenn die Datei vollständig vorhanden ist, sonst importiert Magento eine halb geschriebene CSV und bricht mit Validierungsfehlern ab.
Genau an dieser Stelle scheitern viele selbstgebaute Setups. Wer den Dateitransfer und den Import in einen einzigen Befehl packt, riskiert Teilimporte. Sauberer ist eine Sequenz mit Größenprüfung oder einer Marker-Datei, die das ERP erst nach vollständigem Schreiben ablegt.
Welche Frequenz ist sinnvoll, täglich, wöchentlich oder stündlich?
Die Frequenz folgt der Datenquelle, nicht dem Wunschdenken. Drei Muster haben sich etabliert:
Täglich (nachts, 03:00–05:00 Uhr) ist der Standard für Preise, Bestände und Produktstammdaten aus einem ERP. Der Import läuft in einem Lastfenster, in dem weder Kunden noch Redakteure zugreifen. Bei Katalogen über 50.000 SKUs sollte der Indexer im Anschluss separat angestoßen werden, sonst arbeitet der Shop mit veralteten Suchindizes.
Stündlich oder halbstündlich ist nur bei Bestandsdaten mit hoher Volatilität sinnvoll, etwa bei Dropshipping-Modellen, bei denen der Lieferant Lagerbestände im Minutentakt meldet. Vorsicht: Jeder Import triggert Reindex- und Cache-Prozesse. Ohne vollständigen Redis-Cache und sauber konfigurierten Indexer im Update-on-Schedule-Modus bringt das den Shop unter Last in Verlegenheit.
Wöchentlich bleibt für Sortimentserweiterungen, neue Kategorien und redaktionelle Inhalte richtig. Hier ist die Änderungsrate niedrig, und ein manueller Review der importierten Daten vor dem Go-Live ist sinnvoll. Vollautomatik wäre an dieser Stelle sogar kontraproduktiv, weil fehlerhafte Produktbeschreibungen aus dem PIM direkt im Shop landen.
Die richtige Frequenz ist nicht die, die technisch möglich ist, sondern die, bei der eine Fehlermeldung um 04:00 Uhr morgens noch am selben Tag auffällt.
Welche Dritt-Tools ersetzen den fehlenden nativen Scheduled Import?
Wer nicht selbst Cron-Jobs pflegen will, greift zu Erweiterungen. Der Markt für Magento-Open-Source-Import-Tools ist reif, und die Auswahl hängt stark von der Datenquelle ab.
Magento 2 Import Export von Firebear ist die am weitesten verbreitete Lösung im DACH-Raum. Die Erweiterung bringt einen Scheduler im Admin-UI, unterstützt CSV, XML, JSON und Google Sheets als Quellen, verarbeitet XSLT-Transformationen und protokolliert Läufe im Backend. Der Vorteil: Kein Serverzugriff für die Konfiguration, kein Cron-Skript zu pflegen. Der Nachteil: Lizenzkosten und eine weitere Extension im Update-Zyklus.
Data Transporter von Ubertheme verfolgt denselben Ansatz mit etwas schlankerem Funktionsumfang und günstigerer Lizenzierung. Für Händler ohne komplexe Mapping-Anforderungen oft ausreichend.
ERP-Konnektoren wie der von Xtento oder dedizierte Middleware-Lösungen (Cobby, SyncSpider, DataHub) gehen einen Schritt weiter: Sie synchronisieren nicht per Datei, sondern per API in Echtzeit oder quasi-Echtzeit. Das ist technisch überlegen, aber deutlich teurer und bringt eine Abhängigkeit vom Middleware-Anbieter mit sich.
Für die Mehrheit der DACH-Magento-Händler mit 5.000 bis 100.000 SKUs bleibt die Kombination aus nativem CLI-Import plus Cron plus einem Cron-Skript zur Dateibeschaffung die kosteneffizienteste Lösung. Sie kostet einen Entwicklertag bei der Einrichtung und danach fast nichts.
Was 2026 anders wird
Zwei Entwicklungen verschärfen das Thema. Erstens: Adobe verschiebt mit jeder Commerce-Release mehr Funktionalität in den kommerziellen Kern. Open-Source-Händler werden dauerhaft auf Community-Lösungen oder Eigenbau angewiesen bleiben. Zweitens: Die Anforderungen an Datenaktualität steigen. Lieferanten-EDI mit stündlichen Bestandsmeldungen, dynamische Preisgestaltung, Marketplace-Synchronisation, alles setzt automatisierte Importe voraus.
Wer heute noch manuell importiert, wird 2026 nicht konkurrenzfähig sein, wenn der eigene Sortimentsumfang wächst. Die Einrichtung eines Scheduled Imports ist keine strategische Entscheidung mehr, sondern eine Basisfähigkeit. Sie ist an einem Nachmittag erledigt und verhindert die Fehlerklasse, die teuer wird, sobald der Shop skaliert: veraltete Daten im Frontend.
Der pragmatische Startpunkt für Open-Source-Händler: ein Cron-Job, ein Logfile, eine Test-CSV mit zehn Produkten. Läuft das stabil über eine Woche, ist die Erweiterung auf den vollen Katalog ein Konfigurationsdetail.