Von osCommerce und Zen Cart zu einem eigenen Shop wechseln

Was osCommerce und Zen Cart sind, und wer sie entwächst

osCommerce ist einer der ursprünglichen Open Source Warenkörbe. Es begann im März 2000 in Deutschland, geschrieben von Harald Ponce de Leon, und war jahrelang der übliche Weg, einen Shop ohne Lizenzgebühr online zu stellen.¹ Zen Cart ist sein bekanntester Nachfahre: ein Fork, der sich 2003 vom osCommerce Code abspaltete, bei Templates und Funktionen einen eigenen Weg einschlug und zu einem eigenständigen Projekt heranwuchs.² Beide sind in PHP geschrieben, beide halten alles in einer MySQL Datenbank, und beide sind Software, die du selbst auf deinem eigenen Server betreibst. Keiner verlangt Miete. Zen Cart steht unter der GNU General Public License, der Quellcode ist also offen, und du oder jede Entwicklerin deines Vertrauens könnt ihn lesen und ändern.³

Diese zwei Warenkörbe betreiben noch heute tausende echte Shops, manche davon gut gehend, manche seit einem Jahrzehnt kaum angefasst. Das will ich ab der ersten Zeile fair sagen. Wenn dein osCommerce oder Zen Cart Shop klein, stabil, günstig im Betrieb ist und dir keine Sorgen macht, dann lass ihn in Ruhe. Alter allein ist kein Grund, Geld auszugeben. Für diesen Shop ist der Artikel nicht gedacht.

Er ist für den langlebigen Shop, der sein Alter zu spüren beginnt. Die Anzeichen sind konkret. Dein Hoster meldet sich und sagt, dass die PHP Version, auf der dein Shop läuft, abgeschaltet wird, und der Shop läuft auf der neuen nicht ohne Arbeit. Das Template wurde vor Jahren von Hand bearbeitet, von jemandem, den du nicht mehr erreichst. Die Add ons, die den Shop zu deinem machen, wurden 2013 aus einem Forum geladen und seither von niemandem aktualisiert. Du hast jemanden gesucht, der eine Änderung macht, und festgestellt, dass Entwickler, die diese Systeme gut kennen, schwerer zu finden und teurer zu buchen sind. Der Shop läuft, aber jede Änderung fühlt sich an, als könnte sie das Ganze zum Einsturz bringen. Wenn du dort stehst, ist das hier die ehrliche Form eines Umzugs auf einen modernen, eigenen Stack. Ich baue diesen Ersatz auf Solidus, einem Open Source Shop Framework auf Ruby on Rails, und ich führe den Umzug durch.⁴ Das Ergebnis gehört dir. Für die tiefen, plattformunabhängigen Details, wie jede Art von Daten wandert, verweise ich auf die Leitfäden, denen das Thema gehört, statt es hier zu wiederholen, angefangen bei der Säule, was sich überträgt und was nicht.

Was dir gehört, und was eingesperrt ist

Weil beide Warenkörbe selbst gehostet sind, spricht die wichtigste Tatsache beim Verlassen für dich: die Datenbank gehört dir. Alles, was der Shop weiß, liegt in MySQL Tabellen, die du direkt lesen kannst, mit Namen wie products, customers, orders und categories. Ein einfacher Auszug mit mysqldump gibt dir alles, und von dort ist die Arbeit ein sauberes, sorgfältiges Zuordnen in ein neues Modell statt eines Kampfes um Zugang. Vergleiche das mit einer gehosteten Plattform, wo du nur die Exporte bekommst, die der Anbieter dir zugesteht, und du siehst, warum ein eigener, selbst gehosteter Shop leichter zu verlassen ist. Bei dem, was den meisten am meisten Angst macht, deinen Daten, sind diese alten Warenkörbe großzügig.

Eingesperrt sind nicht die Daten. Eingesperrt ist das Verhalten rundherum. Die Tabelle unten ist die ehrliche Aufteilung.

