Migration von Magento 1 auf Magento 2: Datenübernahme und Fallstricke

1. Warum Migration 2026 noch ein reales Projekt ist

Magento 1 erreichte im Juni 2020 das offizielle End-of-Life, seitdem gibt es keine Sicherheitspatches mehr vom Hersteller. Trotzdem laufen im Jahr 2026 immer noch Shops auf dieser Plattform, meist weil eine Magento 1 Migration als zu aufwendig oder zu riskant für das Tagesgeschäft eingeschätzt wurde. Das Risiko ist inzwischen jedoch deutlich größer als noch vor einigen Jahren: bekannte, öffentlich dokumentierte Sicherheitslücken werden nie wieder geschlossen, PCI-DSS-Compliance für Zahlungsabwicklung ist auf einer unterstützten Plattform kaum noch nachweisbar, und die verfügbare Anzahl an Entwicklern mit aktuellem Magento-1-Wissen sinkt kontinuierlich.

Dieser Artikel behandelt eine praxisnahe Magento-Migration von einem bestehenden Magento-1-Shop auf Magento 2.4.8, mit Fokus auf die technischen Fallstricke, die in Migrationsprojekten immer wieder für Verzögerungen sorgen: das Data Migration Tool und seine Grenzen, EAV-Mapping-Probleme bei individuellen Produktattributen, der zwingende Theme-Neubau statt einer 1:1-Übernahme, URL-Struktur und SEO-Redirects, sowie die technisch nicht triviale Umstellung der Passwort-Hashes bestehender Kundenkonten.

Wichtig vorab: Eine Magento 1 Migration ist kein reines Datenbank-Kopierprojekt, sondern in weiten Teilen ein Neubau. Wer das von Anfang an einplant, statt eine schnelle, oberflächliche Übernahme zu erwarten, vermeidet die größten Enttäuschungen im Projektverlauf.

2. Migrationsstrategie wählen: Big Bang vs. schrittweise

Ein Big-Bang-Cutover migriert den kompletten Shop an einem festen Stichtag: Daten werden final synchronisiert, der alte Shop wird abgeschaltet, der neue geht live. Dieser Ansatz eignet sich für kleinere bis mittlere Shops mit überschaubarem Auftragsvolumen, bei denen ein Wartungsfenster von einigen Stunden akzeptabel ist. Der Vorteil liegt in der Einfachheit: es gibt keinen Parallelbetrieb, keine Synchronisationslogik zwischen zwei Systemen, und das Projekt hat einen klaren Abschluss.

Für Shops mit hohem täglichem Auftragsvolumen oder mehreren angebundenen Drittsystemen wie ERP oder PIM ist eine schrittweise Migration mit temporärem Parallelbetrieb oft die realistischere Wahl. Dabei laufen beide Systeme für einen begrenzten Zeitraum nebeneinander, während einzelne Funktionsbereiche, etwa zunächst nur der Produktkatalog, dann später Checkout und Kundenkonten, nacheinander auf Magento 2 umgestellt werden. Diese Strategie erhöht die Projektkomplexität erheblich, reduziert aber das Risiko eines kompletten Shop-Ausfalls während der kritischen Umstellungsphase. Die Entscheidung zwischen beiden Ansätzen sollte früh im Projekt getroffen werden, da sie die gesamte technische Vorbereitung der Magento-Migration beeinflusst.

3. Data Migration Tool: Grundlagen und mapping.xml

Adobe stellt für die Magento 1 Migration ein offizielles Data Migration Tool bereit, das als separates Composer-Paket parallel zur Magento-2-Installation läuft und in mehreren Phasen arbeitet: zunächst die Einstellungsmigration (Konfigurationswerte), danach die Datenmigration (Stammdaten wie Produkte, Kategorien, Kunden) und schließlich die Delta-Migration, die während des laufenden Parallelbetriebs kontinuierlich neue Änderungen aus Magento 1 nachzieht, bis zum finalen Cutover.

Zentral für die korrekte Funktion des Tools sind die mapping.xml-Dateien, die für jede Magento-Edition und -Version mitgeliefert werden und definieren, welche Magento-1-Tabellen und -Spalten auf welche Magento-2-Entitäten abgebildet werden. Bei individuellen Anpassungen im ursprünglichen Magento-1-Shop, etwa zusätzlichen Spalten in Kerntabellen oder umbenannten Attributen, reicht die mitgelieferte mapping.xml nicht aus und muss um eigene Mapping-Regeln ergänzt werden, bevor die Datenmigrationsphase gestartet wird.

