Von Magento oder Adobe Commerce zu einem eigenen Solidus Shop wechseln

Was Magento heute ist, und wer herauswächst

Magento ist ernstzunehmende Shopsoftware, und das will ich klar sagen, bevor ich den Rest des Artikels damit verbringe zu erklären, warum ein Shop sie verlassen könnte. Sie bewältigt sehr große Kataloge, komplexe Regeln im Geschäft zwischen Unternehmen, mehrere Storefronts und Währungen aus einer Installation und Produkte mit vielen Attributen, an denen andere Plattformen scheitern. Wenn dein Shop das alles wirklich braucht und du das Team und das Budget hast, um Magento gut zu betreiben, verdient sie ihren Platz, und du solltest vermutlich bleiben.

Das Unternehmen, für das ich schreibe, ist das andere: der Shop, der für weit mehr Plattform und weit mehr Spezialistenzeit zahlt, als seine Bedürfnisse rechtfertigen. Meist ist das ein mittelgroßer Händler oder Fachhändler, der vor Jahren bei Magento gelandet ist, oft auf Rat einer Agentur, und nun feststellt, dass die Lizenz, das Hosting und der Tagessatz der wenigen Leute, die das System kennen, eine Rechnung ergeben, die in keinem Verhältnis zu dem steht, was der Shop tatsächlich tut. Der Checkout funktioniert. Der Katalog funktioniert. Aber jede Änderung ist ein Projekt, jedes Upgrade ist ein Projekt, und die Person, die die Rechnung unterschreibt, fragt sich allmählich, wofür das alles gut ist.

Dieser Artikel ist der ehrliche Leitfaden zum Umzug von Magento Open Source oder Adobe Commerce auf einen eigenen Shop auf Basis von Solidus, dem quelloffenen Shop Framework für Ruby on Rails. Ich baue den neuen Shop und führe den Umzug durch. Dir gehört das Ergebnis. Ich werde konkret, wie Magentos Export und die API wirklich arbeiten, was sauber herausgegeben wird und was zurückgehalten wird und wo die harten Teile liegen. Für das tiefe Detail, wie jede Art von Daten umzieht, verlinke ich auf die Beiträge, die das sauber behandeln, statt es hier zu wiederholen. Der Einstieg, falls du ihn noch nicht gelesen hast, ist der Überblick: was sich überträgt und was nicht.

Zwei Editionen auf einer Codebasis

Die erste Klarheit betrifft die Frage, auf welchem Magento du bist, denn die beiden Editionen sind dieselbe Software mit sehr unterschiedlichen kommerziellen Bedingungen.

Magento Open Source ist kostenlos zu lizenzieren. Der Code liegt auf GitHub unter der Open Software License 3.0, und du kannst ihn herunterladen, betreiben und verändern, ohne Adobe etwas zu zahlen.¹ Deine Kosten sind Hosting, Entwicklung und die Erweiterungen, die du kaufst. Diese Edition betreiben viele kleinere Shops, manchmal ohne zu wissen, dass es eine zweite gibt.

Adobe Commerce ist die bezahlte Edition. Sie ist auf demselben Kern gebaut und ergänzt Funktionen für größere Betriebe: native Funktionen für das Geschäft zwischen Unternehmen, Content Staging, Kundensegmentierung, dedizierten Support und eine verwaltete Cloud Option. Adobe veröffentlicht keinen Listenpreis dafür. Die kommerzielle Lizenz wird in einem Bestelldokument mit Adobe vereinbart, und der Lizenzhinweis auf GitHub sagt ausdrücklich, dass kommerzielle Bedingungen, sobald du dafür Gebühren zahlst, die quelloffene Lizenz für jede Datei ablösen.¹ In der Praxis wird die Gebühr von Adobe angeboten und an die Größe deines Unternehmens angepasst, statt aus einer öffentlichen Preisliste zu stammen,² und genau das macht sie so schwer vergleichbar und so leicht weiterzuzahlen. Für viele Shops ist die Adobe Commerce Lizenz der größte einzelne Grund, warum die Zahlen am Jahresanfang keinen Sinn mehr ergeben.

