Wie lange dauert eine Hyvä-Migration? Phasen und Zeitplan

“Wie lange dauert das?” ist meist die zweite Frage, die wir zu Hyvä hören – gleich nach “Wird es schneller?”. Die ehrliche Antwort: Es hängt von Ihrem Shop ab. Diese Antwort ist aber nur nützlich, wenn wir auch erklären, wovon es abhängt. Dieser Beitrag geht die Phasen einer Migration von Luma zu Hyvä durch und zeigt, welche Faktoren jede Phase kürzer oder länger machen.

Wenn Hyvä für Sie neu ist, beginnen Sie mit unserem verständlichen Hyvä-Leitfaden. Kurz gesagt: Hyvä ersetzt das Frontend von Luma aus RequireJS, KnockoutJS, jQuery und LESS durch Tailwind CSS und Alpine.js. Ihr Magento-Backend, Ihr Katalog, Ihre Kunden und Bestellungen bleiben, wo sie sind.

Warum es keine pauschale Zahl gibt

Eine Hyvä-Migration ist ein Neuaufbau des Frontends, keine Datenmigration. Produkte, Preise, Kunden und Bestellhistorie werden nirgendwohin verschoben. Was sich ändert, ist jedes Template, jedes Skript und jeder Style, den der Kunde sieht.

Der Umfang des Projekts hängt daher von der Frontend-Oberfläche Ihres Shops ab:

• Wie viele Extensions von Drittanbietern etwas im Frontend ausgeben.
• Ob es für diese Extensions ein Hyvä-Kompatibilitätsmodul gibt.
• Ob Sie Ihren aktuellen Look behalten oder ein neues Design möchten.
• Welchen Checkout Sie wählen.
• Wie viele Store Views, Sprachen und Märkte Sie betreiben.

Zwei Shops mit gleich vielen Produkten können sehr unterschiedlich viel Arbeit bedeuten. Ein Shop mit einer Handvoll bekannter Extensions und einem nativen Hyvä-Design ist ein kleines Projekt. Ein Shop mit vielen individuellen Modulen, einem stark angepassten Checkout und mehreren Märkten ist ein deutlich größeres.

Phase 1: Audit und Projektplan

Alles beginnt mit einem Audit Ihres aktuellen Shops. Wir listen jedes aktivierte Modul auf und prüfen, was es im Frontend tut. Reine Backend-Module wie ERP-Anbindungen oder Feed-Exporter brauchen in der Regel überhaupt keine Frontend-Arbeit.

Für jedes Frontend-Modul gibt es drei mögliche Ergebnisse:

1. Es gibt ein Hyvä-Kompatibilitätsmodul, das installiert werden kann.
2. Es gibt kein Kompatibilitätsmodul, die Templates müssen also für Alpine.js und Tailwind neu geschrieben werden.
3. Das Modul wird nicht mehr gebraucht und kann entfernt werden.

Diesen Schritt beschreiben wir ausführlich in unserer Hyvä-Migrations-Checkliste. Der Audit umfasst außerdem den Server, die aktuelle Performance-Baseline und Ihr Analytics-Setup. Am Ende erhalten Sie einen Projektplan mit Design, Struktur, Extensions und Server sowie einen Zeitplan.

Diese Phase beseitigt den Großteil der Unsicherheit. Jeder Zeitplan, der vor dem Audit genannt wird, ist eine Schätzung ins Blaue.

Phase 2: Scope und Festpreisangebot

Nach dem Audit wird der Scope zu einer klaren Liste. Seiten, Checkout und Extensions werden einzeln festgehalten. Nach dieser Liste bauen wir, und diese Liste geben Sie frei.

In der Scope-Phase fallen auch die großen Entscheidungen:

• Design-Weg. Ein natives Hyvä-Design mit Ihrem Logo, Ihren Farben und Schriften ist der schnellste Weg zum Livegang. Ihr aktuelles Theme anzupassen oder ein individuelles Design zu entwickeln dauert länger.
• Checkout. Hyvä Checkout, ein Checkout eines Drittanbieters oder eines unserer eigenen Templates mit 2 Schritten, 3 Schritten oder als One-Page-Checkout. Jede Variante erfordert unterschiedlich viel Einrichtung und Tests.
• Extensions ohne Kompatibilitätsmodul. Jede wird entweder neu gebaut, ersetzt oder entfernt.

Klare Entscheidungen an dieser Stelle halten die Umsetzungsphase kurz. Offene Fragen kommen später meist als Verzögerungen zurück.