# Install the Data Migration Tool matching your Magento 2 edition and version
bin/composer require magento/data-migration-tool:2.4.8

# Phase 1: migrate configuration settings first
bin/magento migrate:settings --reset vendor/magento/data-migration-tool/etc/opensource-to-opensource/2.4.8/config.xml

# Phase 2: migrate master data (products, categories, customers, orders)
bin/magento migrate:data --reset vendor/magento/data-migration-tool/etc/opensource-to-opensource/2.4.8/config.xml

# Phase 3: run repeatedly during parallel operation to pull incremental changes
bin/magento migrate:delta vendor/magento/data-migration-tool/etc/opensource-to-opensource/2.4.8/config.xml

4. Custom-Attribute und EAV-Mapping-Fallstricke

Individuelle Produktattribute sind der Bereich, in dem eine Magento 1 Migration am häufigsten ins Stocken gerät. Magento 1 und Magento 2 nutzen zwar beide ein EAV-Modell (Entity-Attribute-Value), aber die interne Struktur von Attribut-Sets, Attributgruppen und Attribut-Typen unterscheidet sich in Details, die bei einer automatisierten Migration nicht immer korrekt aufgelöst werden. Ein häufiges Problem: ein in Magento 1 als Textfeld angelegtes Attribut, das eigentlich eine Auswahlliste sein sollte, wird 1:1 übernommen, statt in Magento 2 sauber als select-Attribut mit definierten Optionen neu modelliert zu werden.

Ein zweites, subtileres Problem sind doppelte attribute_code-Kollisionen: Magento 2 reserviert einige Attribut-Codes für interne Zwecke, die in Magento 1 möglicherweise für eigene, projektspezifische Attribute verwendet wurden. Das Migration-Tool bricht in solchen Fällen entweder mit einem Fehler ab oder überschreibt stillschweigend die falschen Werte, wenn das Mapping nicht vorher explizit bereinigt wurde. Der empfohlene Weg ist eine vollständige Attribut-Inventur des Magento-1-Shops vor Migrationsbeginn, mit einer bewussten Entscheidung pro Attribut: 1:1 übernehmen, umbenennen, oder als komplett neues Magento-2-Attribut mit sauberem Attribut-Set neu anlegen.

<!-- Custom mapping.xml override for an attribute renamed to avoid a Magento 2 core collision -->
<?xml version="1.0" encoding="UTF-8"?>
<config>
    <step title="Custom Attribute Mapping">
        <map>
            <field_rules>
                <ignore>
                    <!-- Attribute code collided with a Magento 2 reserved name -->
                    <field name="status"/>
                </ignore>
                <rename>
                    <!-- Renamed to avoid the collision, remapped explicitly here -->
                    <field name="status" to="legacy_order_status"/>
                </rename>
            </field_rules>
        </map>
    </step>
</config>

5. Theme und Extensions: warum ein Neubau nötig ist

Magento-1-Templates basieren auf phtml-Dateien mit Zend_Db-Direktzugriffen, Blocks nach dem alten EAV-Model-Muster und einem völlig anderen Layout-XML-Dialekt. Diese Struktur ist mit dem Magento-2-Modulsystem, Service Contracts und dem Hyvä-Theme-Ansatz mit Tailwind CSS und Alpine.js technisch inkompatibel, eine automatisierte Konvertierung von Magento-1-Templates nach Magento 2 existiert nicht und würde selbst bei Verfügbarkeit fragilen, kaum wartbaren Code erzeugen. Der einzig sinnvolle Weg ist ein bewusster Theme-Neubau, der das Design des alten Shops als visuelle Referenz nutzt, aber technisch komplett neu auf Basis der Magento-2-Blockstruktur und, sofern gewünscht, Hyvä entsteht.

Bei Erweiterungen gilt dasselbe Prinzip: Eine Magento-1-Extension, etwa ein individuelles Versandmodul oder eine Payment-Integration, kann nicht einfach kopiert werden, weil sich Modul-Registrierung, Dependency Injection und Service-Contract-Muster fundamental geändert haben. Für jede Magento-1-Erweiterung muss geprüft werden, ob es bereits eine offizielle Magento-2-Version des Anbieters gibt, ob eine funktional vergleichbare Magento-2-Alternative am Markt existiert, oder ob die Logik als komplett neues Magento-2-Modul mit modernem PHP 8.4 und Service Contracts nachgebaut werden muss.

6. URL-Struktur und SEO-Redirects

