Die Hyvä-Migrationscheckliste: 47 Punkte, bevor Sie starten

Hyvä-Migrationsprojekte, die lange dauern oder das Budget überschreiten, lassen sich fast immer auf etwas zurückführen, das beim Scoping übersehen wurde. Diese Checkliste umfasst die 47 Punkte, die wir mit jedem Händler während der Vorbereitungen durchgehen. Einmal durchzugehen dauert 2–3 Stunden und verhindert 90 % der Überraschungen während des Projekts.

Verwenden Sie sie, bevor Sie den Umfang der Hyvä-Migration unterzeichnen. Nehmen Sie sie mit zu der Agentur, die Sie in Betracht ziehen, und gehen Sie sie gemeinsam durch.

Abschnitt A: Magento-Umgebung (Punkte 1–8)

1. Magento-Version bestätigt (z.B. Magento Open Source 2.4.6, Adobe Commerce 2.4.7). Hyvä unterstützt bestimmte Versionen; wenn Sie eine ältere Version verwenden, planen Sie zuerst ein Upgrade von Magento.

2. PHP-Version ist Hyvä-kompatibel. Hyvä unterstützt typischerweise PHP 8.1+, abhängig von der Magento-Version. Bestätigen Sie, dass Ihr Hosting übereinstimmt.

3. Hosting-Umgebung bereit für Staging. Eine separate Staging-Umgebung (die der Produktionskonfiguration + aktuellen Daten entspricht) ist nicht verhandelbar. Die Migrationsarbeiten finden hier vor dem Cutover statt.

4. Produktionsdaten kürzlich auf Staging aktualisiert. Staging-Daten, die älter als 30 Tage sind, zeigen Unterschiede zur Produktion bei UAT. Aktualisieren Sie vor dem Start.

5. Composer-Authentifizierung funktioniert für Magento + private Anbieter. Bestätigen Sie, dass composer install in der Staging-Umgebung fehlerfrei läuft. Authentifizierungsprobleme während des Projekts blockieren die Bereitstellung.

6. Ausreichend Speicherplatz + Arbeitsspeicher auf Staging für die Hyvä-Installation. Die kompilierten Assets von Hyvä erhöhen den Speicherplatzbedarf; überprüfen Sie, ob die Staging-Umgebung damit umgehen kann.

7. Datenbanksicherungsverfahren dokumentiert. Bestätigen Sie, dass Sie die Datenbank zurücksetzen können, falls während des Cutovers etwas katastrophal schiefgeht.

8. Wartungsmodus-Workflow getestet. Bestätigen Sie, dass das Aktivieren/Deaktivieren des Wartungsmodus wie erwartet funktioniert; dies ist der Mechanismus für den Cutover-Tag.

Abschnitt B: Erweiterungsinventar (Punkte 9–18)

9. Vollständige Erweiterungsliste dokumentiert. Anbieter + Erweiterungsname + Version + Lizenzstatus für jede kostenpflichtige Erweiterung. Ziehen Sie die Daten aus composer.json + composer.lock.

