Magento Open Source, Adobe Commerce sowie Magento 1 vs. 2
Magento Open Source ist kostenlose, selbst gehostete Ecommerce-Software auf PHP-Basis; Adobe Commerce (früher Magento Commerce) ist die kostenpflichtige Stufe mit zusätzlichen B2B-, Content-Staging- und Cloud-Hosting-Funktionen, betrieben auf von Adobe verwalteter Infrastruktur. Magento 1 erreichte bereits vor Jahren das Ende seines Lebenszyklus, und Shops, die es noch betreiben, migrieren meist allein aus diesem Grund, unabhängig von jeder Plattformvergleichsentscheidung.
Aufgrund dieser Bandbreite kann ein "Magento-Migrationsprojekt" bedeuten, einen kleinen Magento-1-Shop auf eine völlig andere Plattform zu verschieben, Magento 1 zu Magento 2 zu migrieren (immer noch Magento, aber ein Neuaufbau über eine Hauptversion hinweg), oder von Adobe Commerce Cloud zu etwas mit anderer Kostenstruktur zu wechseln. Wir grenzen zuerst ab, welcher Fall zutrifft, bevor wir irgendetwas schätzen.
Das EAV-Datenmodell und Multi-Store-Setups
Magento speichert Produktdaten über eine EAV-Struktur (Entity-Attribute-Value), die für stark konfigurierbare, attributreiche Kataloge leistungsfähig, aber strukturell anders ist als die einfacheren flachen Produkttabellen, die die meisten anderen Plattformen nutzen. Konfigurierbare Produkte (Magentos Version von Varianten), individuelle Attribut-Sets und attributgesteuerte facettierte Navigation benötigen alle ein explizites Mapping beim Wechsel zu einer Plattform ohne EAV-Äquivalent.
Magentos Multi-Store-/Multi-Website-Architektur, mit der mehrere Storefronts, Währungen oder Locales aus einer Installation betrieben werden, ist ein weiterer Punkt, der sorgfältig gemappt werden muss, da die meisten Plattformen Multi-Store unterschiedlich handhaben: separate Shops, ein einzelner Shop mit marktspezifischen Einstellungen, oder gar kein natives Äquivalent.
Extensions, individuelle Module und Magento-Entwickler
Magento-Shops verlassen sich für alles über die Kernfunktionalität hinaus häufig auf Marketplace-Extensions und individuell gebaute Module - etwa für Zahlungsmethoden, B2B-Preisregeln oder unternehmensspezifische Katalog-Logik. Da Magento eine entwicklerlastige Plattform ist, steckt ein nennenswerter Teil dessen, was ein Shop "tut", oft in individuellem PHP-Code statt in Admin-Einstellungen, und diese Logik muss identifiziert und entweder neu aufgebaut oder ersetzt werden, nicht nur exportiert.
Bei Themes gilt dasselbe Muster: Magento-Themes basieren auf dem eigenen Layout-XML-/Blocks-System, das anderswo keine direkte Entsprechung hat, weshalb ein Wechsel von Magento meist einen kompletten Storefront-Neuaufbau auf der neuen Plattform bedeutet.
SEO, URLs und wie wir eine Magento-Migration durchführen
Magento verwaltet URL-Rewrites intern und unterstützt recht flexible URL-Strukturen, aber die konkreten Details (Kategoriepfade, Produkt-URL-Suffixe, storeview-spezifische URLs) variieren je nach Konfiguration stark von Shop zu Shop. Genau diese Variabilität ist der Grund, warum wir mit einem Audit Ihrer tatsächlichen Live-URL-Muster beginnen, statt einen Magento-Standard vorauszusetzen.
Für eine Magento-Migration bauen wir die URL-/Weiterleitungskarte anhand dessen, was Ihr Shop heute wirklich tut, behandeln Multi-Store-URL-Varianten, wo relevant, und validieren, dass Metadaten und Canonical-Tags korrekt übernommen werden. Unser Service SEO- und Weiterleitungsmigration behandelt das ausführlicher.
Häufig gestellte Fragen
Ich nutze noch Magento 1. Können Sie das migrieren?
Ja, der Wechsel weg von Magento 1 ist eines der häufigeren Projekte, die wir sehen, meist getrieben vom Ende des Lebenszyklus statt von einer Plattformpräferenz. Wir behandeln es als vollständiges Replatforming, da Magento 1 und 2 unterschiedliche zugrunde liegende Architekturen haben.
Was passiert mit meinen individuellen Magento-Modulen?
Wir identifizieren, was jedes individuelle Modul tatsächlich tut - etwa eine Zahlungsintegration, eine Preisregel oder eine Katalogfunktion - und klären, ob die Zielplattform ein integriertes oder Extension-Äquivalent hat oder ob individuelle Entwicklung nötig ist.
Können Adobe Commerce B2B-Funktionen auf eine nicht-Enterprise-Plattform migrieren?
Das hängt von den konkreten Funktionen ab. Firmenkonten, Angebots-Workflows und gestaffelte B2B-Preise haben nicht auf jeder Plattform eine direkte Entsprechung, daher bewerten wir das im Rahmen der Bewertung von Fall zu Fall, statt eine Eins-zu-eins-Übereinstimmung vorauszusetzen.
Wie wirkt sich die EAV-Attributstruktur auf die Migrationsdauer aus?
Kataloge mit vielen individuellen Attributen und Attribut-Sets benötigen im Allgemeinen mehr Mapping-Zeit als einfache flache Kataloge, da für jedes Attribut explizit entschieden werden muss, wo es auf der Zielplattform landet.