Wie lange dauert eine Hyvä-Migration tatsächlich?

Eine typische Luma → Hyvä-Migration dauert 6–10 Wochen vom Kickoff bis zur Live-Umstellung. Hyvä Commerce (Theme + Checkout) liegt bei 10–14 Wochen. Hyvä Enterprise auf Adobe Commerce mit vollständigen B2B-Funktionen benötigt 14–16 Wochen.

Diese Zahlen sind realistisch und basieren auf unseren letzten 50+ Hyvä-Bauten, nicht auf Marketingaspirationen. Hier sind die Faktoren, die sie beeinflussen, wo die Abweichungen herkommen und die ehrlichen Worst-Case-Überziehungen.

Die Hauptzeitlinien

Projekttyp	Typischer Zeitrahmen	Bereich
Nur Hyvä Theme (kleiner Shop, 5–10 Erweiterungen)	6 Wochen	5–8 Wochen
Hyvä Theme (mittlerer Shop, 15–25 Erweiterungen)	8 Wochen	7–10 Wochen
Hyvä Theme (großer Shop, 25+ Erweiterungen)	10 Wochen	9–12 Wochen
Hyvä Commerce (Theme + Checkout)	12 Wochen	10–14 Wochen
Hyvä Enterprise (Adobe Commerce B2B)	14 Wochen	12–16 Wochen
Standalone Hyvä Checkout auf bestehendem Hyvä Theme	3 Wochen	2–4 Wochen
Standalone Hyvä Checkout auf Luma	4 Wochen	3–5 Wochen
Pro-Erweiterung benutzerdefiniertes Hyvä-Kompatibilitätsmodul	2 Wochen	1–3 Wochen

Was den Zeitrahmen beeinflusst

In grober Reihenfolge der Auswirkungen:

1. Anzahl der kostenpflichtigen Erweiterungen

Dies ist die größte Variable. Jede kostenpflichtige Erweiterung im Shop benötigt ein Hyvä-Kompatibilitätsmodul, bevor ihr Frontend korrekt gerendert wird. Viele Anbieter liefern ihre eigenen; die restlichen benötigen eine benutzerdefinierte Kompatibilität.

Zeitliche Auswirkungen: Jede benutzerdefinierte Kompatibilitäts-Erweiterung fügt 3–10 Tage hinzu. Ein sauberer Shop mit 5 Anbieter-kompatiblen Erweiterungen läuft schnell; ein Shop mit 25 gemischten Erweiterungen benötigt 4–6 Wochen zusätzlich.

2. Hyvä Commerce vs Hyvä Theme

Hyvä Theme allein deckt den Shop ab. Das Hinzufügen von Hyvä Checkout (mit Zahlungs- + Versand- + Betrugsmodulintegration) fügt 2–4 Wochen hinzu. Das Hinzufügen von Hyvä Admin + Insights fügt 1–2 Wochen hinzu.

3. B2B-Funktionsumfang (Adobe Commerce)

Jede Adobe Commerce B2B-Funktion (Unternehmenskonten, gemeinsame Kataloge, Kundenpreise, Angebote, Genehmigungen) ist eine separate Hyvä-Vorlagenschicht. Voller B2B-Umfang fügt 4–6 Wochen hinzu.

4. Designtreue vs. Rebranding

Ein treuer Luma → Hyvä-Neubau entspricht dem bestehenden Design unter der neuen Renderschicht. Ein angehängtes Rebranding fügt 2–3 Wochen an Design- + Entwicklungsiteration hinzu. Entweder verpflichten Sie sich beim Scoping zum Rebranding oder sparen Sie es für das nächste Jahr.

5. Multi-Store / Multi-Website Magento

Zwei Shops benötigen nicht doppelt so viel Zeit wie einer, wenn Design + Funktionalität identisch sind. Fünf Shops mit länderspezifischen Variationen benötigen leicht das Dreifache der Zeit.

6. Komplexität des Kundenkontobereichs

Das Standard-Magento-Kundenkonto ist unkompliziert. Wenn Sie Abonnements, Geschenkkarten, Guthaben, Rückgabeportale, Mehradressenversand hinzugefügt haben, fügt jede 2–5 Tage hinzu.

7. Komplexität des benutzerdefinierten Checkout-Flusses

Benutzerdefinierte Versandmethoden, B2B-Genehmigungsrouting, mehrstufige Checkout-Anpassungen, bedingte Felder pro Versandland, jede fügt Zeit hinzu. Starke Anpassungen können den eigenständigen Hyvä Checkout von 3 Wochen auf 6 erhöhen.

Die Standard-8-Wochen-Aufschlüsselung (nur Theme-Migration)

Für eine typische Hyvä Theme-Migration eines mittleren Shops:

