Am 26. November 2025 hat OXID eine E-Mail an alle Shopbetreiber verschickt. Darin heißt es, die Umstellung von Smarty auf Twig sei mit einem Migrationstool weitgehend automatisiert, der Aufwand liege bei „etwa einem halben Tag“. Auch die Datenbankmigration sei laut der E-Mail kaum der Rede wert.
Die Botschaft: Migration klingt groß, ist aber eigentlich klein. Keine Sorge, das geht schnell.
Und genau das hat viele Betreiber professioneller OXID-Shops verunsichert.
Denn wer seit Jahren mit OXID arbeitet, Entwicklungen begleitet, individuelle Templates pflegt, ERP-/CRM-Systeme angebunden oder Marktplatzintegrationen im Einsatz hat, weiß: Eine Migration ist selten ein technischer Schnellläufer. Und wenn kommuniziert wird, tiefgreifende strukturelle Änderungen seien innerhalb weniger Stunden erledigt, entsteht – unbeabsichtigt – eine Lücke zwischen Marketing und Realität.
Wir möchten hier etwas klarstellen, bevor Missverständnisse größer werden: Agenturen und Dienstleister sind keine Gegner, sondern die verlängerte technische Hand des Shopbetreibers. Wenn die Komplexität gewachsener OXID-Systeme unterschätzt wird, entsteht ungewollt Misstrauen. Und genau das schadet den Unternehmen, die sich auf fundierte Beratung verlassen müssen. Deshalb ist Transparenz jetzt wichtiger denn je.
Vom Open-Source-Projekt zur Enterprise-Plattform
Mit OXID 7 kommen drei Parallel-Umstellungen zusammen, die in der Praxis nicht voneinander zu trennen sind:
1. Smarty wird durch Twig ersetzt
Die Template-Engine – also die „Sprache“ des Frontends – wird komplett ausgetauscht. Smarty und Twig funktionieren unterschiedlich und sind nicht kompatibel.
Alles, was bisher in Smarty geschrieben wurde (Templates, Logik im Frontend, CMS-Inhalte), muss auf Twig übertragen werden.
2. Das neue APEX Theme löst Flow und Wave ab
Flow (Bootstrap 3, Smarty) und Wave (Bootstrap 4, Smarty) waren die etablierte Basis vieler Child-Themes. APEX ist ein Neuanfang: Bootstrap 5, neue Strukturen, neue Blocknamen, neue HTML-Architektur, Twig statt Smarty.
Ein Flow- oder Wave-Child-Theme kann nicht weiterverwendet werden. Es braucht ein neues Child-Theme auf Basis von APEX.
3. Module müssen aktualisiert oder ersetzt werden
Viele Module greifen direkt in Templates, Checkout oder Navigation ein. Zahlreiche Module basieren noch auf Smarty oder Flow/Wave-Strukturen.
Mit APEX und Twig müssen diese Module aktualisiert oder neu entwickelt werden – oder durch Alternativen ersetzt werden.
Diese drei Umstellungen greifen ineinander. Und genau deshalb ist die Migration nicht trivial.
Was das Migrationstool wirklich kann – und was nicht
OXID beschreibt das Migrationstool als Lösung, die „den größten Teil der Aufgaben wegautomatisiert“. In Wahrheit übernimmt das Tool vor allem eines:
- Es übersetzt Syntax.
- Nicht Architektur.
- Nicht Layout.
- Nicht Geschäftslogik.
Das Tool wandelt Smarty-Ausdrücke wie [{if}], [{foreach}] oder [{include}] in ihre Twig-Gegenstücke um. Und es kann Smarty-Code in CMS-Seiten und Artikelbeschreibungen konvertieren.
Das spart Zeit – ohne Frage.
Aber das Tool weiß nicht:
- wie APEX aufgebaut ist,
- welche Blöcke ersetzt wurden,
- welche Module in welches Template eingreifen,
- wo individuelle Logik im Frontend sitzt,
- wie das Layout am Ende aussehen soll.
Die von OXID dokumentierten Known issues – fehlendes |raw, übrig gebliebene $-Zeichen, fehlerhaftes Escaping oder Probleme bei Array-Ausdrücken – bestätigen das.
Die OXID-Community beschreibt es sehr treffend:
Der Converter liefert etwa „80–90 % technische Konvertierung“, aber keinerlei strukturelle oder funktionale Migration.
Was am Ende entsteht, ist ein sinnvoller Rohling – kein fertiges Twig-Theme.
Warum Flow und Wave nicht zu APEX passen – und warum es wichtig ist, das zu verstehen
Über die Jahre haben sich Flow und Wave als Basis für Child-Themes etabliert. Viele Shops sind so entstanden: Das offizielle Parent-Theme wird erweitert, überschrieben und sukzessive weiterentwickelt. Doch Flow und Wave unterscheiden sich bereits voneinander, und beide sind konzeptionell nicht mit APEX vereinbar.
Wer ein Flow-basiertes Custom-Theme betreibt, nutzt:
- Bootstrap 3 als HTML-/CSS-Basis
- Smarty-Templates
- Flow-spezifische Blocknamen
- Flow-spezifische Includestrukturen
- Modulabhängige Layout-Erweiterungen
APEX dagegen verwendet:
- Bootstrap 5
- Twig
- Neue Blocknamen
- Neue Template-Hierarchien
- Neue Markup-Struktur
Ein Child-Theme kann nicht Twig aus APEX erben und gleichzeitig Layoutteile aus Flow referenzieren. Deshalb ist die Migration von Flow-Templates nach Twig nur der erste Schritt. Die eigentliche Aufgabe besteht darin, diese Templates in die APEX-Architektur einzubetten – und das ist eine gestalterische und strukturelle Aufgabe, kein rein technisches Umschreiben.
Warum das Thema Module für viele Shops geschäftskritisch ist
Ein weiterer Punkt, der in der OXID-Mail nur indirekt angesprochen wurde, betrifft die Modullandschaft. Für viele Shops sind Module weit mehr als technische Erweiterungen. Sie sind betriebsnotwendig. Ohne funktionierende Module gibt es keine Anbindung an Marktplätze wie Amazon, keine Sichtbarkeit auf eBay, keine reibungslose Warenwirtschaftskommunikation, keine unternehmenskritischen B2B-Funktionen und keine stabile Payment-Infrastruktur.
Gerade diese Module wurden über Jahre entwickelt, erweitert und tief in Shopprozesse integriert. Viele davon stammen von Drittanbietern, manche werden aktiv gepflegt, andere nicht. Und viele basieren vollständig auf Smarty und den Strukturen des Flow- oder Wave-Themes. Mit OXID 7 und APEX ändern sich jedoch nicht nur Template-Sprache und Theme-Struktur, sondern auch die Art und Weise, wie Module technisch eingebettet werden.
Das bedeutet: Selbst wenn das eigentliche Theme sauber nach Twig migriert ist, bleibt die Frage offen, ob jedes Modul — insbesondere jene, die für den Umsatz entscheidend sind — rechtzeitig und korrekt für OXID 7 aktualisiert wird. Eine Amazon-Anbindung, die auf ein altes Layout setzt, ist nicht durch ein Syntax-Tool reparierbar. Und ein Zahlungsmodul, das in der neuen Checkout-Struktur nicht greift, blockiert unmittelbar Bestellprozesse.
OXID hat in der E-Mail neue Begriffe eingeführt wie „OPAL“, „OPAL hq“ oder den „OXID Project Accelerator“, die suggerieren, dass ältere Module durch moderne Alternativen ersetzt werden können. Das ist grundsätzlich ein sinnvoller Schritt, weil es die Abhängigkeit von verwaisten Modulen senkt. Aber diese OPAL-Module decken bei weitem nicht alle Marktplatz- oder ERP-Anbindungen ab — und sie ersetzen nicht die Integrationen, die für viele Shops seit Jahren spezifisch entwickelt wurden.
UPDATE: Ergänzender Blogbetrag zum Thema Modulentwicklung und OPAL.
Mit anderen Worten: Die Modulwelt bleibt ein zentraler Faktor der Migration. Sie bestimmt in vielen Fällen den Gesamtaufwand stärker als die eigentliche Template-Umstellung. Und diese Realität lässt sich nicht innerhalb eines halben Tages „wegautomatisieren“. Sie verlangt sorgfältige Prüfung, Abstimmung mit Modulanbietern und, wenn nötig, gezielte Neuentwicklung.
Gerade deshalb braucht es hier Transparenz: Betreiber müssen wissen, welche ihrer Module kompatibel sind, welche aktualisiert werden können und wo Alternativen entstehen. Und Dienstleister müssen diese Abhängigkeiten ehrlich kommunizieren, damit Entscheidungen nicht auf Annahmen basieren, sondern auf Fakten. Denn am Ende hängt hier nicht nur Technik, sondern Umsatz dran.
Warum diese Fakten so wichtig sind
Wenn ein Shop über Jahre gewachsen ist, greifen Layout, Module, Integrationen und CMS-Inhalte ineinander. Der Shop ist kein Demosystem – er ist ein operatives System, das täglich Umsatz generiert.
Darum ist es gefährlich, wenn der Eindruck entsteht, eine Migration sei in wenigen Stunden erledigt. Die Folge ist eine Frage, die aktuell viele Dienstleister hören:
Warum braucht unsere Agentur zwei oder drei Monate, wenn der Hersteller sagt, es geht in einem halben Tag?
Diese Frage erzeugt Spannung, wo eigentlich Vertrauen notwendig wäre. Niemand kann ehrliche Planung leisten, wenn unterschiedliche Erwartungshorizonte nebeneinander existieren. Die Wahrheit ist: Agenturen und Dienstleister profitieren nicht von komplizierten Migrationen. Im Gegenteil – sie wollen reibungslose Abläufe und nachvollziehbare Prozesse.
Was sie aber auch leisten müssen, ist Verantwortung: Risiken minimieren, Kompatibilität sicherstellen, Module prüfen, Layouts sauber migrieren, Integrationen stabil halten, Tracking, SEO, Checkout – all das sind nicht optionalen Extras, sondern zwingende Voraussetzungen.
Nur wenn Shopbetreiber verstehen, wie tiefgreifend OXID 7 eingreift, können beide Seiten – Betreiber und Dienstleister – auf Augenhöhe planen.
Ein realistischer Blick auf die Migration
Die Migration auf OXID 7 ist kein Schnellschuss – aber sie ist ein planbares Projekt. Twig als Template-Engine, Bootstrap 5 und APEX als Theme-Basis sind moderne, zukunftssichere Technologien. Sie verbessern Struktur, Wartbarkeit und langfristige Stabilität.
Der richtige Weg ist ein kontrolliertes Vorgehen:
- Analyse der bestehenden Themes
- Bewertung der Module
- Nutzung des Converters als Werkzeug, nicht als Lösung
- Proof-of-Concept auf APEX
- Schrittweise Überführung der wichtigsten Seiten
- Intensive Tests
- Und schließlich ein sauber geplanter Go-live
So entsteht eine moderne, saubere Basis für die kommenden Jahre – und ein System, das wieder gut wartbar und erweiterbar ist.
Fazit
OXID 7 ist ein großer Schritt vorwärts – technisch und architektonisch. Doch jeder große Schritt verlangt Orientierung. Marketing soll Mut machen, aber Migration verlangt Pragmatismus und ehrliche Worte. Agenturen sind Partner in diesem Prozess, keine Antagonisten. Wer sich aufeinander verlassen kann, hat eine solide Basis für die kommenden Jahre.
Die gute Nachricht:
Der Umstieg ist machbar.
Aber er ist kein „halber Tag“.
Er ist ein Neuanfang auf moderner Grundlage – und genau das macht ihn wertvoll.