Wenn du auf Adobe Commerce bist und nicht in Ruhe sagen kannst, was dir die Lizenz bringt, das du nicht mit der kostenlosen Edition plus einem Entwickler bekämst, dann ist genau diese Lücke das Erste, was du prüfen solltest.

Was dir wirklich gehört, und was dich hält

Hier die gute Nachricht, und sie ist wirklich gut: dir gehören deine Daten, auf beiden Editionen. Magento speichert alles in einer Datenbank, die du kontrollierst, meist MariaDB oder MySQL, und gibt dir Admin Werkzeuge und eine vollständige API, um alles herauszuholen.³ Niemand kann deinen Shop abschalten oder deinen Katalog als Geisel nehmen. Das ist ein echter Vorteil gegenüber einer gehosteten Plattform, und es bedeutet, dass der Umzug, den ich unten beschreibe, eine Frage des Aufwands ist und nicht der Erlaubnis.

Was dich hält, sind nicht die Daten. Es ist das Gewicht des Apparats rundherum.

Ein ordentlich betriebener Magento 2 Shop ist ein Verbund beweglicher Teile. Für die Linie 2.4.9 erwartet er PHP 8.5, eine Suchmaschine wie OpenSearch 3, eine Datenbank auf MariaDB 12.3 oder MySQL 8.4, dazu einen Cache, eine Nachrichtenwarteschlange und einen Reverse Proxy davor.³ Jedes dieser Teile muss installiert, abgestimmt, gepatcht und aktualisiert werden, und diese Arbeit wird fast immer zu Agentursätzen gemacht, weil der Kreis der Leute, die das gut können, klein und gefragt ist. Die Plattform ist nicht teuer, weil Adobe gierig wäre. Sie ist teuer, weil sie groß ist, und große Software braucht große Pflege.

Das Zweite, was dich hält, ist die Support Uhr. Adobe gibt jeder 2.4 Release Linie drei Jahre Standard Support ab dem Erscheinungsdatum. Die Linie 2.4.6 verließ den Standard Support am 11. August 2026, 2.4.7 verlässt ihn am 31. Mai 2027, 2.4.8 am 31. Mai 2028 und 2.4.9, erschienen am 12. Mai 2026, am 31. Mai 2029.⁴ Dieser Takt bedeutet ein geplantes Upgrade Projekt alle ein bis zwei Jahre, ganz gleich, ob das Upgrade dir etwas bringt, das du wolltest. Auf einer Plattform, die du auch noch lizenzierst und hostest, ist der Upgrade Zyklus die Kost, die leise für immer wiederkehrt.

Nichts davon ist eine Falle im unehrlichen Sinn. Es ist schlicht der laufende Aufwand einer schwergewichtigen Plattform, und die Frage ist, ob dein Shop schwer genug ist, um sie zu brauchen.

Die Daten aus Magento herausholen

Weil dir die Datenbank gehört, ist das Herausholen der Daten eine echte Möglichkeit statt einer Verhandlung. Magento gibt dir zwei Wege, und ein ernsthafter Umzug nutzt beide.

Der erste ist der Importer und Exporter im Admin, unter System, dann Data Transfer. Der Export erzeugt kommagetrennte Dateien, und du wählst den Entitätstyp: Produkte, die Hauptdatei der Kunden, Kundenadressen, Advanced Pricing, Stock Sources und Customer Finances stehen als getrennte Exporte zur Verfügung.⁵ Das Format ist eine flache kommagetrennte Datei, in der jede Zeile, die mit einem Wert in der Spalte SKU beginnt, ein neues Produkt eröffnet, während weitere Zeilen seine Bilder und Optionen tragen.⁶ Der Import nimmt dasselbe kommagetrennte Format oder eine gezippte Fassung davon an, mit Verhalten zum Hinzufügen, Aktualisieren, Ersetzen oder Löschen von Datensätzen.⁶ Das ist das Werkzeug für den Großteil des Katalogs und die Kundenliste.