10. ZIP-installierte Erweiterungen separat identifiziert. Alles in app/code/*, das nicht über Composer bereitgestellt wird. Oft die kniffligsten zu migrierenden.

11. Benutzerdefinierte Inhouse-Erweiterungen identifiziert. Alles, was von Ihrem vorherigen Entwicklerteam geschrieben wurde und die Benutzeroberfläche betrifft.

12. Jede Erweiterung gegen compat.hyva.io überprüft. Status notiert: Kompatibel (Anbieter-Kompatibilität) / Workaround (Community-Kompatibilität) / Nicht kompatibel / Unbekannt.

13. Anbieter-Kompatibilitätsmodulversionen überprüft. Ein Anbieter, der Hyvä-Kompatibilität für die aktuelle Erweiterungsversion liefert, tut dies möglicherweise nicht für Ihre ältere Version. Überprüfen Sie jede Erweiterung.

14. Erweiterungen, die als "überspringen statt migrieren" identifiziert sind. Eingestellte Erweiterungen, redundante Erweiterungen, Erweiterungen, die ersetzt werden sollen, gekennzeichnet, damit wir nicht für Kompatibilität bezahlen, die wir nicht nutzen werden.

15. Lizenzgültigkeit für jede kostenpflichtige Erweiterung bestätigt. Composer-Installationen benötigen gültige Lizenzen; abgelaufene blockieren die Bereitstellung.

16. Erweiterungen, die in den Checkout eingreifen, für zusätzliche QA gekennzeichnet. Zahlung, Betrug, Versand, Geschenkkarten, Store-Guthaben, diese benötigen vollständige Testläufe des Bestellflusses.

17. Benutzerdefinierte Themenänderungen inventarisiert. Alles, was Ihr vorheriges Entwicklerteam im Luma-Theme angepasst hat und unter Hyvä repliziert werden muss.

18. Magic-String / Event-Dispatcher-Abhängigkeiten notiert. Einige Erweiterungen hängen von spezifischen Ereignisnamen oder Magic-Strings ab; diese müssen in die Hyvä-Kompatibilitätsmodule übertragen werden.

Abschnitt C: Inhalt + URL-Struktur (Punkte 19–26)

19. URL-Struktur dokumentiert. Jede PDP-, PLP-, CMS-Seiten-URL notiert. URLs, die sich nicht ändern werden, überprüft.

20. URLs, die sich ändern werden, identifiziert. Alle, die sich ändern, benötigen 301-Weiterleitungen zum Cutover.

21. URL-Rewrites-Tabelle gesichert. Die url_rewrite-Tabelle von Magento ist entscheidend für SEO; sichern Sie sie vor dem Cutover.

22. Strukturierte Daten (Produkt, Angebot, Breadcrumb, FAQSeite) auf der bestehenden Website überprüft. Was auch immer jetzt vorhanden ist, muss zu Hyvä übertragen werden.

23. Schema.org-Markup, das derzeit auf der PDP vorhanden ist, katalogisiert. Insbesondere: Produkt, Angebot, AggregateRating, Bewertung, FAQSeite. Bestätigen Sie, dass alles übertragen wird.

24. CMS-Inhalte inventarisiert. Statische Seiten, CMS-Blöcke, Banner, dynamische Inhaltsblöcke, alle benötigen ihre Hyvä-Äquivalente.

25. SEO-Metadaten pro Seitentyp bestätigt. Titel-Tags, Meta-Beschreibungen, kanonische Tags, hreflang für Mehrsprachigkeit.

26. Aktueller Zustand von Sitemap und robots.txt dokumentiert. Der Cutover ändert diese nicht, aber eine Überprüfung ist eine gute Gelegenheit.

Abschnitt D: Leistungsbasislinie (Punkte 27–32)

27. Mobile Lighthouse-Leistungsbewertung für PDP, PLP, Suche, Warenkorb, Checkout aufgezeichnet. Dies ist Ihre Basislinie vor der Messung der Verbesserung.

28. Status der Core Web Vitals aus der Search Console aufgezeichnet. Aktueller Status Gut/Verbesserungsbedürftig/Schlecht pro URL-Gruppe.

29. Aktuelles Seitengewicht gemessen. HTML, JS, CSS, Bildgewicht pro Schlüssel-Seitentyp.

30. Inventar der Drittanbieter-Tags. GTM-Tags, Analyseschscripts, Chat-Widgets, Marketing-Pixel, alles, was von nicht-ersten Domains geladen wird.

31. Aktuelle mobile Konversionsrate erfasst. Insbesondere: mobile Warenkorb-Hinzufügungsrate und mobile Checkout-Abschlussrate. Die Nachzahlen sind, wie Sie den ROI messen werden.

32. Aktuelle Desktop-Konversionsrate erfasst. Zum Vergleich; der Anstieg wird auf dem Desktop kleiner sein als auf dem Mobilgerät.

Abschnitt E: Design + UX (Punkte 33–38)

33. Designabsicht bestätigt: treue Wiederherstellung vs. Rebranding vs. neue Richtung. Dies ist das größte Risiko für den Umfangswachstum; sichern Sie es beim Scoping.

34. Markentokens dokumentiert. Farben, Typografie, Abstände, Randradien. Diese fließen in die Tailwind-Konfiguration ein.

35. Erwartungen an die Komponentenbibliothek festgelegt. Button-Stile, Formular-Stile, Karten-Stile, existieren sie? Müssen sie entworfen werden? Hyvä-Standards verwenden?

36. PDP-Warenpräsentationsblöcke inventarisiert. Verwandte Produkte, zuletzt angesehen, Upsells, Cross-Sells, FAQ-Akkordeon, Bewertungen, alles wird übertragen?

37. Anforderungen an den Kundenkonto-Bereich bestätigt. Standard-Magento-Konto oder angepasst? Abonnements, Geschenkkarten, Rücksendungen?

38. Mobile spezifische UX-Anforderungen notiert. Sticky-Hinzufügen-zum-Warenkorb, mobiles Mini-Warenkorb, mobiles Filterverhalten.

Abschnitt F: B2B / Adobe Commerce-Funktionen (Punkte 39–43)

(Überspringen Sie diesen Abschnitt, wenn Magento Open Source B2C.)

39. B2B-Funktionen in Gebrauch katalogisiert. Unternehmenskonten, gemeinsame Kataloge, kundenspezifische Preise, Angebote, Bestelllisten, Genehmigungs-Workflows, alles muss neu gestaltet werden.

40. Kundensegmentierte Katalogsichtbarkeit bestätigt. Welche Segmente sehen welche Produkte/Kategorien?

41. Kundenspezifische Preislogik dokumentiert. Preiskategorien, Vertragspreise, Mengenrabatte, alles muss pro angemeldetem Kunden korrekt angezeigt werden.

42. Genehmigungs-Workflow-Schwellen dokumentiert. Welche Bestellungen benötigen eine Genehmigung, wer genehmigt, wie die Benachrichtigung funktioniert.

43. B2B-spezifische PDP-Attribute notiert. Datenblätter, Zertifikate, Lieferzeiten, Preise für Großpackungen.

Abschnitt G: Stakeholder + Projektmanagement (Punkte 44–47)

44. Überprüfungszeiträume für Stakeholder gebucht. Die UAT-Woche benötigt den Kalender Ihres Teams. Buchen Sie es vor dem Start.

45. Cutover-Fenster bestätigt. Off-Peak-Wochenende, keine Verkaufsveranstaltungen, keine Marketingkampagnen, die um Traffic konkurrieren.

46. Ressource für die Nachverfolgung nach dem Start bestätigt. Jemand auf Ihrer Seite, der 72 Stunden nach dem Cutover verfügbar ist, um Probleme zu erkennen.

47. Genehmigungsbehörde bestätigt. Wer hat die Befugnis, Änderungen am Umfang, den Abschluss der UAT und das Go/No-Go für den Cutover zu genehmigen? Eine namentlich genannte Person ist bevorzugt.

Was mit dieser Liste zu tun ist

1. Gehen Sie sie durch, bevor Sie Scoping-Angebote anfordern. Je mehr Punkte Sie mit "ja / dokumentiert / bestätigt" beantworten können, bevor Sie mit Agenturen sprechen, desto schneller + günstiger wird Ihr Scoping sein.

2. Nehmen Sie sie mit zu Ihrer Shortlist von Hyvä-Agenturen. Lassen Sie sie gemeinsam mit Ihnen durchgehen. Agenturen, die sich gründlich mit der Checkliste beschäftigen, zeigen, dass sie Migration verstehen; Agenturen, die sie nur oberflächlich durchgehen, zeigen, dass sie es nicht tun.

3. Verweisen Sie darauf beim Kickoff. Bevor die Arbeiten beginnen, sollte jeder Punkt der Checkliste eine bestätigte Antwort haben. Offene Punkte beim Kickoff werden bis Woche 4 zu Problemen.

4. Verwenden Sie sie für das Nachspiel. Wenn etwas schiefgeht, verfolgen Sie zurück, welcher Punkt der Checkliste fehlgeschlagen ist. Aktualisieren Sie die Checkliste für das nächste Mal.

Was diese Checkliste nicht abdeckt

Einige Dinge, die die Checkliste absichtlich nicht enthält, weil sie zu projektspezifisch sind:

• Spezifische Anforderungen an benutzerdefinierte Funktionen (Konfiguratoren, AR-Viewer, benutzerdefinierte Suche), diese benötigen eigene Umfangsdokumente
• Koordination von Marketingkampagnen, Ihr Marketingteam ist dafür verantwortlich
• Kommunikationsplan mit Kunden über den Cutover, normalerweise nicht erforderlich, wenn der Cutover reibungslos verläuft
• Langfristige Hyvä-Roadmap (wann Checkout hinzufügen, wann Admin hinzufügen), sprechen Sie über Phase 2, nachdem Phase 1 abgeschlossen ist

Wenn Ihr Umfang eines davon umfasst, erstellen Sie separate detaillierte Umfangsdokumente dafür zusätzlich zu dieser Basischeckliste.

Warum 47?

Keine magische Zahl. Die Liste ist im Laufe der Jahre gewachsen, als wir gelernt haben, auf welche Punkte Überraschungen während des Projekts zurückzuführen sind. Derzeit liegt sie bei 47; sie wird wahrscheinlich in den nächsten zwei Jahren auf 52 wachsen, wenn neue Randfälle auftauchen.

Der Punkt ist nicht die Zahl; es geht darum, eine umfassende Liste zu haben, die Sie einmal durchgehen, anstatt Punkte in Woche 5 des Builds zu entdecken.

Nächste Schritte

• Sehen Sie sich die Hyvä-Migrationsdienstseite für den vollständigen Prozess an
• Lesen Sie Wie man Magento Luma in 8 Wochen nach Hyvä migriert für eine wöchentliche Aufschlüsselung
• Lesen Sie Hyvä-Migrationskosten im Jahr 2026 für den Kostenrahmen
• Buchen Sie einen Scoping-Anruf, wir gehen diese Checkliste gemeinsam durch