Von Luma auf Hyvä migrieren: typische Stolperfallen
Von Luma auf Hyvä migrieren: typische Stolperfallen
~8 Min. Lesezeit Zuletzt aktualisiert am 9. August 2026
Ein bestehendes Luma-Projekt auf Hyvä umzustellen ist kein einfaches Theme-Wechseln - es ist praktisch ein Frontend-Neubau. Dieses Kapitel sammelt die wichtigsten Stolperfallen für Entwickler, die diesen Umstieg vor sich haben.
Kein 1:1-Template-Mapping
Ein Luma-.phtml-Template lässt sich nicht einfach kopieren und leicht anpassen - Knockout-Bindings (data-bind), ko_template-Referenzen und RequireJS-Modulverweise haben in Hyvä schlicht keine Entsprechung. Realistisch ist ein Neuschreiben jedes angepassten Templates nach Hyvä-Konventionen (Kapitel 6-9), nicht ein Migrations-Skript.
Eigene Luma-Erweiterungen und Drittanbieter-Module prüfen
Vor der Migration lohnt sich eine Bestandsaufnahme: Welche eigenen Luma-Templates/Blocks existieren, und welche Drittanbieter-Erweiterungen bringen eigenes Frontend mit? Nicht jedes Magento-Modul unterstützt Hyvä von Haus aus - manche brauchen ein separates Hyvä-Kompatibilitätsmodul (oft von der Hyvä-Community oder dem Hersteller selbst bereitgestellt), andere müssen komplett neu für Hyvä gebaut werden.
Achtung: Ein häufiger Migrationsfehler: Man aktiviert Hyvä produktiv, ohne vorher zu prüfen, ob geschäftskritische Drittanbieter-Erweiterungen (Payment-Provider, Fracht-Rechner, individuelle Checkout-Erweiterungen) überhaupt eine Hyvä-Version haben. Das führt im schlimmsten Fall zu einem kaputten Checkout in Produktion.
Schrittweise Migration vs. "Big Bang"
Ein kompletter Umbau in einem einzigen Deployment ist riskant und schwer zu testen. Sinnvoller ist häufig eine schrittweise Migration: zuerst eine Staging-Umgebung mit Hyvä parallel zur produktiven Luma-Seite aufsetzen, Seite für Seite (Startseite, Kategorieseite, Produktseite, Checkout) migrieren und testen, und erst am Ende komplett umschalten.
CSS und JavaScript komplett neu denken
LESS-Dateien aus Luma lassen sich nicht automatisch in Tailwind-Klassen übersetzen - das ist im Kern eine komplette Neugestaltung des Stylings, keine Migration im technischen Sinne. Der Vorteil dabei: Es ist die ideale Gelegenheit, gewachsenen, unübersichtlichen LESS-Code hinter sich zu lassen und mit einer sauberen, konsistenten Design-Token-Struktur neu zu starten (Kapitel 12).
Teamwissen aufbauen, bevor die Migration beginnt
Da Hyvä-Entwicklung sich fundamental von Luma-Entwicklung unterscheidet (kein Knockout, keine UI-Components, Tailwind statt LESS, Alpine statt jQuery), lohnt es sich, dass das Entwicklungsteam die Grundlagen dieser Serie (Block 1-4) tatsächlich durcharbeitet, bevor die eigentliche Migration beginnt - Zeitdruck während einer laufenden Migration ist der denkbar schlechteste Moment, neue Konzepte zum ersten Mal zu lernen.
Tipp: Ein gutes erstes Migrationsprojekt zum Üben: eine einzelne, unabhängige Seite (wie die Team-Seite aus Kapitel 17-22 dieser Serie) komplett neu in Hyvä bauen, bevor man sich an geschäftskritische Seiten wie Checkout oder Produktseite wagt.