Der zweite Weg ist die Web API. Magento liefert ein Framework, das REST, GraphQL und SOAP bereitstellt, aufgebaut auf einem Modell aus Anlegen, Lesen, Ändern, Löschen und Suchen, sodass alles, was der Admin mit einem Produkt, einem Kunden oder einer Bestellung tun kann, programmatisch gesteuert werden kann.⁷ Die Authentifizierung läuft per Token für Integrationen, die du im Admin anlegst, per OAuth für externe Anwendungen oder per Login für eine Administratorin oder eine Kundin.⁷ Für einen Umzug ist die API der Weg, über den ich die Datensätze hole, die der flache Export unbeholfen behandelt, etwa Bestellungen mit ihrer vollständigen Zeilen und Statushistorie, und über den ich die Zählungen zwischen altem und neuem Shop abgleiche.

Zwei Grenzen solltest du kennen, bevor du um die API herum planst, denn beide sind Adobes eigene Voreinstellungen. Das Input Limiting begrenzt eine einzelne Anfrage auf 20 Entitäten bei synchronen Aufrufen und 5.000 bei asynchronen und begrenzt ein seitenweises Ergebnis auf 300 Einträge, ist aber standardmäßig abgeschaltet und wird unter Web Api Limits und GraphQL Input Limits konfiguriert.⁸ Davon getrennt kannst du ab Adobe Commerce 2.4.7 ein Rate Limiting für die über REST und GraphQL gesendeten Zahlungsinformationen einschalten, um Carding Angriffe zu dämpfen, das ebenfalls standardmäßig aus ist und eine Redis Verbindung braucht.⁹ Für einen einmaligen Umzug beißen diese Grenzen selten, aber wenn du große Mengen liest, paginierst du die Daten und kämpfst nicht gegen die Limits.

Das Datenmodell, und warum das Mapping Arbeit macht

Der Grund, warum ein Magento Export aufwendiger ist, als er aussieht, liegt in der Art, wie Magento ein Produkt speichert. Es nutzt ein Modell aus Entität, Attribut und Wert, meist EAV abgekürzt. Statt einer breiten Tabelle mit einer Spalte für jedes Produktfeld hält Magento die Attribute in mehreren Tabellen, eine Gruppe je Datentyp, und setzt ein Produkt zusammen, indem es über sie hinweg verknüpft. Adobe sagt es direkt: Objekte, die EAV Attribute nutzen, speichern ihre Werte typischerweise in mehreren Datenbanktabellen, und das Katalog und das Kundenmodul sind die Hauptnutzer.¹⁰

Dieses Design ist der Grund, warum Magento mit eigenen Attributen so flexibel ist. Du kannst ein Produktattribut für Form, Volumen, Spannung oder sonst etwas hinzufügen, und das Modell nimmt es ohne Schemaänderung auf. Der Preis dieser Flexibilität ist, dass dein Katalog keine ordentliche Tabelle ist, die an einer Stelle liegt. Er ist über das Modell verteilt, und die Bedeutung jedes Attributs, welche global sind und welche je Store View variieren, welche Pflicht sind, welche konfigurierbare Produkte speisen, lebt teils in den Daten und teils in den Köpfen derer, die es eingerichtet haben.