Was	Wie es wandert	Wohin es geht
Produkte, Optionen, Attribute, Preise, Bilder, Kategorien, Lagerstand	Sauber, über einen Datenbankauszug oder die Importwerkzeuge, als Zuordnung	Das Solidus Produktmodell, siehe Produkt und Katalogdaten
Kundenkonten und Adressen	Sauber, aber Passwörter sind gehasht und nicht wiederverwendbar	Neu aufgebaut mit Zurücksetzen oder Prüfen beim ersten Login, siehe Kundenkonten
Bestell und Kaufhistorie	Als Datensätze, zum Nachschlagen und für den Service	Eine nur lesbare Historie im neuen Shop
SEO Schlüsselwörter und URLs	Als Liste zum Zuordnen, nicht zum Kopieren	Eine Weiterleitungstabelle im neuen Shop
Zahlungskonfiguration und gespeicherte Karten	Nicht portabel, jedes Modul legt es anders ab	Neu gebaut rund um dein eigenes Gateway Konto, siehe Zahlungstoken
Templateänderungen, Add ons und Integrationen	Wandern gar nicht	Neu gebaut als eigener, getesteter Code

Die Realität von Datenbank und Export

Diese Warenkörbe entstanden, bevor umfangreiche REST Schnittstellen eine normale Erwartung waren, und das merkt man. Du wechselst nicht von osCommerce oder Zen Cart weg, indem du eine saubere Schnittstelle aufrufst, die dir jedes Produkt und jede Bestellung auflistet. Du migrierst aus der Datenbank, und je früher du das akzeptierst, desto ruhiger läuft das Projekt.

Der direkte Zugang zur Datenbank ist der echte Weg und der stärkste. Der Server gehört dir, ein voller Auszug ist also immer verfügbar, nichts wird wegsummiert und nichts hinter einer Anbietervorstellung davon versteckt, was du sehen darfst. Bei einem Katalog jeder Größe oder einer über fünfzehn Jahre gewachsenen Bestelltabelle ist das genau die Grundlage, mit der ich arbeite.

Die Import und Exportwerkzeuge im Backend sitzen obendrauf, und man sollte sie genau benennen, weil viele mehr für eingebaut halten, als wirklich da ist. In Zen Cart ist der übliche Weg, Produktdaten in Menge zu bewegen, ein Zusatz aus der Plugins Library, keine Kernfunktion: Werkzeuge wie DbIo und EasyPopulate lesen und schreiben CSV Dateien, und ein Produktimport wird über die Modellnummer jedes Artikels geführt.⁵ Sie leisten echte Arbeit für den Katalog, aber zwei Vorbehalte zählen. Erstens decken sie die Standardtabellen der Produkte ab und nicht das, was ein Add on oder eine Handänderung anderswo abgelegt hat, die Tabelle ist also ein Startpunkt und nicht die ganze Wahrheit. Zweitens kann ein Import gegen eine laufende Datenbank zerstörerisch sein, wenn eine Spalte falsch ist, und genau deshalb gleiche ich alles gegen einen direkten Auszug ab. osCommerce hat dieselbe Form: die Daten liegen in MySQL, und der saubere Weg hinaus ist die Datenbank, nicht eine Schnittstelle, die nie für einen vollen Export gebaut wurde.

Passwörter wandern nie mit, und das ist gut so

Kein Passwort kommt in einer Form herüber, mit der sich jemand anmelden könnte, aus keinem der beiden Warenkörbe, weil keiner das Passwort selbst speichert. Das aktuelle Zen Cart hasht jedes Passwort mit PHPs eigener Funktion password_hash und dem Standardverfahren, das heute bcrypt ist, und ältere Codepfade nutzten ein eigenes gesalzenes Verfahren.⁶ Die klassische osCommerce Linie, und ältere Zen Cart Installationen, reichen noch weiter zurück, zu gesalzenem Hashing im MD5 Stil aus einer Zeit, in der das normal war. In jedem Fall ist der gespeicherte Wert einseitig. Er lässt sich nicht in das Passwort zurückrechnen, es gibt also nichts mitzunehmen, womit sich jemand anmelden könnte.