Magento 1 und Magento 2 unterscheiden sich in ihren URL-Key-Konventionen, oft schon allein durch unterschiedliche Standardsuffixe und Kategoriepfad-Strukturen. Ohne sorgfältige Planung verliert der migrierte Shop einen erheblichen Teil seiner organisch aufgebauten Suchmaschinen-Rankings, weil Suchmaschinen die alten, indexierten URLs plötzlich als 404 vorfinden. Der zentrale Baustein zur Vermeidung dieses Risikos ist eine vollständige 301-Redirect-Tabelle, die jede alte Magento-1-URL explizit auf die neue Magento-2-Route abbildet, nicht nur pauschal auf die Startseite.

Zusätzlich zur reinen URL-Weiterleitung müssen Canonical-Tags neu gesetzt und die XML-Sitemap komplett neu aufgebaut werden, da die alte Sitemap-Struktur auf den nicht mehr existierenden Magento-1-URLs basiert. Ein oft unterschätzter Aufwand ist die Erstellung der Redirect-Mapping-Tabelle selbst: Bei einem Katalog mit mehreren tausend Produkten und Kategorien reicht manuelle Pflege nicht aus, hier empfiehlt sich ein automatisiertes Skript, das die alte und neue URL-Struktur programmatisch abgleicht und die Redirect-Regeln generiert, bevor sie in der finalen url_rewrite-Tabelle von Magento 2 landen.

7. Kundendaten und Passwort-Hashes

Magento 1 speichert Kundenpasswörter mit einem MD5-basierten Hash-Verfahren, während Magento 2 über \Magento\Framework\Encryption\Encryptor auf bcrypt-basiertes Hashing setzt, ein fundamentaler und aus Sicherheitssicht sehr begrüßenswerter Unterschied. Das Data Migration Tool übernimmt die alten MD5-Hashes zunächst unverändert in die neue Datenbank, markiert sie aber intern als Legacy-Format. Beim ersten erfolgreichen Login eines migrierten Kunden erkennt Magento 2 automatisch das alte Hash-Format, validiert das eingegebene Passwort noch einmal gegen den MD5-Hash, und speichert bei Erfolg transparent einen neuen bcrypt-Hash, ohne dass der Kunde etwas davon bemerkt oder sein Passwort erneut eingeben muss.

Wichtig für die Projektplanung: Kunden, die sich nach der Migration nie wieder einloggen, behalten dauerhaft einen MD5-Hash, was aus heutiger Sicherheitssicht ein Restrisiko darstellt. Für besonders sicherheitskritische Projekte empfiehlt sich ergänzend eine einmalige, kommunizierte Passwort-Reset-Kampagne für alle migrierten Konten, die über einen bestimmten Zeitraum, etwa sechs Monate nach dem Cutover, nicht eingeloggt haben, um verbliebene MD5-Hashes systematisch zu eliminieren.

declare(strict_types=1);

namespace Vendor\MigrationTools\Model;

use Magento\Customer\Api\Data\CustomerInterface;
use Psr\Log\LoggerInterface;

/**
 * Reports customers whose password hash is still in the legacy MD5-based
 * format after a Magento 1 to Magento 2 migration, so they can be targeted
 * for a proactive password reset campaign.
 */
final class LegacyHashReporter
{
    private const string LEGACY_HASH_PREFIX_LENGTH = 32; // MD5 hex digest length

    /**
     * @param LoggerInterface $logger Logs identified legacy accounts for the reset campaign
     */
    public function __construct(
        private readonly LoggerInterface $logger,
    ) {
    }

    /**
     * Flags whether a stored password hash still looks like a legacy MD5-based hash.
     *
     * @param string $passwordHash Raw password_hash value from customer_entity
     * @return bool True if the hash format still matches the legacy Magento 1 pattern
     */
    public function isLegacyHash(string $passwordHash): bool
    {
        // Magento 2 bcrypt hashes contain a version prefix and a salt separated by ':'.
        // A legacy migrated hash typically has no such separator structure.
        return !str_contains($passwordHash, ':') && strlen($passwordHash) === self::LEGACY_HASH_PREFIX_LENGTH;
    }
}

8. Testing und Go-Live-Cutover-Plan

Vor jedem finalen Cutover sollten mindestens zwei bis drei vollständige Dry-Run-Migrationen gegen eine Kopie der Produktivdatenbank durchgeführt werden, um Laufzeit, Fehlerquote und Datenkonsistenz realistisch einzuschätzen. Nach jedem Dry-Run gehört eine Datenabgleich-Checkliste zum festen Prozess: stimmt die Anzahl der migrierten Bestellungen exakt mit der Quelldatenbank überein, stimmt die Kundenanzahl, stimmt die Produktanzahl inklusive aller Varianten bei konfigurierbaren Produkten, und wurden alle Attributwerte korrekt übernommen.

