Hyvä-Migration: Was Sie in der ersten Woche erwarten können
Eine Hyvä-Migration ist hauptsächlich ein Frontend-Austausch. Magento Open Source oder Adobe Commerce bleibt, wo es ist. Katalog, Bestellungen, Kunden, Zahlungsintegrationen bleiben unberührt. Was sich ändert, ist die Themenebene.
Die meisten Teams benötigen 2 bis 4 Wochen. Die eigentliche Programmierarbeit ist ein Bruchteil davon. Der Rest sind Entscheidungen: Welche Drittanbieter-Module benötigen ein Hyvä-Kompatibilitätsmodul, was ist mit benutzerdefinierten Luma-Overrides zu tun und wie geht man mit den unvermeidlichen, storefront-spezifischen Randfällen um, die Ihr Team vor Jahren erstellt hat und nie dokumentiert hat.
Die Form der ersten Woche
Die erste Woche legt das Tempo für alles Folgende fest. Gut gemacht, haben Sie ein Hyvä-Theme, das gegen Ihre Staging-Datenbank rendert, mit dem Großteil des Katalogs intakt und Ihren drei wichtigsten Checkout-Flows, die manuelle Tests bestehen. Schlecht gemacht, finden Sie sich in Woche drei mit dem Debuggen von Luma-JS-Rückständen wieder.
Was tatsächlich in der ersten Woche passiert:
Tag 1: Audit und Inventar. Jedes Drittanbieter-Modul in Ihrer Composer-Datei wird auf Hyvä-Kompatibilität überprüft. Einige haben offizielle Kompatibilitätsmodule. Einige haben Community-Module. Einige haben nichts, und Sie entscheiden, ob Sie bauen, patchen oder entfernen.
Tag 2-3: Hyvä installieren, das Standard-Theme ausführen. Lassen Sie den grünen Hyvä-Storefront mit Ihren echten Produktdaten laufen. Bestätigen Sie, dass Warenkorb-, Checkout- und Kontoflüsse mit dem Standard-Theme funktionieren.
Tag 4-5: Das Standard-Theme branden. Farben, Typografie, Logo, Kopfzeile, Fußzeile. Hyvä's Tailwind-Setup macht dies schneller als die entsprechende Luma-Arbeit um einen erheblichen Betrag.
Was wir gewünscht hätten, vorher gewusst zu haben
Einige Dinge, die in den meisten Hyvä-Migrationsleitfäden nicht erwähnt werden, aber echte Zeit kosten:
- PWA Studio-Rückstände. Wenn der Shop jemals PWA Studio installiert hatte, erwarten Sie Geisterreferenzen zu Service-Workern und veraltete Manifeste. Überprüfen Sie
pub/staticfrühzeitig. - Benutzerdefinierte Knockout-Komponenten. Alles in
view/frontend/web/js, das Knockout verwendet, benötigt eine Neuschreibung zu Alpine oder einem Hyvä-nativen Äquivalent. Planen Sie dafür. Es ist der Teil, der Teams überrascht. - E-Mail-Vorlagen. Bestell- und Kunden-E-Mail-Vorlagen verwenden immer noch den Legacy-Magento-Renderer. Gehen Sie nicht davon aus, dass sie überarbeitet werden müssen. Testen Sie sie vor dem Start.
- Konfigurationen von Drittanbieter-Modulen. Einige Kompatibilitätsmodule benötigen zusätzliche Admin-Konfigurationen, die leicht übersehen werden können. Hyvä Themes führt eine Liste. Überprüfen Sie sie.
Die wichtige Kennzahl
Lighthouse Performance ist der Test, den wir vor der Abnahme durchführen. Das Hyvä-Standard-Theme auf einem richtig konfigurierten Magento-Shop liegt im Bereich von 80-95 von Anfang an. Wenn Ihre Migration unter 70 fällt, stimmt etwas nicht, normalerweise ein Drittanbieter-Modul, das Luma-Assets in den Hyvä-Build einfließen lässt.
Wir haben gesehen, dass Migrationen in drei Wochen bei 92 mobil landen. Wir haben auch gesehen, dass sich einige über drei Monate hinziehen, weil das Team weiterhin Module hinzufügte, ohne die Auswirkungen zu messen. Die Disziplin ist die gleiche wie bei jeder anderen Leistungsarbeit: Budgetieren, Messen, Ausliefern.
Für wen Hyvä nicht geeignet ist
Hyvä hat eine klare Meinung dazu, wie das Frontend funktionieren sollte. Tailwind, Alpine, servergerendertes HTML. Wenn Ihr Team sich einem stark angepassten React- oder Vue-Storefront verpflichtet hat, ist Hyvä nicht der richtige Weg. Sie möchten ein headless Setup mit Adobe Commerce oder einen separaten PWA-Stack.
Für die meisten Magento-Shops ist Hyvä jedoch der günstigste große Leistungsgewinn auf dem Tisch. Kleinere Bundles, schnellere Darstellung, weniger JS zum Debuggen. In fast jedem Fall, den wir seit 2021 gesehen haben, ist die Migrationskosten wert.