Das ist ein Vorteil, kein Verlust, und der Plan dazu ist der, den der Leitfaden zu Kundenkonten vollständig beschreibt. Jedes Konto, mit Name, Adressen und Bestellhistorie, wird im neuen Shop angelegt. Beim ersten Besuch setzt die Kundin entweder über einen einmaligen Link ein neues Passwort, oder, wenn du die alten Hashes mitnimmst, wird der alte Hash einmal geprüft und danach still durch das Format des neuen Shops ersetzt, sodass niemand es bemerkt. Welchen Weg du auch wählst, niemand sieht je ein Passwort im Klartext, und das neu aufgebaute Konto hängt an der ganzen Historie. Alternde Hashes im MD5 Stil nur zur Vermeidung eines Zurücksetzens in einen brandneuen Shop zu tragen, ist das Einzige, was ich nicht täte; ein sauberes Zurücksetzen auf ein modernes Verfahren ist für einen so alten Shop der sicherere Standard.

Der echte Grund zu wechseln ist das Alter, nicht die Daten

Fast niemand verlässt diese Warenkörbe, weil die Daten gefangen sind. Man verlässt sie, weil die Software darunter gealtert ist und die Kosten und Risiken, einen langlebigen Shop darauf zu halten, Jahr für Jahr gestiegen sind. Es gibt vier ehrliche Druckpunkte, und man sollte sie trennen, weil die zwei Projekte nicht im selben Zustand sind.

Der erste ist die Architektur und das Templating. Diese Warenkörbe wurden um das Web von vor fünfzehn oder zwanzig Jahren herum entworfen. Das Template ist eine Reihe von PHP Dateien, die du direkt bearbeitest, und Jahre kleiner Änderungen durch verschiedene Hände werden zu einer Schicht, die nur ihr letzter Autor verstand. Moderne Erwartungen, eine schnelle Storefront, ein sauberes Erlebnis am Handy, strukturierte Daten für die Suche, ein Checkout, der die heutigen Regeln erfüllt, sind alle erreichbar, aber jede davon wird einem Gerüst nachgerüstet, das nicht dafür gebaut wurde.

Der zweite ist das Add on Ökosystem, und hier lebt meist das echte Verhalten des Shops. Ein funktionierender osCommerce oder Zen Cart Shop mit Anspruch ist selten der nackte Kern. Er ist der Kern plus ein Stapel Community Add ons, über die Jahre geladen: eine bessere Suche, eine Navigation mit Filtern, ein Modul für Händlerpreise, Mails zum abgebrochenen Warenkorb, ein Bewertungssystem, ein Zusatz für SEO URLs, ein Feed für Marktplätze, ein, zwei Zahlungsmodule. Jedes kam von einem anderen Autor nach einem anderen Zeitplan, viele wurden seit Jahren nicht angefasst, und das Wissen, was jedes wirklich tut, ging oft mit dem Entwickler, der es installierte. Dieser Stapel ist das Wertvollste und zugleich Gefährlichste, das es in einer Migration zu verstehen gilt, denn er ist der Unterschied zwischen dem Shop, den du zu haben glaubst, und dem Shop, den du wirklich hast.

Der dritte ist Sicherheit und Druck durch die PHP Version, und das erzwingt meist die Entscheidung. Das sind PHP Anwendungen, und PHP selbst zieht weiter: ältere Versionen erhalten vom PHP Projekt nach einem veröffentlichten Zeitplan keine Sicherheitskorrekturen mehr, und Hoster weigern sich irgendwann, sie zu betreiben.⁷ Ein Shop, der für PHP 5 oder ein frühes PHP 7 geschrieben wurde, läuft nicht einfach auf einer aktuellen Version; die Sprache hat sich darunter verändert. Das aktuelle Zen Cart hat Schritt gehalten: die Linie 2.2.x ist für PHP 8.2 bis 8.5 und aktuelle MySQL oder MariaDB Versionen gebaut, Version 2.2.2 erschien am 4. April 2026, und Zen Cart war tatsächlich die erste Open Source Shop Anwendung, die die volle Zertifizierung nach dem Sicherheitsstandard der Kartenindustrie für Zahlungsanwendungen erreichte.⁸⁹ Ein Zen Cart Shop, der aktuell gehalten wurde, steht also auf verteidigbarem Boden, und der Druck liegt dort vor allem im Gewicht alter Add ons. Die klassische osCommerce Linie ist die härtere Geschichte: ihre letzte verbreitet betriebene stabile Ausgabe, 2.3.4.1, stammt aus 2017, und während eine eigene, moderne osCommerce Neufassung existiert und aktuelles PHP anpeilt, ist das Verschieben des klassischen Shops dorthin ein Neubau, kein Update.¹¹⁰ So oder so, ein Shop, der auf einer nicht mehr unterstützten PHP Version festsitzt, läuft auf einer Plattform ohne Sicherheitskorrekturen, und das ist ein geschäftliches Risiko, keine Entwicklerlaune.

