Was maßgeschneidert sein musste, und warum.
Der Katalog eines Wellness-Retreat-Betreibers passt nicht in E-Commerce-Standards. Ein Retreat ist kein Produkt — es ist ein datumsgebundenes Bundle, das Unterkunft, Verpflegung und Unterricht zu einer einzigen kaufbaren Einheit kombiniert. Der leitende Lehrende ist kein Produktautor; er ist der Grund, aus dem ein Gast bucht. Das Sanskrit-Vokabular und die Philosophie-Module der Marke sind kein Blog; sie sind eine Inhaltsschicht, die neben dem Storefront steht und der Kaufentscheidung ihren Kontext gibt.
Wir bauten die Plattform Ende 2018 auf PrestaShop 1.7.4, mit vier domänenspezifischen Modulen und einem stark angepassten Standard-Theme. Das Retreat-Bundles-Modul modellierte Angebote mit mehreren Terminen und Komponenten samt Datumsauswahl und Komponentenkonfiguration — nichts im PrestaShop-Ökosystem kam dem nahe. Das Sanskrit-Lernmodul hatte eigene Datenbanktabellen, Frontend-Routen und ein Admin-Panel: eine Vokabel- und Philosophie-Oberfläche, die der Betreiber unabhängig vom Katalog bearbeiten konnte. Ein Reseller-Modul verwaltete B2B-Partneragenturen mit Kontakt-, Länder- und Währungsdatensätzen.
Der Checkout-Ablauf wurde überschrieben — 67 Klassen- und Controller-Overrides auf dem Höhepunkt — weil Retreat-Käufe andere Validierungsregeln haben als Checkouts für physische Waren. Man kann keine zwei Plätze bei einem Retreat buchen, ohne Termine auszuwählen. Man kann kein Komponentenfeld leer lassen und zur Zahlung fortschreiten.
Kleine Dinge, die die Plattform am Leben hielten.
Die Jahre zwei bis sechs waren nicht dramatisch. Wechsel der Zahlungsanbieter. DSGVO-Anpassungen. Ergänzungen von Versanddienstleistern. PHP-Laufzeit-Upgrades, über die gesamte Zusammenarbeit hinweg eingearbeitet. Gelegentlich neue Texte, neue Retreat-Formate, neue B2B-Partner, über das Reseller-Modul angebunden. Die Art Wartung, die keine Projektseite hervorbringt, aber der eigentliche Inhalt einer siebenjährigen Zusammenarbeit ist.
Die meisten maßgeschneiderten Plattformen überleben diese Phase nicht. Das Team, das sie gebaut hat, ist weitergezogen. Die Module sind undokumentiert. Die Klassen-Overrides sind rätselhafter Code. Jede Anhebung einer Abhängigkeit ist ein Würfelwurf.
Die Plattform überlebte, weil dieselben Menschen an ihr arbeiteten. Als ein Wechsel des Zahlungsanbieters Änderungen am Checkout-Override erforderte, nahm der Ingenieur, der den Override geschrieben hatte, die Änderung vor. Als ein PHP-Laufzeit-Upgrade zwei Modulkonstruktoren brach, wussten wir, welche Konstruktoren zu prüfen waren. Institutionelles Wissen über eine Codebasis hat einen kumulierenden Wert, der erst dann zutage tritt, wenn etwas bricht — und irgendwann bricht immer etwas.
- F · 01Retreat-Bundle-Produkttyp
- Datumsgebundene Bundles mit mehreren Komponenten (Unterkunft, Verpflegung, Unterricht), modelliert in einem benutzerdefinierten PrestaShop-Modul. Kein Standard-Äquivalent.
- F · 02Sanskrit-Lerninhaltsschicht
- Getrennt von Storefront und Blog: eigene Datenbanktabellen, Frontend-Routen und ein Admin-Panel für Vokabel- und Philosophie-Inhalte.
- F · 03B2B-Reseller-Schicht
- Verwaltung von Partneragenturen mit Kontakt-, Länder- und Währungsdatensätzen. Buchungen über das Reseller-Modul geroutet, ohne den öffentlichen Storefront-Ablauf zu berühren.
- F · 04Angepasster Checkout-Ablauf
- 67 Klassen- und Controller-Overrides auf dem Höhepunkt, die retreat-spezifische Validierungsregeln modellieren — Datumsauswahl, Komponentenkonfiguration — die der Standard-Checkout nicht erzwingt.
- F · 05Kontinuierliche Wartung
- Sieben Jahre Wechsel der Zahlungsanbieter, DSGVO-Anpassungen, Versand-Updates und PHP-Laufzeit-Upgrades — alles vom Team abgewickelt, das die ursprünglichen Module geschrieben hat.
- F · 06Laufende Hauptversions-Migration
- PrestaShop 1.7.4 → 1.7.8.11 in Produktion abgeschlossen; 1.7.8.11 → 8.2.3 im späten Staging. Jeder Override erneut getestet, jedes Modul mit einem PHP-8.x-Kompatibilitätsdurchgang versehen. Die Migration ist die Arbeit, die die Betreuung verdient.
Die Migration, die gerade läuft.
Das End-of-Life von PrestaShop 1.7 erzwang 2025 eine Entscheidung: replattformieren oder migrieren. Replattformieren bedeutet, sieben Jahre domänenspezifischer Modularbeit wegzuwerfen und auf einem neuen Stack von vorn zu beginnen. Wir argumentierten für die Migration. Der Betreiber stimmte zu.
Die Migration läuft in zwei Stufen. Die erste — PrestaShop 1.7.4 → 1.7.8.11 — wurde früher abgeschlossen und ist in Produktion. Die zweite — 1.7.8.11 → 8.2.3 — ist der schwierigere Sprung: PrestaShop 8 verlagerte mehr Views nach Twig und änderte das Override-System so weit, dass alle 67 Klassen- und Controller-Overrides erneut getestet oder refaktoriert werden müssen. Jedes benutzerdefinierte Modul braucht einen PHP-8.x-Kompatibilitätsdurchgang.
Allein der Oktober 2025 brachte 245 Commits auf dem 8.2.3-Migrationsbranch hervor. Die Arbeit läuft in einer abgezweigten Staging-Umgebung mit gespiegelten Produktionsdaten. Jeder Checkout-Ablauf, jede Retreat-Bundle-Konfiguration, jede Sanskrit-Inhaltsroute wird gegen die neue Version getestet, bevor das Umstellungsfenster geöffnet wird. Die Migration ist methodisch und langsam, weil der Audit-Trail, den sie hinterlässt, ebenso sehr zählt wie der aktualisierte Code.
Der Grund, warum die Migration möglich ist — und im Budget bleibt — ist, dass das Team, das sie durchführt, die ursprünglichen Module geschrieben hat. Wir haben die Komplexität nicht entdeckt; wir besaßen sie bereits.
Das Argument, für das Upgrade beim selben Team zu bleiben.
Sieben Jahre. Durchgehend ein Team. Eine Hauptversions-Migration derzeit im späten Staging-Stadium.
Die heute in Produktion laufende Plattform läuft auf PrestaShop 1.7.8.11 mit dem Retreat-Bundles-Modul, der Sanskrit-Lernoberfläche, der B2B-Reseller-Schicht und dem angepassten Checkout-Ablauf — alles intakt. Der 8.2.3-Branch ist der nächste Schritt — die Migration, die sich dagegen sträubt, als Ein-Wochen-Sprint behandelt zu werden, und der Teil, den am Anfang einer Engagement mit maßgeschneiderter Plattform niemand einplant.
Der Wert einer langen Zusammenarbeit an einer maßgeschneiderten Plattform liegt nicht im ersten Bau. Die erste Version kann jeder bauen. Der Wert ist angesammelter Kontext: zu wissen, welcher Override tragend ist, welche Modulannahme unter einer neuen Framework-Version zerspringen wird, von welcher PHP-Klasse der Zahlungsschritt auf eine Weise abhängt, die die Dokumentation nicht erwähnt. Dieser Kontext überträgt sich in einem Migrations-Briefing nicht auf ein neues Team. Er lebt in den Menschen, die den Code geschrieben haben. Die Migration, die jetzt im Staging ist, ist möglich — und überlebbar — weil dasselbe Team den ursprünglichen Code besitzt.
Sie haben die Module geschrieben. Sie waren das richtige Team, um sie zu migrieren.