Hyvä läuft jetzt nativ auf Magento 2.4.9 und auf Mage-OS. Wir haben beides getestet. Was das für Ihren Shop bedeutet →
Kurz gesagt
Bevor Sie eine Hyvä-Migration planen, erfassen Sie jede Extension und ordnen Sie sie einer von drei Gruppen zu: funktioniert auf Hyvä, braucht eine Frontend-Portierung oder sollte weg. Achten Sie besonders auf Zahlungs-, Tracking- und Checkout-Module, denn sie gehen am häufigsten kaputt. Die Extension-Liste bestimmt Umfang, Risiko und Zeitplan des gesamten Projekts.
Eine Migration von Luma zu Hyvä ändert nur das Frontend. Ihre Produkte, Kunden und Bestellungen bleiben, wo sie sind.


Das klingt nach einem einfachen Projekt, und in vieler Hinsicht ist es das auch. Doch fast jeder Magento-Shop nutzt Extensions, die für Luma geschrieben wurden – und diese Extensions entscheiden, wie reibungslos der Umstieg verläuft.
Das ist die Checkliste, die wir vor dem Start jedes Hyvä-Projekts verwenden.
Warum Extensions zuerst kommen
Hyvä entfernt den RequireJS-, KnockoutJS- und jQuery-Stack von Luma. Jede Extension, die eigenes Storefront-JavaScript oder Knockout-Templates mitbringt, setzt diesen Stack voraus.
Auf Hyvä funktioniert der Backend-Teil einer solchen Extension weiterhin. Der Teil, den Kunden sehen – etwa ein Widget, ein Pop-up oder ein Checkout-Schritt –, funktioniert erst, wenn sein Frontend neu gebaut wurde.
Entdecken Sie das mitten im Projekt, kostet es Zeit und bringt Risiken mit sich. Entdecken Sie es am ersten Tag, wird es einfach Teil des Plans.
Schritt 1: Erfassen Sie jedes Modul
Beginnen Sie mit einer vollständigen Liste. Verlassen Sie sich nicht auf Ihr Gedächtnis oder das Admin-Menü, denn viele Module haben überhaupt keine Admin-Oberfläche.
bin/magento module:status --enabled | grep -v '^Magento_'
composer show | grep -v '^magento/'Der erste Befehl listet aktivierte Module auf, die nicht zum Magento-Core gehören. Der zweite listet die Composer-Pakete auf, sodass Sie Anbieter und Version jedes Moduls finden.
Prüfen Sie außerdem app/code auf individuelle und ältere Module, die ohne Composer installiert wurden. Oft sind es genau die, an die sich niemand mehr erinnert.
Schritt 2: Klären Sie, was jedes Modul in der Storefront tut
Beantworten Sie für jedes Modul eine Frage: Verändert es etwas, das ein Kunde sieht oder anklickt?
- Reine Backend-Module wie ERP-Konnektoren, Bestellexporte, Feeds oder Admin-Tools funktionieren auf Hyvä in der Regel ohne Änderungen.
- Module mit Storefront-Templates, JavaScript oder Layout-Änderungen verdienen einen genaueren Blick.
- Module, die den Checkout berühren, verdienen den genauesten Blick von allen.
Storefront-Code erkennen Sie schnell, wenn Sie in jedem Modul nach einem view/frontend Ordner suchen mit web/js, requirejs-config.js oder Knockout .html Templates.
Schritt 3: Ordnen Sie jedes Modul einer von drei Gruppen zu
Wir ordnen jede Extension einer von drei Gruppen zu und teilen die vollständige Liste mit dem Shopbetreiber.
| Gruppe | Bedeutung | Typische Maßnahme |
|---|---|---|
| Funktioniert | Nur Backend, oder es gibt bereits ein Hyvä-Kompatibilitätsmodul | Bei Bedarf das Kompatibilitätsmodul installieren, dann testen |
| Muss portiert werden | Hat Luma-Frontend-Code und kein fertiges Kompatibilitätsmodul | Den Frontend-Teil in Alpine.js und Tailwind neu bauen |
| Sollte weg | Ungenutzt, doppelt vorhanden oder durch etwas Besseres ersetzt | Entfernen oder durch ein Hyvä-fähiges Modul ersetzen |
Viele bekannte Anbieter veröffentlichen eigene Hyvä-Kompatibilitätsmodule. Hyvä pflegt außerdem einen öffentlichen Tracker für Kompatibilitätsmodule – eine gute erste Anlaufstelle.
Für die Module, die in der mittleren Spalte landen, erklärt unser Beitrag über Extensions ohne Hyvä-Kompatibilitätsmodul die Optionen im Detail.
Schritt 4: Prüfen Sie die Hochrisiko-Kategorien
Unserer Erfahrung nach gehen einige Arten von Modulen häufiger kaputt als andere. Planen Sie für sie im Audit mehr Zeit ein.
- Zahlungsarten. Viele Zahlungsmodule rendern ihren Checkout-Schritt mit Knockout. Für manche Anbieter gibt es überhaupt keine Hyvä-fähige Version.
- Tracking und Tag-Manager. Viele Module senden E-Commerce-Events über RequireJS. Auf Hyvä können diese Events unbemerkt ausbleiben, sodass GA4-Berichte ohne Fehlermeldung verstummen.
- Slider, Galerien und Produktkonfiguratoren. Das sind oft schwere jQuery-Widgets.
- Theme-spezifische Page-Builder-Elemente. Inhalte, die mit eigenen Elementen Ihres alten Themes erstellt wurden, können nach dem Wechsel verschwinden.
- Suche und Layered Navigation. Diese haben oft eigene Frontend-Skripte.
Schritt 5: Entscheiden Sie früh über den Checkout
Im Checkout treffen Zahlungs-, Versand- und Tracking-Module aufeinander. Hier sollte eine Entscheidung fallen, bevor die Designarbeit beginnt.
- Hyvä Checkout auf Basis von Magewire, wenn Ihre Zahlungs- und Versandarten unterstützt werden oder sich integrieren lassen.
- Den Checkout vorerst mit dem Fallback-Ansatz von Hyvä auf Luma belassen, während der Rest des Shops zu Hyvä wechselt.
- Ein Checkout-Template, zugeschnitten auf Ihre Warenkorbgröße und Ihre Märkte.
Planen Sie auch die Content Security Policy ein. Seit Magento 2.4.7 erzwingen Checkout-Seiten eine strenge CSP, daher muss jedes Inline-Skript freigegeben sein, sonst können Zahlungsarten ausfallen.
Unser Artikel Lohnt sich Hyvä Checkout? hilft Ihnen bei dieser Entscheidung.
Schritt 6: Schützen Sie SEO und Tracking
Eine Änderung am Frontend sollte nicht verändern, wie Google oder Ihre Analytics den Shop sehen. Nehmen Sie diese Punkte in die Checkliste auf:
- Behalten Sie jede URL bei, auch die Kategorie- und Produkt-URLs.
- Vergleichen Sie gerenderte Titel, Meta-Descriptions, Canonical-Tags und hreflang zwischen alten und neuen Seiten.
- Vergleichen Sie die strukturierten Daten für Produkte, Breadcrumbs und Organisation.
- Testen Sie GA4-E-Commerce-Events durchgängig: Artikel ansehen, in den Warenkorb legen, Checkout beginnen und Kauf.
- Beobachten Sie die Search Console nach dem Launch genau.
Unser Team für Magento-SEO-Checkliste behandelt die SEO-Seite umfassender.
Schritt 7: Machen Sie aus der Liste einen Plan
Sobald jedes Modul eingeordnet ist, haben Sie alles für einen realistischen Plan:
- Die Zahl der Portierungen ergibt den Hauptentwicklungsaufwand.
- Die Checkout-Variante ergibt das Hauptrisiko.
- Die Module, die Sie entfernen, machen den Shop einfacher und leichter.
Jetzt ist auch der richtige Moment, den Server zu betrachten. Hyvä macht das Frontend leichter, aber ein langsamer Server, ein defekter Full-Page-Cache oder sehr große Bilder bleiben mit jedem Theme langsam.
Wenn Sie gleichzeitig ein Magento-Upgrade planen, führen Sie dasselbe Extension-Audit für das Upgrade durch – so prüfen Sie jedes Modul nur einmal.
FAQ
Wie viele Extensions sind für Hyvä zu viele?
Eine feste Zahl gibt es nicht. Entscheidend ist, wie viele Storefront-Code ohne Kompatibilitätsmodul haben und wie komplex dieser ist.
Können wir auf Hyvä umsteigen, wenn eine Zahlungsart nicht Hyvä-fähig ist?
Ja. Sie können die Integration bauen lassen oder den Checkout vorerst auf Luma belassen, während der Rest des Shops auf Hyvä läuft.
Wer sollte das Extension-Audit durchführen?
Ein Magento-Entwickler, der sowohl Luma als auch Hyvä kennt. Für den Audit braucht es jemanden, der Modulcode lesen kann – nicht nur die Marketingseite des Moduls.
Wir prüfen jede Extension, bevor wir ein Angebot für eine Hyvä-Migration erstellen. Wie der Ablauf funktioniert, sehen Sie auf unserer Seite Hyvä-Theme-Entwicklung , unter anderem was kaputtgeht und wie wir damit umgehen.