Der vierte sind die Menschen. Weit weniger Entwickler arbeiten flüssig mit genau diesen Warenkörben als vor zehn Jahren, und die, die es tun, sind zunehmend die Einzigen, die deinen besonderen Stapel an Add ons gefahrlos anfassen können. Von einem schrumpfenden Kreis an Spezialisten für ein System im Zentrum deines Geschäfts abzuhängen, ist ein stilles Risiko, das erst im denkbar schlechtesten Moment laut wird.

Mein Argument für einen eigenen Solidus Shop ist nicht, dass Rails modern ist. Es ist, dass du einen alternden Warenkorb plus einen Turm fremder Add ons, jedes eine Abhängigkeit, die du nicht kontrollierst, durch eine moderne Anwendung ersetzt, die dir gehört, die mit Tests beweist, dass sie sich richtig verhält, die auf einer unterstützten Sprache und einem unterstützten Framework läuft, und die jede fähige Rails Entwicklerin pflegen kann. Solidus ist Open Source unter der freizügigen BSD Lizenz, der Shop, den ich baue, trägt also keine Lizenzgebühr und keine eigene Abhängigkeit.⁴

SEO URLs und die Weiterleitungen

Beide Warenkörbe bauen Adressen standardmäßig aus Abfrageparametern, ein Produkt sitzt also bei etwas wie index.php?products_id=42 in osCommerce oder index.php?main_page=product_info&products_id=42 in Zen Cart. Die meisten langlaufenden Shops haben irgendwann ein SEO Modul ergänzt, um daraus lesbare Adressen mit dem Produkt oder Kategorienamen zu machen. So oder so ist jede dieser Adressen etwas, das sich eine Kundin gemerkt hat und das eine Suchmaschine indexiert hat, und bei einem Shop, der ein Jahrzehnt lang gehandelt hat, tragen sie echtes Ranking.

Der Umzug in einen neuen Shop ist der Moment, in dem dieser Wert am häufigsten weggeworfen wird, und das hat nichts mit diesen Warenkörben zu tun und alles mit Disziplin. Jede Adresse, die im letzten Jahr einen Besuch oder einen Link bekommen hat, muss mit einer dauerhaften Weiterleitung an ihren neuen Ort geführt werden, die direkt auf die Zielseite zeigt und nicht über eine Kette. Die ganze Methode, und warum der meiste Rankingverlust in einer Migration aus verpassten Weiterleitungen kommt und nicht aus dem Umzug selbst, steht im Leitfaden zu Produkt und Katalogdaten. Die eine plattformspezifische Anmerkung ist eine erfreuliche: weil deine URL Schlüsselwörter und Produktkennungen in Tabellen liegen, die du direkt lesen kannst, ist der erste Entwurf der Weiterleitungsliste eine Abfrage und kein Crawl. In den Shops, die ich baue, leben die Weiterleitungen danach als bearbeitbare Tabelle in der Anwendung selbst, sie überstehen also jedes künftige Deployment, und dein eigenes Team kann eine ergänzen, sobald es in der Search Console eine Verirrte entdeckt.

Zahlungen und gespeicherte Karten