Für einen Umzug zählt das auf eine konkrete Weise: der Export gibt dir die Werte, aber du musst sie noch auf das Modell des neuen Shops abbilden, entscheiden, welche Attribute den Umzug überleben und welche nie genutzt wurden, und jene abgleichen, die sich als etwas erweisen, das subtil anderes meint, als ihr Name nahelegt. Das ist kein Hindernis. Es ist ehrliche Arbeit, bei einem echten Katalog meist ein paar Tage sorgfältigen Abgleichs, und es ist dieselbe Art von Arbeit, die der Beitrag zu Produkt und Katalogdaten im Detail durchgeht. Setz die Erwartung jetzt: die Daten kommen heraus, und sie abzubilden ist der Teil, der Zeit kostet.

Die Exportwerkzeuge und die API Grenzen

Was zieht also sauber um, was mit Aufwand und was muss neu gebaut werden? Das ist die Tabelle, die ich mir von mehr Anbietern wünschte.

Was	Wie es Magento verlässt	Wie schwer
Produkte, Varianten, Preise, Bilder, Kategorien, Bestand	Admin Export in kommagetrennte Dateien, auf das neue Modell abgebildet	Zieht mit Mapping Arbeit um
Kunden und Adressen	Admin Export der Kundenhauptdatei und der Adressen	Zieht sauber um
Bestell und Kaufhistorie	Über die API als Datensätze gelesen, als reine Lesehistorie importiert	Zieht teilweise um
Passwörter	Nur Hashes, beim ersten Login aktualisiert, nie der Klartext	Sonderbehandlung
Gespeicherte Karten und Token	Nur zwischen zertifizierten Anbietern, oft braucht es das Gateway	Am härtesten, zuerst planen
Abonnements aus einer Erweiterung	Hängt von der Erweiterung ab, braucht oft eigenen Export	Am härtesten, zuerst planen
URLs und Weiterleitungen	Von Hand von der alten auf die neue Struktur abgebildet	Zieht mit Aufwand um
Theme, Erweiterungen, eigene Module	Ziehen nicht um, werden als Code neu gebaut	Neu gebaut

Die Zeilen im härtesten Band sind die, die du am ersten Tag ansprichst, nicht in der letzten Woche. Auf jede komme ich gleich zurück.

Die Fallen, die typisch für Magento sind

Jede Plattform hat eigene Stellen, an denen ein Umzug hängen bleibt. Für Magento sind das die, die ich ehrlich kennzeichnen muss.

Passwörter kommen nie als Passwörter herüber. Magento speichert das Passwort einer Kundin nie im Klartext. Es speichert einen Hash, ein Salt und eine Versionsmarke, mit SHA256 oder Argon2id je nachdem, wann das Konto zuletzt gesetzt wurde,¹¹ und es gibt keinen Weg, das ursprüngliche Passwort zurückzulesen, was der ganze Sinn des Hashens ist. Weil dir die Datenbank gehört, kannst du diese Hashes in den neuen Shop tragen, sie beim ersten Login der Kundin einmal prüfen und das Passwort dann im eigenen Format des neuen Shops speichern, sodass niemand etwas zurücksetzen muss und keine Kundin es bemerkt. Wenn dir diese zusätzliche Sorgfalt den Aufwand nicht wert ist, funktioniert auch ein einmaliges Zurücksetzen zum Start. Der Beitrag zu Kundenkonten behandelt beide Wege und die Servicenachricht, die dazugehört.

Zahlungen und hinterlegte Karten sind das härteste Einzelteil. Eine gespeicherte Karte gehört dem Zahlungsanbieter, nicht Magento, also hängt es von deinem Gateway ab und nicht von einem der beiden Shops, ob deine Kundinnen ihre gespeicherten Karten behalten. Der beste Fall ist, dass dein Magento Shop bereits über einen Anbieter abrechnet, der dir gehört, etwa dein eigenes Stripe Konto, denn dann verbindet sich der neue Solidus Shop mit demselben Konto und die Token ziehen gar nicht um. Der schlechteste Fall ist ein Anbieter, der Token nur an einen anderen Inhaber mit der höchsten Stufe des Kartensicherheitsstandards herausgibt, falls er sie überhaupt herausgibt. Das ist die Frage, die du vor allem anderen klärst, und der Beitrag zu Zahlungstoken ist das Detail. Lies die versteckten Gefahren beim Wechsel von Payment Gateways, bevor du dich zu einem Gatewaywechsel zusätzlich zum Plattformwechsel verpflichtest.

