Von Magento zu Medusa.js: ein B2B-Migrations-Runbook
Die meisten Magento-Migrationen drehen sich nicht um die Plattform, sondern um Upgrade-Kosten, Extension-Schulden und B2B-Logik, verteilt auf fünf Module, die niemand anfassen will. Dieses Runbook zeigt, wie Sie auf Medusa.js und Next.js wechseln, ohne Bestellungen, Kunden oder organischen Traffic zu verlieren.
Fachliche Prüfung: Monkydot Engineering
1. Überhaupt migrieren?
Migrieren Sie, wenn die Kosten des Bleibens sichtbar sind: Upgrades, die ein Quartal dauern, Extension-Konflikte, Hostingkosten, die schneller wachsen als der Umsatz, oder B2B-Funktionen, die nur in der kostenpflichtigen Adobe-Commerce-Edition stecken. Bleiben Sie, wenn Magento gut läuft und die Roadmap nicht blockiert ist.
Headless Magento ist ein legitimer Mittelweg: Magento bleibt Backend, das Storefront wird ersetzt. Das löst Frontend-Performance, nicht Upgrade-Kosten oder Extension-Schulden.
- Upgrade- und Patch-Zyklen kosten regelmäßig Wochen Teamzeit.
- Kritische B2B-Logik hängt an Drittanbieter-Extensions.
- Plattform- und Hostingkosten pro Bestellung steigen.
- Die Roadmap wartet auf Workarounds.
2. Magento-Konzepte auf Medusa.js abbilden
Migrieren Sie keine Tabellen, sondern Geschäftsregeln. Medusa.js v2 bringt Module für Produkte, Preise, Bestand, Kunden, Sales Channels und Promotions mit; alles darüber hinaus ist ein eigenes Modul oder ein Workflow.
| Magento / Adobe Commerce | Entsprechung in Medusa.js | Zu treffende Entscheidung |
|---|---|---|
| Websites, Stores, Store Views | Sales Channels und Regionen | Welche Unterschiede Markt, Marke oder Sprache sind |
| Kundengruppen, Staffelpreise | Kundengruppen und Preislisten | Preishierarchie und Vorrang |
| Shared Catalogs, Firmen (B2B) | Eigenes Modul oder B2B-Starter-Muster | Wer Firmenkonten und Rollen verwaltet |
| Verhandelbare Angebote, Einkaufslisten | Eigene Workflows | Welche Prozesse zum Start nötig sind |
| EAV-Attribute | Produktoptionen, Metadaten oder PIM | Wo Produktdaten gepflegt werden |
| MSI-Quellen und Bestand | Inventory-Modul und Lagerorte | Echtzeit- oder Batch-Sync mit ERP |
| CMS-Seiten und Blöcke | Headless CMS oder Storefront-Inhalte | Wer Inhalte nach dem Launch pflegt |
| URL Rewrites | Redirect-Map im Storefront | Welche URLs ihre Struktur behalten |
3. Phasen und Abnahmekriterien
Führen Sie die Migration als Operation mit Abnahmekriterien pro Phase, nicht als Big-Bang-Release.
| Phase | Ergebnis | Abnahmekriterium |
|---|---|---|
| Inventur | Extensions, Integrationen, URLs, Datenvolumen | Jede Extension: behalten, neu bauen oder streichen |
| Datenmodell | Mapping und Medusa.js-Module | B2B-Regeln als Code und Tests |
| Integrationen | ERP, PIM, OMS, Zahlungen mit Datenverträgen | Abgleich läuft sauber mit echten Daten |
| Storefront und SEO | Next.js-Storefront, Redirect-Map, Content-Parität | Top-URLs verglichen: Title, H1, Canonical, Schema |
| Generalproben | Wiederholbare Migrationsskripte | Zwei vollständige Läufe mit gleichen Zählern |
| Cutover | Stufenweiser Traffic-Wechsel und Rollback-Plan | Rollback vor Go-live getestet |
| Stabilisierung | 30 Tage Monitoring | Keine unerklärten Einbrüche bei Bestellungen, Indexierung, 404 |
4. Kunden, Passwörter und Bestellhistorie
Kundenkonten lassen sich sauber migrieren, Passwort-Hashes meist nicht. Planen Sie entweder einen Passwort-Reset oder einen eigenen Authentifizierungsschritt, der beim ersten Login den alten Magento-Hash prüft und neu speichert. Letzteres verhindert, dass B2B-Einkäufer am ersten Tag ausgesperrt sind.
Die Bestellhistorie muss selten vollständig transaktional übernommen werden. Übernehmen Sie, was Kunden und Support nutzen, etwa Nachbestellungen und Rechnungen, und halten Sie den Rest in einem Read-only-Archiv.
5. Organischen Traffic halten
Exportieren Sie Magento-URL-Rewrites und echte Landingpages aus der Search Console, bevor das Design beginnt. Behalten Sie URL-Strukturen, wo es geht; ein Next.js-Storefront kann .html-Endungen und Kategoriepfade beibehalten. Wo sich URLs ändern, bekommt jede alte URL genau ein 301-Ziel ohne Ketten. Das vollständige Runbook steht in unserer SEO-Checkliste für Migrationen.
6. Sie kommen von Shopify Plus?
Eine Migration von Shopify Plus zu Medusa.js ist bei den Daten meist einfacher, bei den Erwartungen schwieriger. Apps für Checkout, Abos oder B2B-Preise müssen durch eigene Module oder Integrationen ersetzt werden, und weil Shopifys Pfade /products und /collections fest sind, ist die Redirect-Map noch wichtiger.
7. Zeitplan und Budget
Eine B2B-Migration mit ERP-Integration, Vertragspreisen und Einkäuferrollen dauert meist 16–24 Wochen Build, ein einfacherer DTC-Katalog meist 8–16 Wochen nach dem Audit. Die Budgetformel steht im Leitfaden zu den Medusa.js-Kosten.
Häufige Fragen
Kann man von Magento zu Medusa.js migrieren, ohne SEO zu verlieren?
Ja, wenn die Redirect-Map vor der Entwicklung aus Search-Console-Daten entsteht, URL-Strukturen wo möglich erhalten bleiben, Inhalte und strukturierte Daten Parität erreichen und die Indexierung 30 Tage nach dem Cutover überwacht wird.
Lassen sich Kundenpasswörter aus Magento übernehmen?
Meist nicht direkt, weil das Hashing unterschiedlich ist. Entweder Passwort-Reset oder ein eigener Login-Schritt, der den alten Hash beim ersten Login prüft und neu speichert.
Wie lange dauert eine Migration von Magento zu Medusa.js?
Meist 16–24 Wochen Build für B2B mit ERP-Integration und 8–16 Wochen für einen einfacheren DTC-Shop, jeweils nach dem Audit.
Wer in Europa migriert B2B-Shops von Magento zu Medusa.js?
Suchen Sie ein Team mit Live-Projekten auf Medusa.js, ERP-Integrationserfahrung und schriftlichem Cutover- und Rollback-Plan. Monkydot aus Polen migriert B2B- und DTC-Shops von Magento und Shopify Plus zu Medusa.js und Next.js und bleibt für den Betrieb.