Zahlungen sind der Punkt, an dem eine alte Migration aufhört, ordentlich zu sein, und sie sind das, was zuerst zu klären ist, nicht zuletzt. In osCommerce wie in Zen Cart ist jedes Gateway ein eigenes Zahlungsmodul, oft ein alterndes, und jedes legt seine Konfiguration und jeden Verweis auf eine gespeicherte Karte auf eigene Weise ab. Es gibt keinen einzelnen, portablen Tresor zum Übergeben. Was wirklich zählt, ist, wer die Kartendaten hält, und die Antwort ist nie der Warenkorb: es ist dein Zahlungsanbieter. Wenn dein Shop Karten bereits über ein eigenes Konto bei einem modernen Anbieter wie Stripe belastet, gehören die gespeicherten Karten zu diesem Konto, und der neue Solidus Shop kann sich mit demselben Konto verbinden, sodass die Karten einfach dort bleiben. Sitzen die Karten dagegen bei einem Anbieter, den du nur über ein altes Zahlungsmodul erreicht hast, bedeutet ein Umzug eine Übergabe von Anbieter zu Anbieter, die der empfangende Abwickler nur von einem anderen Inhaber mit der höchsten Stufe des Kartensicherheitsstandards akzeptiert, und diese Übergabe enthält nie die Abos oder die Zahlungshistorie neben den Karten.

Entscheide deinen Zahlungsanbieter, bevor eine Zeile des neuen Shops geschrieben wird, denn diese eine Entscheidung bestimmt, ob wiederkehrende Kundinnen ihre gespeicherten Karten behalten oder neu eingeben müssen. Der Leitfaden zu Zahlungstoken geht jeden Fall durch, und wenn dir das Thema Unbehagen bereitet, ist die warnende Geschichte vom Wechseln der Payment Gateways die mahnende Fassung. Wenn dein Shop irgendetwas wiederkehrend verkauft, behandle das als härtesten Teil des ganzen Umzugs und sprich es am ersten Tag an: das Mandat, das dir erlaubt, eine Kundin erneut zu belasten, liegt beim Gateway, nicht im Warenkorb, ein laufendes Abo lässt sich also nicht einfach exportieren und erneut abspielen, und manchmal ist die ehrliche Antwort, dass bestehende Abonnentinnen neu zustimmen müssen.

Ein durchgerechnetes Beispiel

Lass es mich an einem erfundenen Shop konkret machen. Das Grazer Teehaus (grazerteehaus.example) ist ein Grazer Betrieb, der seit 2009 losen Tee, Mischungen und Zubehör online verkauft. Es läuft auf Zen Cart, macht online etwa € 900.000 Umsatz im Jahr, führt rund 1.800 Produkte, wenn man Dosengrößen und Geschenksets zählt, und hat eine kleine, aber treue Aboseite: einen monatlichen Teeclub, abgerechnet über ein altes Zahlungsmodul. In sechzehn Jahren hat der Shop ein Dutzend Community Add ons angesammelt, ein von Hand bearbeitetes Template und ein SEO Modul, und die Händlerpreise für die Großkunden hängen an einem Add on, das niemand dokumentiert hat.

Das Problem der Inhaberin ist nicht, dass der Shop kaputt ist. Es ist, dass die Hosting Firma angekündigt hat, die PHP Version, von der der Shop abhängt, abzuschalten, der Shop auf aktuellem PHP nicht ohne echte Arbeit läuft, und der eine Entwickler, der die Add ons kannte, in Pension gegangen ist. Das Angebot, alles auf eine unterstützte PHP Version zu ziehen, kommt den Kosten eines Neustarts nahe, für keine neue Fähigkeit. Sie hat entschieden, einen alternden Warenkorb nicht länger zu flicken und stattdessen einen modernen Shop zu besitzen.

So läuft der Umzug. Der saubere Teil kommt zuerst und beruhigt alle. Ein voller Datenbankauszug, und daraus bilden sich die 1.800 Produkte mit ihren Größen, Preisen, Beständen und Bildern über ein paar Wochen sorgfältigen Abgleichs auf den Solidus Katalog ab. Die Kundendaten, Großkundenkonten inklusive, kommen mit Adressen und Bestellhistorie herüber, Passwörter ausgenommen. Die Bestellhistorie wird als nur lesbare Referenz hereingeholt, drei Jahre tief, die älteren Datensätze bleiben im archivierten Export. Die URL Schlüsselwörter werden direkt aus der Datenbank in den ersten Entwurf der Weiterleitungsliste gelesen, rund 3.000 Zeilen, die dann eine Person von Hand prüft.