Abonnements leben in einer Erweiterung, nicht im Kern. Magento hat keine native wiederkehrende Abrechnung, wenn dein Shop also Abos verkauft, tut er das über eine Erweiterung oder die Abofunktion eines Zahlungsanbieters, und die Daten und die Logik sitzen dort. Das macht aktive Abonnements zum anderen harten Fall: ein aktives Mandat lässt sich oft nicht einfach exportieren und wieder einfügen und braucht vielleicht die Mithilfe der Erweiterung oder des Gateways, um ohne Unterbrechung der Abrechnung einer Kundin umzuziehen. Kennzeichne jedes laufende Abo früh und plane den Umschaltpunkt um die Abrechnungstermine herum. Der Beitrag zu Abonnements ist der, den du ganz lesen solltest, wenn das auf dich zutrifft.

Die URL Struktur ist deine, und du bewahrst sie. Magento baut eigene URLs, oft mit .html am Ende, mit Kategoriepfaden und Parametern aus der Layered Navigation, und Jahre an Links und Rankings hängen daran. Jede dieser Adressen muss mit einer dauerhaften Weiterleitung auf ihren neuen Ort abgebildet werden, sonst trifft der Verkehr, der dich gestern fand, morgen auf eine tote Seite. Auf den Shops, die ich baue, leben die Weiterleitungen in der Anwendung selbst, in einer Tabelle, die das eigene Personal des Shops bearbeiten kann, sodass sie jedes künftige Deploy überleben. Die Mechanik steht im Beitrag zu Produkt und Katalogdaten, denn die Weiterleitungskarte und der Produktumzug sind dieselbe Übung.

Die Logik versteckt sich in Modulen. Der wahre Grund, warum ein Magento Shop schwer zu verlassen ist, sind selten die Daten. Es ist, dass Jahre an Geschäftsregeln, Preislogik, Integrationen mit einem ERP oder einem Lager und stille Anpassungen in Erweiterungen und eigenen Modulen leben, die niemand vollständig dokumentiert hat. Nichts davon zieht per Export um. Es muss verstanden und als gewöhnlicher Anwendungscode neu gebaut werden. Das ist Arbeit, aber es ist auch die Chance, denn die neu gebaute Fassung ist getestet, dokumentiert und deine.

Ein Beispiel aus Graz

Lass es mich mit einem erfundenen Unternehmen greifbar machen, denn echte Kundengeschichten sind nicht meine, sie zu erzählen.

Murtal Werkzeug (murtalwerkzeug.example) ist ein Grazer Anbieter von Werkzeug und Arbeitskleidung und verkauft sowohl an Private als auch an Gewerbekunden. Der Shop setzt online rund vier Millionen Euro im Jahr um, führt einen Katalog von etwa 12.000 Produkten mit starker Nutzung eigener Attribute für Spannung, Größe und Material und ist seit sechs Jahren auf Adobe Commerce. Die Gewerbekunden haben ausgehandelte Preislisten und zahlen auf monatliche Rechnung. Der Shop funktioniert. Was aufhörte zu funktionieren, war die Rechnerei: die Adobe Commerce Lizenz, eine verwaltete Hostingrechnung in der Größe der Plattform und ein Agenturvertrag für Patches und das nächste Upgrade kosteten zusammen jedes Jahr mehr als zwei Vollzeitkräfte, und der Inhaber konnte nicht sagen, was die Lizenz kaufte, das ein Entwickler nicht könnte.