Phase 3: Design und Umsetzung auf Staging

Die Umsetzung findet immer auf einer Staging-Umgebung statt, nie in Ihrem Live-Shop. Ihr Luma-Shop verkauft weiter, während die Hyvä-Version daneben entsteht.

Die typische Reihenfolge der Arbeiten:

1. Child-Theme und Design-Tokens (Farben, Schriften, Abstände) in Tailwind.
2. Header, Footer, Navigation und Suche.
3. Kategorieseiten, Layered Navigation und Produktlisten.
4. Produktseiten, einschließlich konfigurierbarer Produkte, Galerie und Bewertungen.
5. Warenkorb, Mini-Warenkorb und Checkout.
6. Kundenkonto-Seiten und CMS-Inhalte.
7. Extension-Templates, die neu geschrieben werden müssen.

Produktseite und Checkout kosten in der Regel am meisten Zeit, weil dort die meiste Logik und die meisten Extensions stecken. Auch mit Page Builder erstellte Inhaltsseiten brauchen Aufmerksamkeit, da Widgets aus der Luma-Zeit auf Skripte angewiesen sein können, die Hyvä nicht mehr lädt.

Sie prüfen die Staging-Umgebung, während sie wächst, nicht erst am Ende. Kurze Feedback-Schleifen sind viel schneller als eine große Abnahme zum Schluss.

Phase 4: Tests

Testen ist kein kurzer Schritt am Ende, sondern eine eigene Phase. Sie zu überspringen ist der häufigste Grund, warum Migrationen nach dem Launch schiefgehen.

• Checkout-Tests für jede Zahlungs- und Versandart, in jedem Markt.
• Store-View-Tests für Übersetzungen, Währungen und Steueranzeige.
• Tracking-Tests für GA4-E-Commerce-Events und alle Marketing-Tags.
• Speed-Tests mit Lighthouse auf Start-, Kategorie- und Produktseiten.
• SEO-Prüfungen für URLs, Canonicals, strukturierte Daten und Weiterleitungen.

Unsere Methode für Speed-Tests erklären wir in wie wir die Hyvä-Geschwindigkeit mit Lighthouse testen. Ein weiterer Klassiker sind die Sicherheitsregeln im Checkout: Hyvä Checkout läuft auf Magewire, und seine Content-Security-Policy-Regeln müssen mit Ihren echten Zahlungsanbietern getestet werden.

Phase 5: Launch und danach

Die Umstellung selbst ist geplant und kurz. Da sich das Backend nicht ändert, bedeutet der Livegang vor allem: das neue Theme deployen, es Ihren Store Views zuweisen und die Caches leeren.

Ein guter Launch-Plan umfasst:

• Ein Launch-Zeitfenster mit wenig Traffic.
• Einen Rollback-Weg zum alten Theme, falls etwas Kritisches auftritt.
• Einen CDN-Cache-Purge nach dem Deploy.
• Monitoring von Bestellungen, Fehlern und erfolgreichen Zahlungen in den ersten Tagen.

Nach dem Launch messen wir erneut und vergleichen mit den Ausgangswerten. Laborwerte zählen, aber echte Nutzerdaten und abgeschlossene Checkouts zählen mehr.

Was eine Migration verkürzt oder verlängert

Der größte Einzelfaktor ist meist die Liste der Extensions. Ein Shop, der ungenutzte Module vor der Migration entfernt, spart in jeder späteren Phase Zeit.

FAQ

Ist mein Shop während einer Hyvä-Migration offline?

Nein. Das neue Frontend wird auf einer Staging-Umgebung gebaut, während Ihr aktueller Shop weiter verkauft. Die Umstellung beim Launch ist kurz und für eine ruhige Zeit geplant.

Müssen wir unsere Produkte und Kunden migrieren?

Nein. Hyvä ist ein Frontend-Theme, Ihr Katalog, Ihre Kunden und Bestellungen bleiben also in derselben Magento-Datenbank. Nur die Storefront wird neu aufgebaut.

Können wir Magento gleichzeitig upgraden?

Das ist möglich, wir empfehlen aber meist einen separaten Schritt. Beides zu kombinieren erschwert das Testen, weil sich nicht erkennen lässt, ob ein Problem vom Upgrade oder vom neuen Theme kommt.

Sie möchten einen realistischen Zeitplan für Ihren eigenen Shop? Unsere Hyvä-Migrationspakete beginnen mit einem Audit jeder Extension, damit der Plan auf Ihrem Shop basiert und nicht auf einer Schätzung.