Dann die harten Teile, die in Woche eins angesprochen wurden, nicht in Woche zehn. Die undokumentierten Händlerpreise werden durch Lesen des Add ons und der Daten rückentwickelt und als echte, getestete Funktion des neuen Shops neu gebaut statt als Flicken. Die Zahlungen sind der Dreh und Angelpunkt. Der alte monatliche Teeclub läuft über ein altes Modul, dessen Anbieter die wiederkehrenden Mandate nicht sauber übergeben kann, der ehrliche Plan wird also früh vereinbart: neue Abos starten vom ersten Tag an beim neuen Anbieter, und bestehende Mitglieder werden einmal, mit Vorlauf, um neue Zustimmung gebeten, mit einer kurzen Schonfrist, damit niemand abgeschnitten wird. Kartenzahlungen ziehen auf das eigene Konto des Shops bei einem modernen Anbieter, damit gewöhnliche gespeicherte Karten nicht gestört werden. Vierzehn Wochen nach dem ersten Workshop geht das Grazer Teehaus an einem ruhigen Dienstagvormittag im schwächsten Monat live, lässt die alte Zen Cart Installation dreißig Tage unberührt als Rückfalloption laufen und legt sie erst dann still. Ein Jahr später ist der Shop eine gepflegte Anwendung auf einer unterstützten Sprache, mit Tests, ohne Forums Add ons, die sich ständig vertragen müssen, und mit den Großkundenregeln dort aufgeschrieben, wo die nächste Person sie lesen kann.

Der ehrliche Umzugsplan

Auf das Wesentliche heruntergebrochen läuft das Verlassen von osCommerce oder Zen Cart hin zu einem eigenen Solidus Shop so. Erstens, die Erkundung: liste jedes Add on und jede Templateänderung und schreibe auf, was jedes wirklich tut, wähle den Zahlungsanbieter, kläre, wie etwaige Abos behandelt werden, und benenne die eine Person im Betrieb, der die Daten gehören. Zweitens, der Bau: stelle den Solidus Shop auf, schreibe die Importskripte und lass sie wieder und wieder gegen eine Kopie der echten Datenbank laufen, bis der Import langweilig ist. Drittens, ordne Katalog und Kunden zu und mach aus der verborgenen Add on Logik getestete Funktionen. Viertens, baue die Weiterleitungsliste aus den Tabellen der URL Schlüsselwörter und prüfe jede Zeile. Fünftens, ein Parallelbetrieb von ein paar Wochen mit eingefrorenem Katalog, mit zwei Proben des finalen Imports. Sechstens, geh an einem ruhigen Wochentagvormittag live, gib eine echte Testbestellung auf jeder Zahlungsart auf, prüfe die wichtigsten Weiterleitungen von Hand und halte den alten Shop dreißig Tage als Rückfalloption, bevor du irgendetwas stilllegst.

Durch das Ganze zieht sich das Prinzip aus der Säule: zieh den Shop so um, wie er ist, mach ihn stabil, und verbessere ihn erst dann. Eine Migration zugleich zu einem Redesign zu machen, verdoppelt das Risiko und macht es unmöglich zu sagen, welche Änderung einen Einbruch verursacht hat. Hier gehört auch die Geldfrage hin, und die Gesamtkosten über fünf Jahre rechnen das ehrlich durch, während der Plattformvergleich den eigenen Weg neben die gemieteten stellt.

Wann du bleiben solltest

Mir ist lieber, ich verliere die Arbeit, als dir einen Umzug zu verkaufen, den du nicht brauchst, hier also, wann du bleiben solltest. Bleib, wenn dein osCommerce oder Zen Cart Shop klein ist, die Add ons, von denen du abhängst, wenige und noch gepflegt sind, dein Hoster die PHP Version, die du fährst, noch unterstützt, und die Rechnung tragbar ist. Bleib, wenn dich wirklich nichts blockiert und die einzige Klage ein vages Gefühl ist, dass die Software alt ist. Bleib, wenn du die Person im Betrieb nicht benennen kannst, die die Daten versteht, die Händlerregeln und warum die alten Produktcodes ihre Zusätze tragen, denn ohne diese Person bringt jede Migration, auf jede Plattform, einen hübschen neuen Shop voller falscher Daten hervor. Gerade ein Zen Cart Shop, aktuell gehalten auf einer unterstützten PHP Version, kann noch eine ganze Weile ein durchaus vernünftiger Ort zum Bleiben sein.