#!/usr/bin/env bash
# Quick row-count reconciliation after a Data Migration Tool dry run.
# Run against both the Magento 1 source and the fresh Magento 2 target
# database to catch obvious data-loss before scheduling the final cutover.
set -euo pipefail

SOURCE_DB="magento1_prod_copy"
TARGET_DB="magento2_migration"

echo "Orders:"
bin/mysql -e "SELECT COUNT(*) FROM ${SOURCE_DB}.sales_flat_order" -N
bin/mysql -e "SELECT COUNT(*) FROM ${TARGET_DB}.sales_order" -N

echo "Customers:"
bin/mysql -e "SELECT COUNT(*) FROM ${SOURCE_DB}.customer_entity" -N
bin/mysql -e "SELECT COUNT(*) FROM ${TARGET_DB}.customer_entity" -N

echo "Products (including all configurable variants):"
bin/mysql -e "SELECT COUNT(*) FROM ${SOURCE_DB}.catalog_product_entity" -N
bin/mysql -e "SELECT COUNT(*) FROM ${TARGET_DB}.catalog_product_entity" -N

Der eigentliche Cutover-Tag sollte ein festes, kommuniziertes Wartungsfenster mit realistischem Zeitpuffer vorsehen, in der Regel außerhalb der Hauptgeschäftszeiten. Ein dokumentierter Rollback-Plan für den Fall, dass die finale Delta-Migration unerwartete Fehler produziert, gehört zwingend zur Vorbereitung: im Zweifel muss der alte Magento-1-Shop kurzfristig reaktivierbar sein, bis das Problem behoben und ein neuer Cutover-Termin angesetzt ist. Ein Cutover ohne getesteten Rollback-Plan ist eines der größten vermeidbaren Risiken einer Magento-Migration.

9. Vergleich: typische Fehler vs. richtiges Vorgehen

Die folgende Übersicht fasst die häufigsten Fehler bei einer Magento 1 Migration zusammen und stellt ihnen das etablierte, richtige Vorgehen gegenüber.

Der gemeinsame Nenner aller vermeidbaren Fehler: Eine Magento 1 Migration scheitert selten am Data Migration Tool selbst, sondern an unzureichender Vorbereitung und fehlenden Tests in den Bereichen, die das Tool nicht automatisch abdeckt.

Auch nach einem erfolgreichen Cutover ist das Projekt nicht sofort beendet. In den ersten zwei bis vier Wochen nach dem Livegang sollte ein engmaschiges Monitoring auf Bestellabbrüche, ungewöhnliche 404-Raten aus Suchmaschinen-Crawlern und Support-Anfragen zu fehlenden Kundenkonten laufen. Diese Phase deckt zuverlässig genau die Fehler auf, die in Dry-Runs mit synthetischen Testdaten unentdeckt bleiben, etwa seltene Kombinationen aus alten Rabattcodes und neuen Steuerregeln oder vereinzelte Produkte mit inkonsistenten EAV-Werten aus jahrelang gewachsenen Altdaten. Ein fest eingeplantes Zeitfenster für diese Nachbeobachtung, inklusive eines ansprechbaren Entwicklerteams, gehört ebenso zum Migrationsplan wie der eigentliche Cutover-Termin selbst.

10. Zusammenfassung

Eine erfolgreiche Magento 1 Migration auf Magento 2.4.8 verlangt weit mehr als das offizielle Data Migration Tool zu installieren und laufen zu lassen. Die Wahl zwischen Big-Bang- und schrittweiser Migration bestimmt die gesamte Projektstruktur. Custom-Attribute erfordern eine vollständige Inventur vor der Datenmigrationsphase, um EAV-Mapping-Kollisionen zu vermeiden. Theme und Extensions müssen bewusst neu gebaut werden, eine automatisierte 1:1-Konvertierung existiert nicht und wäre auch nicht wünschenswert.

URL-Redirects und ein neu aufgebautes Sitemap-Konzept schützen bestehende SEO-Rankings, während die transparente Passwort-Hash-Umstellung von MD5 auf bcrypt zwar automatisch beim ersten Login greift, aber für inaktive Konten proaktiv nachverfolgt werden sollte. Mehrere getestete Dry-Run-Migrationen mit vollständigem Datenabgleich und ein dokumentierter Rollback-Plan reduzieren das Risiko des finalen Cutovers auf ein kalkulierbares Maß, statt eine Magento-Migration als einmaligen, unumkehrbaren Sprung ins kalte Wasser zu behandeln.

11. FAQ: Migration von Magento 1 auf Magento 2