Wenn ich so einen Umzug plane, dreht sich die erste Woche nicht um Produkte. Sie dreht sich um die drei harten Zeilen in der Tabelle. Murtal Werkzeug rechnet über das eigene Stripe Konto ab, also bleiben die gespeicherten Karten, wo sie sind: der neue Solidus Shop verbindet sich mit demselben Konto, und kein Token zieht um. Es gibt keine Abonnements, womit der andere harte Fall ganz entfällt. Die Passwörter sind Argon2id Hashes in einer Datenbank, die der Inhaber kontrolliert, also ziehen sie um und werden beim ersten Login aktualisiert, und keine Kundin wird zum Zurücksetzen gezwungen. Diese in Woche eins geklärten Antworten machen den Rest des Projekts ruhig.

Der Katalog ist die eigentliche Mühe. Der EAV Export kommt als kommagetrennte Dateien heraus, und die Mapping Arbeit besteht darin zu entscheiden, welche der vielen eigenen Attribute noch genutzt werden, Jahre an Fastdubletten zusammenzuführen und die Gewerbepreislisten auf das neue Modell abzugleichen. Die Bestellhistorie kommt über die API als reine Lesedatensätze, sodass Kundenservice und Kundinnen die Vergangenheit weiter nachsehen können, während Gutschriften und Retouren auf wirklich alten Bestellungen für ein kurzes Übergabefenster beim alten System bleiben. Die 12.000 alten URLs werden zu einer Weiterleitungskarte, die jemand von Murtal Werkzeug prüft, denn nur dort weiß man, welche Kategorieseiten ihren Verkehr noch verdienen. Auf der anderen Seite werden die Gewerbepreislisten und die monatliche Rechnung, die auf Magento eine Erweiterung waren, zu gewöhnlichen getesteten Funktionen der Rails Anwendung, und die jährliche Lizenz und das erzwungene Upgrade verschwinden für immer aus dem Budget.

Der Umzug ist nicht gratis und nicht sofort. Aber ein Jahr später zahlt Murtal Werkzeug für Hosting und einen Entwickler, der seinen Code kennt, und sonst nichts, und der Shop gehört ihm ganz.

Der ehrliche Umzug auf Solidus

Die Form eines Magento Umzugs ist jedes Mal dieselbe, und die Reihenfolge zählt.

Ich beginne mit den drei Fragen, die ein Projekt versenken können: wo liegen die gespeicherten Karten und Token und ziehen sie um, gibt es aktive Abonnements und wovon hängen sie ab, und wer auf deiner Seite besitzt die Daten und kann sagen, was ein Attribut bedeutet. Klär die zuerst, denn spät entdeckt sind sie teuer. Dann kommen Katalog und Kunden über den Admin Export und die API herüber, auf das Solidus Modell abgebildet mit dem Abgleich, den die EAV Struktur verlangt. Die Bestellhistorie folgt als reine Lesedatensätze. Die URL Karte wird gebaut und von jemandem geprüft, der den Shop kennt. Die Storefront, der Checkout und jede Integration, die in einem Modul lebte, werden als getesteter Rails Code neu gebaut. Alt und neu laufen ein paar Wochen parallel mit eingefrorenem Katalog, der finale Import wird geprobt, bis er langweilig ist, und die Umschaltung geschieht an einem ruhigen Werktagvormittag, wobei der alte Shop dreißig Tage unangetastet als Rückfallebene bleibt.

Das Ergebnis ist ein passend dimensionierter Shop. Wo Magento dir eine Plattform für den gehobenen Betrieb gab und dich fürs Lizenzieren, Hosten und Aktualisieren zahlen ließ, gibt dir Solidus eine Rails Anwendung ohne Lizenzgebühr, ohne von einem Anbieter aufgezwungenen Upgrade Takt und mit einer Hostingrechnung, die zu einem Shop passt statt zu einer Plattform für Tausende. Die Anpassung, die eine Erweiterung und ein Angebot war, wird zu Code, der dir gehört. Für den vollen Geldvergleich über fünf Jahre, samt der Adobe Commerce Lizenz, die du kaum beziffern kannst, lies die Gesamtkosten über fünf Jahre, und für die Einordnung der Plattformen zueinander den Plattformvergleich.

