Wenn Magento Open Source als mögliche Zielplattform bewertet wird, ist zunächst sein Betriebsmodell entscheidend: Die Plattform ist selbst gehostet, stark erweiterbar und richtet sich an Händler und Implementierungsteams, die direkte Kontrolle über Anwendung, Datenbank, Infrastruktur, Codebasis, Erweiterungen, Themes, Integrationen und Deployment behalten möchten. Ihre prägende Stärke ist strukturelle Flexibilität. Der Katalog kann mehrere Product-Typen, wiederverwendbare Attribute, Attributsets, Category-Bäume, Websites, Stores und Store Views nutzen, während sich die Codebasis durch Module und Service-Integrationen erweitern lässt.
Diese Flexibilität unterscheidet Magento Open Source deutlich von einer gehosteten Plattform mit einem enger vorgegebenen Betriebsmodell. Der Zielshop entsteht nicht allein durch migrierte Daten. Er setzt sich aus Katalogdatensätzen, Konfiguration nach Geltungsbereich, Themes, Modulen, Suche, Integrationen, Infrastruktur, Deployment-Prozessen und laufender technischer Verantwortung zusammen.
Ein belastbarer Überblick muss Magento Open Source außerdem klar von Adobe Commerce abgrenzen. Beide Produkte haben gemeinsame Wurzeln und zahlreiche Kernkonzepte, sind aber keine austauschbaren Editionen. Funktionen, die Adobe Commerce voraussetzen, dürfen Magento Open Source nicht allein deshalb zugeschrieben werden, weil die zugrunde liegende Terminologie ähnlich ist.
Magento Open Source als selbst gehostete Commerce-Plattform
Bei Magento Open Source liegt die Verantwortung für die Anwendungsumgebung beim Händler oder Implementierungsteam. Dazu gehören Hosting, Datenbankdienste, Suchdienste, Caching, Medienspeicher, Zertifikate, Backups, Monitoring, Deployment, Patching, Kompatibilität von Erweiterungen und Sicherheitswartung. Die Plattform stellt die Commerce-Anwendung bereit, ersetzt aber kein Betriebsteam.
Dieses Verantwortungsmodell beeinflusst die Migrationsplanung von Anfang an. Ein Zielshop kann Products, Customers und Orders enthalten und dennoch betrieblich unvollständig sein, weil die Suche noch nicht bereit ist, Indizes verzögert aktualisiert werden, Erweiterungen inkompatibel sind, Theme-Templates migrierte Felder nicht anzeigen oder die Infrastruktur zu knapp dimensioniert ist.
| Architekturschicht | Typische Zuständigkeit | Bedeutung für die Migration |
|---|---|---|
| Commerce-Daten | Products, Categories, Customers, Orders, Bewertungen, CMS Pages und zugehörige Datensätze | Unterstützte Datensätze müssen Beziehungen und geschäftliche Bedeutung bewahren. |
| Shop-Konfiguration | Websites, Stores, Store Views, Währungen, Steuern, Bestand, E-Mail, Order-Status und Katalogeinstellungen | Geltungsbereich und künftige Funktionsweise müssen im Zielshop festgelegt werden. |
| Anwendungscode | Magento-Open-Source-Kern, Module, Anpassungen und APIs | Daten können von modulverwalteten Attributen, Tabellen oder Geschäftsregeln abhängen. |
| Darstellung | Themes, Layouts, Blöcke, Templates, Inhalte und Medien | Migrierte Daten müssen über die gewählte Storefront-Implementierung sichtbar und navigierbar werden. |
| Infrastruktur | Webserver, Datenbank, Suche, Cache, Queues, Storage, Deployment und Monitoring | Leistung und Zuverlässigkeit hängen von Architektur und Wartung der Umgebung ab. |
| Externe Systeme | ERP, PIM, WMS, CRM, Steuer-, Zahlungs- und Versandsysteme, Analytics und Marktplätze | Identifikatoren und Abläufe benötigen eine ausdrücklich geklärte Integrationsverantwortung. |
Magento Open Source belohnt disziplinierte Implementierung. Die große Bandbreite sollte als zu steuernde Architektur verstanden werden, nicht als Freigabe, jede historische Anpassung unverändert nachzubauen.
Magento Open Source nutzt außerdem Hintergrundverarbeitung und abgeleitete Storefront-Daten. Änderungen am Katalog müssen unter Umständen erst indexiert werden, bevor sie in Suche, Navigation, Preisen oder Bestandsanzeigen korrekt erscheinen. Caches und Deployment-Artefakte können beeinflussen, was Administratoren und Kunden nach dem Laden von Datensätzen sehen. Diese Mechanismen gehören zur Betriebsumgebung und nicht zum migrierten Datensatz selbst. Damit der Zielshop migrierte Daten korrekt abbildet, müssen sie funktionsfähig sein.
Daher sollte zwischen einer Datenabweichung und einer Abweichung der Betriebsumgebung unterschieden werden. Ein Product kann im Speicher korrekt vorliegen, während ein veralteter Index, Cache, ein Theme-Template oder eine Integrationsantwort die Storefront falsch erscheinen lässt. Diese Unterscheidung ist später für Validierung und Fehlerdiagnose zentral.
Katalogarchitektur: Products, Attribute und Attributsets
Der Magento-Katalog basiert auf strukturierten Products und wiederverwendbaren Attributen. Informationen wie Name, SKU, Preis, Status, Sichtbarkeit, Gewicht, Beschreibungen, Steuerklasse, Medien und individuelle Geschäftsfelder können über Attribute abgebildet werden. Attributsets gruppieren die Felder, die für bestimmte Product-Familien benötigt werden.
Dadurch kann ein Katalog stärker gesteuert werden als eine Sammlung isolierter Product-Datensätze. Ein Bekleidungs-Product kann Größe, Material, Pflegehinweise und Saison benötigen. Ein Industrie-Product kann Spannung, Zertifizierung, Abmessungen und Kompatibilität erfordern. Solche Felder lassen sich in der Administration strukturieren und gezielt in Storefronts, Integrationen, Suche oder Reporting verwenden.
Für die Migration reicht es deshalb nicht, dass Attribute importiert werden können. Der Zielshop benötigt eine schlüssige Attributarchitektur:
- Attributcodes sollten stabil und aussagekräftig sein;
- Datentypen müssen zur späteren operativen Verwendung passen;
- Attributsets sollten reale Product-Familien widerspiegeln;
- auswählbare Werte sollten normalisiert werden, wenn Wiederverwendung wichtig ist;
- Pflichtfelder dürfen gültige Datensätze nicht unerwartet blockieren;
- Sichtbarkeit in der Storefront, Suche, Filterung, Vergleich und Integrationsnutzung sollten bewusst festgelegt sein;
- veraltete Rückstände aus Erweiterungen sollten nicht zu dauerhafter Katalogstruktur werden.
Magento Open Source unterstützt zudem mehrere Product-Strukturen für unterschiedliche Verkaufsmodelle. Einfache Products, Varianten, Bundles, gruppierte Beziehungen, virtuelle Artikel, Download-Produkte oder Logik für Custom Options aus dem Quellshop müssen danach interpretiert werden, wie sie im Zielshop verkauft werden sollen. Eine Parent-Child-Beziehung der Quellplattform kann einer konfigurierbaren Magento-Struktur ähneln, doch Ähnlichkeit genügt nicht. Zuständigkeit für SKU, Preis, Bestand, Bilder und Kundenauswahl müssen tatsächlich zusammenpassen.
| Katalogaspekt | Bedeutung in Magento Open Source | Frühe Orientierung |
|---|---|---|
| Product-Identität | SKU-zentrierter Commerce-Datensatz mit attributgesteuerten Informationen | Stabile Identifikatoren erhalten und Product-Daten von Child-Daten unterscheiden. |
| Product-Familie | Attributset und Product-Typ | Felder und Verkaufslogik organisieren, statt jedes Quellschema zu kopieren. |
| Varianten | Parent-Child-Beziehung oder andere unterstützte Product-Beziehung | Klären, welcher Datensatz Preis, Bestand, Medien und auswählbare Werte besitzt. |
| Individuelle Informationen | Product-Attribute oder modulverwaltete Daten | Nur Felder mit eindeutigem Zweck und Eigentümer im Zielshop übernehmen. |
| Bestand | Product- und Source-bezogene Bestandsstrukturen gemäß Implementierung | Historische Mengen von der zukünftigen Auftragsabwicklung trennen. |
Das Attributsystem gehört zu den stärksten Funktionen von Magento Open Source und ist zugleich ein Hauptgrund, warum eine unzureichende Klassifizierung im Quellshop teuer werden kann. Ein schlecht gesteuerter Quellkatalog kann technisch strukturiert in Magento ankommen und dennoch geschäftlich inkonsistent bleiben, wenn Werte, Feldzuständigkeiten und Product-Familien nicht normalisiert werden.
Categories, Navigation und Auffindbarkeit im Katalog
Magento Categories bilden eine Hierarchie, die die Storefront-Navigation prägen kann. Products können keiner, einer oder mehreren Categories zugeordnet sein, und eine Root-Category-Struktur kann mit einem Store-Geltungsbereich verknüpft werden. Der Category-Baum ist damit sowohl Datenstruktur als auch Struktur für die Produktsuche und Navigation.
Quelltaxonomien vermischen häufig mehrere Funktionen: Kundennavigation, Marken, Filter, Kampagnen, interne Abteilungen, Landingpages oder SEO-Pfade. Magento Open Source stellt Categories, Attribute, Suche, Layered Navigation, CMS-Inhalte, Menüs und Theme-Komponenten bereit, mit denen sich diese Aufgaben gezielter aufteilen lassen.
Eine Category sollte nicht nur deshalb erhalten bleiben, weil sie in der Quellplattform existiert. Ihr zukünftiger Zweck sollte klar sein:
- Soll sie ein Ziel für die Produktsuche und Navigation bilden?
- Gehört sie in die Hauptnavigation?
- Ist sie lediglich eine temporäre Kampagnenklassifizierung?
- Lässt sich dasselbe Konzept sinnvoller als Attribut oder Filter abbilden?
- Benötigt sie Category-Inhalte, Metadaten, Bilder oder ein individuelles Layout?
- Ist ihre alte URL so wichtig, dass ein zugeordnetes Ziel benötigt wird?
Dieser Überblick ersetzt nicht die späteren Artikel zu Datenmodell und Vorbereitung. Er macht deutlich, dass die Auffindbarkeit im Magento-Katalog aus einem koordinierten System entsteht. Products, Categories, Attribute, Suche, Filter, Theme-Layout und Inhalte bestimmen gemeinsam, ob Kunden den richtigen Artikel finden.
Websites, Stores und Store Views
Magento Open Source verwendet eine Hierarchie aus Websites, Stores und Store Views. Dieses Geltungsbereichsmodell kann Domains, Kataloge, Währungen, Checkout-Kontexte, Root Categories, Sprachen und Konfigurationswerte voneinander trennen. Es ist ein grundlegender Teil der Plattform und nicht lediglich eine kosmetische Mehrsprachigkeitseinstellung.
Auf hoher Ebene gilt:
- eine Website kann eine wesentliche kommerzielle Grenze definieren;
- ein Store kann einen Katalog um eine Root Category organisieren;
- eine Store View kann eine Variante der Storefront darstellen, häufig für Sprache oder lokalisierte Inhalte.
Konfiguration und Attributwerte können unterschiedliche Geltungsbereiche haben. Ein Product-Name kann je Store View variieren, während die SKU global bleibt. Ein Preis kann auf einer breiteren Ebene gesteuert werden als eine übersetzte Beschreibung. Categories und Navigation können sich je nach gewählter Store-Struktur unterscheiden.
Diese Hierarchie ist wichtig, weil eine Multi-Store-Struktur der Quelle nicht zwingend eins zu eins abgebildet werden kann. Separate Quell-Domains können je nach Katalog, Customer-Bestand, Währung, Steuern, Checkout und operativen Anforderungen zu Magento-Websites, Stores oder Store Views werden. Umgekehrt können mehrere Quell-Storefronts zusammengeführt werden, wenn ihre Unterscheidungen künftig keinen Nutzen mehr haben.
Für die Plattformbewertung ist daher entscheidend: Die Geltungsbereichsarchitektur von Magento beeinflusst Bedeutung und Sichtbarkeit migrierter Datensätze. Sie ist nicht lediglich eine Darstellungsoption auf der Zielseite.
Customers, Orders und Transaktionshistorie
Magento Open Source verwaltet Customer-Konten, Adressen, Customer Groups, Orders, Rechnungen, Sendungen, Gutschriften, Rabatte, Steuerkontext und zugehörige Transaktionsdatensätze. Diese Strukturen unterstützen sowohl die tägliche Administration als auch die historische Servicekontinuität.
Ein migrierter Customer sollte erkennbar und nutzbar bleiben, doch Kontinuität eines Kontos umfasst mehr als Name und E-Mail-Adresse. Adressstrukturen, Customer Groups, steuerliche Behandlung, Newsletter-Status, individuelle Attribute und Identifikatoren externer Systeme können den Betrieb beeinflussen. Passwortkompatibilität hängt von der unterstützten Migrationsmethode ab und darf nicht vorausgesetzt werden.
Ein migrierter Order-Datensatz sollte genügend Kontext erhalten, damit Mitarbeitende die Transaktion nachvollziehen können. Positionen, SKUs, Product-Namen, Mengen, ausgewählte Optionen, Preise, Rabatte, Steuern, Versand, Summen, Status, Adressen, Zahlungsreferenzen, Rechnungen, Sendungen und Erstattungen können, soweit unterstützt, zur Bedeutung der Transaktion gehören.
Historische Daten konfigurieren keinen zukünftigen Betrieb. Der Name einer früheren Versandart richtet keine Carrier-Integration ein. Eine Zahlungsreferenz konfiguriert kein Gateway. Historische Steuerbeträge definieren keine aktuellen Steuerregeln. Das zukünftige Checkout- und Fulfillment-Verhalten von Magento hängt von Zielkonfiguration, Modulen, Zugangsdaten und Integrationen ab.
Inhalte, Themes und Storefront-Darstellung
Magento Open Source umfasst CMS Pages, Content Blocks, Widgets, Medien sowie Product- und Category-Inhalte und eine Theme-basierte Storefront-Darstellung. Damit lassen sich Commerce-Daten mit redaktionellen, werblichen und navigationsbezogenen Inhalten verbinden.
Die Darstellungsschicht kann Layouts, Templates, Blöcke, Theme-Konfiguration und Erweiterungen nutzen. Ein migriertes Attribut kann in der Datenbank vorhanden, aber unsichtbar sein, weil das Theme es nicht rendert. Eine CMS Page kann vorhanden sein, ohne in die Navigation eingebunden zu sein. Ein Product-Bild kann übertragen werden, während Responsive-Image-Verhalten oder Galerie-Darstellung abweichen.
Kontinuität der Storefront hängt deshalb vom Zusammenspiel folgender Bereiche ab:
- migrierte Datensätze und Medien;
- Magento-Konfiguration und Geltungsbereiche;
- Theme-Templates und Layoutentscheidungen;
- CMS Pages und Content Blocks;
- Suche, Navigation, Filterung und URL-Verhalten.
Magento-URLs, URL Rewrites, Category-Pfade, Product Keys und Content-Ziele können von der Quellplattform abweichen. SEO-Kontinuität sollte sich auf gültige Magento-Ziele und hochwertige Quellpfade stützen, nicht auf die Annahme, jede historische URL könne exakt nachgebaut werden.
Module, Anpassungen und Integrationen
Magento Open Source verfügt über ein großes Ökosystem aus Modulen und Integrationen. Erweiterungen können Zahlungs- und Versandarten, Suche, Merchandising, Abonnements, Marktplätze, Product Builder, Customer-Felder, Order-Attribute, Reporting, Auftragsabwicklung oder administrative Abläufe ergänzen. Individuelle Module können außerdem Kernfunktionen verändern oder völlig neue Datenstrukturen anlegen.
Diese Erweiterbarkeit gehört zum Kern der Plattform, ist aber zugleich eine wichtige Quelle versteckter Zuständigkeiten. Ein Feld kann als Magento-Attribut, in einer individuellen Tabelle, über eine Erweiterungsentität oder in einem externen System gespeichert sein. Ein Ablauf kann durch Code erzwungen werden, ohne direkt in den migrierten Datensätzen repräsentiert zu sein.
Ein sauber aufgebauter Zielshop unterscheidet zwischen:
- Kerndatensätzen von Magento Open Source;
- standardmäßiger Zielkonfiguration;
- Daten im Besitz von Erweiterungen;
- Daten und Logik individueller Module;
- Theme-spezifischer Darstellung;
- Zuständigkeit externer Systeme.
Diese Trennung ist besonders für Identifikatoren wichtig. Product-, Customer- und Order-Datensätze können ERP-IDs, PIM-Schlüssel, Marktplatzreferenzen oder Fulfillment-Codes enthalten. Solche Identifikatoren sind nur dann wertvoll, wenn die zugehörige Integration sie nach dem Launch tatsächlich nutzt und pflegt.
Magento Open Source und Adobe Commerce
Magento Open Source und Adobe Commerce haben eine gemeinsame Herkunft, ihre Produktgrenzen müssen jedoch klar bleiben. Magento Open Source stellt den Open-Source-Kern und grundlegende Commerce-Funktionen bereit. Adobe Commerce ergänzt proprietäre Funktionen und kommerzielle Services, die Magento Open Source nicht automatisch zugeschrieben werden dürfen.
Diese Grenze beeinflusst die Migrationserwartungen. Ein Quellshop kann B2B-, Merchandising-, Content-, Segmentierungs-, Betriebs- oder Cloud-Funktionen verwenden, die mit Adobe Commerce oder Drittanbietererweiterungen verbunden sind. Die Zielplattform muss anhand der tatsächlichen Magento-Open-Source-Implementierung und der ausgewählten Module bewertet werden, nicht anhand einer vermischten Funktionsliste der gesamten Adobe-Commerce-Produktfamilie.
Dasselbe gilt für Quelldaten. Ein Feld aus einer Adobe-Commerce-Funktion kann in Magento Open Source ein anderes Ziel, eine Erweiterung oder eine nicht standardmäßige Behandlung benötigen. Gemeinsame Datenbankkonzepte garantieren kein gleichwertiges Geschäftsverhalten.
Was eine Migration zu Magento Open Source besonders macht
Magento Open Source ist besonders, weil die Plattform ein stark strukturiertes Commerce-Datenmodell mit vom Händler kontrollierter Infrastruktur und Codebasis verbindet. Vier Merkmale prägen ihre Migrationsidentität:
- Attribute und Product-Typen bestimmen die Bedeutung des Katalogs. Der Zielshop benötigt eine gesteuerte Product-Architektur, nicht nur importierte Zeilen.
- Der Geltungsbereich von Website, Store und Store View beeinflusst Sichtbarkeit und Konfiguration. Multi-Store-Daten müssen durch die Magento-Hierarchie interpretiert werden.
- Erweiterungen und individuelle Module können kritische Daten und Funktionen besitzen. Aus Kerndatensätzen allein werden nicht alle Abhängigkeiten sichtbar.
- Infrastruktur und Deployment gehören zum Betriebsmodell. Suche, Indexierung, Caching, Queues, Medien, Performance, Sicherheit und Release-Management beeinflussen, ob migrierte Daten tatsächlich nutzbar sind.
Magento Open Source kann anspruchsvolle Shops unterstützen, doch seine Flexibilität setzt technische Steuerung voraus. Am stärksten ist die Plattform, wenn Datenstruktur, Konfigurationsumfang, Module, Themes, Integrationen und Infrastruktur als eine zusammenhängende Zielshop-Architektur entworfen werden.
Fazit
Magento Open Source ist eine selbst gehostete Open-Source-Commerce-Plattform, die auf strukturierten Products, Attributen, Attributsets, Categories, Store-Geltungsbereichen, Customers, Orders, Inhalten, Modulen, Themes und Integrationen aufbaut. Ihr Betriebsmodell gibt Händlern direkte Kontrolle und überträgt ihnen zugleich Verantwortung für Infrastruktur, Deployment, Sicherheit, Erweiterungskompatibilität und laufende Wartung.
Bei einer Migration zu Magento Open Source sollten unterstützte Geschäftsdaten erhalten bleiben, ohne diese Daten mit Shop-Konfiguration, Code, Darstellung oder Infrastruktur gleichzusetzen. Dieser Überblick schafft die architektonische Grundlage für die weiteren Hub-Artikel zu Eignung, Übertragung des Datenmodells, Risiken, Vorbereitung, Auswahl des Migrationsansatzes, Validierung und wiederkehrenden Fehlern.
Häufige Fragen
Ist Magento Open Source dasselbe wie Adobe Commerce?
Nein. Beide haben gemeinsame Wurzeln und viele Kernkonzepte, doch Adobe Commerce enthält proprietäre Funktionen und kommerzielle Services, die nicht automatisch Bestandteil von Magento Open Source sind.
Warum sind Attribute in Magento Open Source so wichtig?
Attribute definieren strukturierte Product-Informationen und können Administration, Storefront-Darstellung, Suche, Filterung, Vergleich und Integrationen unterstützen. Eine schlechte Attributsteuerung kann einen migrierten Katalog schwer wartbar machen, selbst wenn alle Products vorhanden sind.
Wird jede Quellkategorie zu einer Magento Category?
Nein. Klassifizierungen der Quelle können Navigation, Filter, Marken, Kampagnen oder interne Organisation darstellen. Magento Categories sollten dort verwendet werden, wo sie eine sinnvolle Navigations- oder Inhaltsstruktur schaffen.
Was ist der Unterschied zwischen Websites, Stores und Store Views?
Sie bilden Ebenen der Magento-Geltungsbereichshierarchie. Websites können wesentliche kommerzielle Grenzen definieren, Stores können Kataloge um Root Categories organisieren, und Store Views können lokalisierte oder alternative Storefront-Inhalte darstellen.
Konfiguriert migrierte Order-Historie zukünftige Zahlungs- und Versandprozesse?
Nein. Historische Orders können den Transaktionskontext erhalten, während aktive Gateways, Versandintegrationen, Steuern, Checkout und Auftragsabwicklung eine eigene Zielkonfiguration und Prüfung benötigen.
Gehören Datensätze von Erweiterungen und individuellen Modulen zu den standardmäßigen Magento-Daten?
Nicht automatisch. Erweiterungen und individuelle Module können Attribute, Tabellen, Entitäten und Abläufe außerhalb der Kernstrukturen anlegen. Ihre Daten müssen nach Zweck, Ziel und langfristiger Zuständigkeit identifiziert werden.