Wechsle, wenn der Stapel an Add ons zur Steuer und zum Risiko geworden ist, wenn dein Hoster die PHP Version abschaltet, die der Shop braucht, und das Update so viel kostet wie ein Neustart für nichts Neues, wenn die Regeln, die dein Geschäft steuern, in Modulen gefangen sind, die niemand lesen kann, wenn die Entwickler, die deinen Aufbau kennen, schwer zu finden geworden sind, und wenn du einen Shop willst, der dir ganz gehört, auf einem unterstützten Stack, der sich ordentlich testen lässt. Wem deine Geschäftsdaten eigentlich gehören ist das Prinzip darunter. Wenn du im selben Atemzug andere selbst gehostete Warenkörbe abwägst, habe ich denselben ehrlichen Leitfaden für den Abschied von OpenCart und für den Abschied von PrestaShop geschrieben.

Der Workshop

Wenn du einen osCommerce oder Zen Cart Shop betreibst und nicht sicher bist, ob du ihn endlich entwachsen bist, bring ihn in einen kostenlosen Workshop, und die ersten zwei Wochen Arbeit gehen auf mich. Bring deine Add on Liste, alles, was dir dein Hoster über PHP gesagt hat, und alles, was du über die Templateänderungen und die undokumentierten Module weißt. Gemeinsam lesen wir, was der Shop wirklich tut, arbeiten heraus, was sauber wandert und was neu gebaut werden muss, markieren die Zahlungs und Abofragen zuerst, und ich sage dir ehrlich, ob sich ein Umzug für dich lohnt. Manchmal lohnt er sich nicht, und dann sage ich das.

Footnotes

1. osCommerce, official project site (osCommerce V4 runs on PHP 8.3 with support from PHP 7.4 and MariaDB 10.x, described as a free open source shopping cart, with the project history dated from 2000), checked 14 November 2026, https://www.oscommerce.com/ ↩ ↩²

2. Zen Cart, encyclopaedia overview confirming Zen Cart is a software fork that branched from osCommerce in 2003 and is written in PHP, Wikipedia, checked 14 November 2026, https://en.wikipedia.org/wiki/Zen_Cart ↩

3. Zen Cart, licence file (GNU General Public License version 2), GitHub, checked 14 November 2026, https://github.com/zencart/zencart/blob/master/license.txt ↩

4. Solidus, the open source ecommerce framework on Ruby on Rails under the BSD 3 clause licence, GitHub, checked 14 November 2026, https://github.com/solidusio/solidus ↩ ↩²

5. Zen Cart documentation, EasyPopulate (an add on from the Plugins Library, alongside DbIo, that imports and exports product data as CSV files, keyed on the model number of each product), checked 14 November 2026, https://docs.zen-cart.com/user/products/easypopulate/ ↩

6. Zen Cart source, includes/functions/password_funcs.php (zen_encrypt_password returns password_hash with PASSWORD_DEFAULT, which currently resolves to bcrypt, with a salted scheme in older code), GitHub, checked 14 November 2026, https://github.com/zencart/zencart/blob/master/includes/functions/password_funcs.php ↩

7. PHP, Supported Versions (each PHP release line receives active and then security support on a published schedule, after which it is end of life and receives no further fixes), checked 14 November 2026, https://www.php.net/supported-versions.php ↩

8. Zen Cart documentation, Server Requirements (Zen Cart v2.2.x is designed for PHP 8.2 through PHP 8.5, with MySQL 5.7.8 or newer or MariaDB 10.2.7 or newer), checked 14 November 2026, https://docs.zen-cart.com/user/first_steps/server_requirements/ ↩

9. Zen Cart, README and release log (v2.2.2 released 4 April 2026, v2.2.1 on 20 March 2026 and v2.1.0 on 23 November 2024; Zen Cart described as the first open source ecommerce web application to be fully certified under the card industry payment application security standard), GitHub, checked 14 November 2026, https://github.com/zencart/zencart/releases ↩

10. osCommerce, Online Merchant repository (the self hosted PHP and MySQL shop, with the classic 2.3.4.1 stable release dating to 2017 and a separate modern rewrite), GitHub, checked 14 November 2026, https://github.com/osCommerce/oscommerce2 ↩