Es ist auch gut zu wissen, falls du noch eine Weile in der Magento Welt bleiben willst, dass es Wege unterhalb eines vollen Umzugs gibt. Die Storefront Hyvä, die viele Agenturen nutzen, um Magentos langsames Standard Theme zu ersetzen, wurde im November 2025 kostenlos und quelloffen,¹² und ein gemeinnütziger Verein betreibt eine gemeinschaftliche Distribution von Magento Open Source, gegründet aus Sorge um die Zukunft der quelloffenen Edition.¹³ Keiner von beiden ändert die Lizenz oder die Upgrade Ökonomie von Adobe Commerce, aber beide sind ehrliche Wege, die Last zu erleichtern, falls ein Umzug noch nicht passt.

Wann du bleiben solltest

Ich verliere die Arbeit lieber, als einen Shop umzuziehen, der bleiben sollte, also hier, wann du auf Magento bleibst.

Bleib, wenn du wirklich nutzt, wofür Magento da ist: einen sehr großen Katalog, tiefe Regeln im Geschäft zwischen Unternehmen, mehrere Shops und Währungen, die die Plattform nativ bewältigt, und ein Team oder eine Agentur, denen du vertraust. Bleib, wenn du auf der kostenlosen Open Source Edition bist, dein Hosting im Griff ist und die Rechnung nicht wirklich wehtut. Bleib, wenn die einzige Klage die Adobe Commerce Lizenz ist und die ehrliche Lösung ist, mit einem Entwickler auf Open Source zu wechseln statt Magento ganz zu verlassen. Und beginne nie einen Umzug in den Monaten vor deiner Hauptsaison oder ohne eine benannte Person auf deiner Seite, die die Daten versteht.

Der Shop, der umziehen sollte, ist der, der Preise für den gehobenen Betrieb zahlt, obwohl er nicht für den gehobenen Betrieb dimensioniert ist, wo die Lizenz, das Hosting und die raren Spezialisten mehr kosten als das Geschäft, das die Plattform trägt. Wenn das auf dich zutrifft, sagt das Geld meist: zieh um, und der Beitrag zu den Gesamtkosten zeigt dir, um wie viel.

Was das für dich bedeutet

Magento zu verlassen ist keine Flucht aus einer Plattform, die dich eingesperrt hätte. Dir gehören deine Daten auf beiden Editionen, und die Tür ist offen. Es ist die Entscheidung, aufzuhören, für eine Plattform für den gehobenen Betrieb zu zahlen, aus der du herausgewachsen bist oder in die du nie hineingewachsen bist, und einen Shop zu betreiben, der passt. Die Daten kommen über den Admin Export und die API heraus. Der Katalog braucht wegen des EAV Modells echte Mapping Arbeit. Die Passwörter, die gespeicherten Karten und etwaige Abonnements sind die harten Teile, und sie werden zuerst geklärt. Alles andere ist ein gut verstandenes Projekt mit klarer Reihenfolge.

Wenn dir gehört, was Magento gibt, und du es nutzt, behalt es. Wenn du für weit mehr Plattform zahlst, als du brauchst, und deine Daten ohnehin dir gehören, ist ein eigener Solidus Shop meist die richtige Größe. Wer überhaupt die Schlüssel zu diesen Daten hält, ist auf jeder Plattform eine klare Frage wert, und das ist das Thema von wem deine Geschäftsdaten gehören.

Wenn du eine klare Antwort auf deine eigenen Zahlen willst, bring sie in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Ich stelle deine Lizenz, dein Hosting und deine Agenturzahlen einem Solidus Bau gegenüber, kennzeichne die Zahlungs und Abofragen vor allem anderen und sage dir ehrlich, ob sich der Umzug für dich lohnt. Manchmal tut er das nicht, und dann sage ich es.