• Woche 1: Grundlagen, Hyvä Theme-Installation, Tailwind-Markenkonfiguration, Designsystem-Komponentenbibliothek, Kopfzeile / Fußzeile / Navigation
• Woche 2–3: Seitenvorlagen, PDP, PLP, Suche, Warenkorb, Kundenkonto, CMS-Blöcke
• Woche 4–5: Erweiterungskompatibilität, Anbieter- + benutzerdefinierte Kompatibilitätsmodule
• Woche 6: Leistungstuning, Lighthouse Mobile 90+ als Ausstiegskriterium
• Woche 7: UAT auf Staging, echte Bestellungen von Anfang bis Ende, plattformübergreifend, Barrierefreiheit, Fehlerbeseitigung
• Woche 8: Umstellung + 72 Stunden Nachverfolgung nach dem Start + Fehlerbehebungs-Sprint

Jede Woche hat explizite Meilensteine, die wir überprüfen. Wenn wir einen Meilenstein verpassen, verschiebt sich das Umstellungsdatum; wir komprimieren die späteren Wochen nicht, um aufzuholen.

Die Liste „Was einen 8-Wochen-Zeitplan entgleisen lässt“

In grober Häufigkeitsreihenfolge, basierend auf unseren Projektunterlagen:

1. Die Erweiterungsliste wächst während des Projekts (am häufigsten)

Neue kostenpflichtige Erweiterung, die in Woche 4 entdeckt wird = 1–3 Wochen hinzugefügt. Fast immer vermeidbar, indem das Inventar gründlich vor dem Kickoff durchgeführt wird.

Minderung: Behandeln Sie das Erweiterungsinventar als harte Grenze, bevor das Scoping abgeschlossen ist. Beginnen Sie die Bauarbeiten nicht, ohne dass es festgelegt ist.

2. Designumfangscreep

„Während wir dabei sind, können wir das PDP neu gestalten?“ = 2+ Wochen hinzugefügt. Häufiges Muster: Stakeholder sieht den neuen Hyvä-Shop auf Staging und entscheidet, dass die Farben / Typografie nicht ganz stimmen, was zu einem Rebranding während des Projekts führt, das nicht eingeplant war.

Minderung: Designreferenzen beim Scoping festlegen. Verpflichten Sie sich entweder zu „treuem Luma-Neubau“ oder „ein Rebranding von Tag 1 an im Umfang enthalten“. Lassen Sie keine Unklarheit zu.

3. Magento-Version-Upgrade kombiniert

Upgrade von Magento 2.4.4 → 2.4.7 + Migration zu Hyvä im selben Zeitraum = +3–4 Wochen integrierte Komplexität.

Minderung: Sequenzieren Sie sie. Upgrade von Magento zuerst, 4–6 Wochen in der Produktion laufen lassen, um Regressionen zu erkennen, dann zu Hyvä migrieren. Kombinierte Upgrades kosten fast immer mehr als die sequenzierten Versionen.

4. Staging-Umgebung nicht bereit beim Kickoff

Wenn wir am Tag 1 der Woche 1 nicht auf Staging bereitstellen können, verschiebt sich jeder Verzögerungstag 1:1 auf die Umstellung.

Minderung: Staging während des Pre-Flights einrichten, bevor das Kickoff-Datum beginnt.

5. Stakeholder-Überprüfung während UAT langsam

Die UAT-Woche geht davon aus, dass Ihr Team Zeit für Tests aufwenden kann. Wenn das Feedback 5 Arbeitstage dauert, ist das 5 Tage, an denen sich die Umstellung verschiebt.

Minderung: Buchen Sie Stakeholder-UAT-Kalenderplätze vor dem Kickoff. Lassen Sie die Überprüfung in Woche 7 nicht ad-hoc planen.

6. Überraschende B2B-Anforderung tritt auf

Wenn in Woche 5 festgestellt wird, dass der Händler Selbstbedienungs-Unternehmenskonten oder einen Angebotsfluss benötigt, verwandelt sich eine B2C-Migration in ein B2B-Projekt.

Minderung: Explizite B2B-Umfangsfrage beim Scoping. „Haben Sie eines dieser Merkmale?“ + Checkliste der B2B Adobe Commerce-Funktionen.

7. Umstellungsdatum kollidiert mit Verkaufsereignissen

Versuchen, in der Woche von Black Friday oder während eines Produkteinführungs-Events umzuschalten. Tun Sie es nicht.

Minderung: Wählen Sie ein 4-wöchiges ruhiges Zeitfenster für die Umstellung + Nachverfolgung nach dem Start. Warten Sie gegebenenfalls auf das richtige Zeitfenster; wir haben Migrationen dafür um 8 Wochen verschoben.

Wenn 8 Wochen nicht realistisch sind

Seien Sie ehrlich, wenn einer dieser Punkte zutrifft, benötigen Sie 10–14 Wochen, nicht 8:

• 25+ kostenpflichtige Erweiterungen
• B2B Commerce-Funktionen im Umfang
• Stark angepasster Checkout-Fluss
• Hyvä Commerce Umfang (nicht nur Hyvä Theme)
• Markenrebranding, das an die Migration angehängt wird
• Multi-Store / Multi-Website Magento-Setup mit >2 Shops
• Adobe Commerce in der Cloud (CI-Pipeline fügt Reibung im Vergleich zu selbst gehostet hinzu)

Für diese Fälle geben wir 10–14 Wochen im Voraus an. 8 Wochen bringen Ihnen eine halb-fertige Website live; niemand gewinnt.

Worst-Case-Überziehungen, die wir gesehen haben

Realistische Worst-Case-Szenarien aus unseren Projektunterlagen:

12-Wochen-Projekt, das 18 Wochen dauerte. B2B Adobe Commerce. Während des Projekts fügte der Händler eine Anforderung hinzu, sich mit einem benutzerdefinierten ERP zu integrieren, das nicht auf der ursprünglichen Liste stand. Die ERP-Integration allein fügte 4 Wochen hinzu. Endergebnis: Erfolgreich versendet, aber 6 Wochen zu spät.

8-Wochen-Projekt, das 11 Wochen dauerte. Standard Magento Open Source. Während des Projekts war ein Upgrade von Magento 2.4.6 → 2.4.7 erforderlich, um einen Sicherheitspatch zu unterstützen. Wir sequenzierten: Upgrade, dann Migration fortsetzen. Fügten 3 Wochen hinzu.

10-Wochen-Projekt, das 14 Wochen dauerte. Markenauffrischung, die während des Projekts an eine Migration angehängt wurde. Das Designteam produzierte in Woche 5 neue Mockups; das Entwicklungsteam musste 2 Wochen Arbeit wegwerfen und von den neuen Mockups neu aufbauen. Lektion: Design vor dem Bau.

In allen drei Fällen wurde die Überziehung durch Änderungen des Umfangs während des Projekts verursacht, nicht durch technische Probleme mit Hyvä. Die technische Arbeit ist gut erprobt; das Projektmanagement ist der Bereich, in dem die Dinge schiefgehen.

Wie wir Zeitrahmenverpflichtungen strukturieren

Wenn wir ein Angebot abgeben, ist der Zeitrahmen festgelegt auf den vereinbarten Umfang. Konkret:

• Jede Woche hat explizite schriftliche Lieferungen
• Jede Woche veröffentlichen wir den Fortschritt im Vergleich zum Plan
• Zusätze außerhalb des Umfangs führen zu einem neuen Angebot (Preis + Zeitrahmen), bevor wir sie anpacken
• Wenn wir einen Meilenstein verpassen, erfahren Sie in der Woche davon, in der er verschoben wird, nicht am Ende
• Das Umstellungsdatum verschiebt sich mit der Meilensteinverschiebung; wir komprimieren die späteren Wochen nicht, um aufzuholen

Das ist die praktische Bedeutung von "Festpreis, fester Zeitrahmen." Der Kompromiss: Wir akzeptieren keine Änderungen des Umfangs während des Projekts ohne ein neues Angebot.

Die Frage „Können wir schneller liefern?“

Häufige Anfrage. Manchmal ja, manchmal nein.

Schneller ist realistisch, wenn:

• Sie die Reaktionsfähigkeit der Stakeholder priorisieren können (UAT in 1 Tag statt 5)
• Sie bereit sind, Nice-to-Haves aus dem Umfang zu streichen
• Sie interne Entwicklerzeit für QA + UAT bereitstellen können
• Sie sich nicht in einem Verkaufsereignisfenster befinden oder um unseren Kalender konkurrieren

Schneller ist nicht realistisch, wenn:

• Ihre Erweiterungsliste Überraschungen hat
• Ihre Designtreue nicht festgelegt ist
• Ihr Team bereits überlastet ist (UAT wird verzögert)
• Sie darauf bestehen, dass Phase-2-Funktionen in Phase 1 geliefert werden

Wir sind ehrlich darüber, in welchem Fall Sie sich beim Scoping befinden. Manchmal ist die Antwort „ja, wir können in 6 Wochen statt 8 liefern“; manchmal ist es „nein, und Eile wird die Qualität beeinträchtigen.“ Wir sagen, was es ist.

Nächste Schritte

• Sehen Sie sich die Hyvä-Migrationsdienstseite an, um zu erfahren, was enthalten ist
• Lesen Sie Wie man Magento Luma in 8 Wochen zu Hyvä migriert für die wöchentliche Aufschlüsselung
• Lesen Sie Hyvä-Migrationskosten im Jahr 2026 für das Budget im Einzelposten
• Buchen Sie einen 30-minütigen Scoping-Anruf für ein Festpreis-, fester Zeitrahmen-Angebot