Footnotes

1. Magento Open Source, magento2 Repository und Lizenzhinweis (Open Software License 3.0, wobei kommerzielle Bedingungen unter einem Bestelldokument mit Adobe die OSL je Datei ablösen), GitHub, abgerufen am 14. November 2026, https://github.com/magento/magento2 ↩ ↩²

2. Adobe, Adobe Commerce Preise (Preise von Adobe statt aus einer öffentlichen Preisliste), abgerufen am 14. November 2026, https://business.adobe.com/products/magento/pricing.html ↩

3. Adobe Experience League, Systemanforderungen von Adobe Commerce und Magento Open Source (Editionen, PHP 8.5, OpenSearch 3, MariaDB 12.3 oder MySQL 8.4 für 2.4.9), abgerufen am 14. November 2026, https://experienceleague.adobe.com/en/docs/commerce-operations/installation-guide/system-requirements ↩ ↩²

4. Adobe Experience League, Adobe Commerce Lifecycle Policy (dreijähriges Standard Support Fenster, mit den Release und Supportdaten von 2.4.6 bis 2.4.9), abgerufen am 14. November 2026, https://experienceleague.adobe.com/en/docs/commerce-operations/release/planning/lifecycle-policy ↩

5. Adobe Experience League, Export data (System, Data Transfer, Export, mit Entitätstypen und CSV Ausgabe), abgerufen am 14. November 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-export ↩

6. Adobe Experience League, CSV data files (kommagetrenntes Format, eine Zeile je SKU, der Import nimmt CSV oder ZIP an), abgerufen am 14. November 2026, https://experienceleague.adobe.com/en/docs/commerce-admin/systems/data-transfer/data-csv ↩ ↩²

7. Adobe Developer, Commerce web APIs, getting started (GraphQL, REST und SOAP auf einem CRUD und Suchmodell, mit Token, OAuth und Login Authentifizierung), abgerufen am 14. November 2026, https://developer.adobe.com/commerce/webapi/get-started/ ↩ ↩²

8. Adobe Developer, API security und Input Limiting (Standardmaximum 20 Entitäten bei synchronen und 5.000 bei asynchronen Anfragen, 300 Einträge je Seite, standardmäßig abgeschaltet), abgerufen am 14. November 2026, https://developer.adobe.com/commerce/webapi/get-started/api-security ↩

9. Adobe Developer, Rate limiting (Rate Limiting für Zahlungsinformationen über REST und GraphQL ab Adobe Commerce 2.4.7, standardmäßig abgeschaltet, braucht Redis), abgerufen am 14. November 2026, https://developer.adobe.com/commerce/webapi/get-started/rate-limiting ↩

10. Adobe Developer, EAV and extension attributes (Objekte mit EAV Attributen speichern Werte in mehreren Datenbanktabellen, und Katalog und Kundenmodul sind die Hauptnutzer), abgerufen am 14. November 2026, https://developer.adobe.com/commerce/php/development/components/attributes ↩

11. Magento Open Source, Encryptor.php (Passwort Hash Versionen SHA256 und Argon2id, gespeichert als Hash, Salt und Version, nie im Klartext), GitHub, abgerufen am 14. November 2026, https://github.com/magento/magento2/blob/2.4-develop/lib/internal/Magento/Framework/Encryption/Encryptor.php ↩

12. Hyvä Themes, Hyvä Theme is now open source and free, 6. November 2025, https://hyva.io/blog/news/hyva-is-free-open-source.html ↩

13. Mage-OS Association, About Mage-OS (gemeinschaftliche Distribution von Magento Open Source, gemeinnütziger Verein, gegründet aus Sorge um die quelloffene Edition), abgerufen am 14. November 2026, https://mage-os.org/about/ ↩