Lighthouse beim Shopsystem-Wechsel: Warum der Score erst einmal fällt
In fast jedem Migrationsprojekt gibt es den Moment, in dem jemand den neuen Shop durch Lighthouse schickt und eine schlechtere Zahl bekommt als im Altsystem. Das ist kein Unfall und meist auch kein Fehler — sondern die vorhersehbare Folge davon, wie der Score gebaut ist und was er gerade misst. Was die Zahl wirklich sagt, wann sie zählt und in welcher Reihenfolge man sie zurückholt.
Es gibt in Migrationsprojekten eine E-Mail, die mit erstaunlicher Zuverlässigkeit ankommt. Sie trifft irgendwo zwischen der zweiten Vorschau und der Go-live-Woche ein, sie kommt selten aus dem Projektteam, und sie enthält einen Screenshot. Auf dem Screenshot steht eine Zahl in einem Kreis, die Zahl ist rot, und darunter steht ein Satz in der Art: „Unser alter Shop hatte 74. Woran liegt das?“
Die ehrliche Antwort ist unbequem, weil sie nach einer Ausrede klingt: Der neue Shop ist an dieser Stelle vermutlich nicht langsamer. Er wird nur zum ersten Mal unter anderen Bedingungen gemessen — mit einer Funktionsausstattung, die das Altsystem so nie hatte, auf einer anderen Seite, an einem anderen Tag, mit einem Werkzeug, dessen Zahl kein Tempo ist, sondern ein gewichteter Mittelwert aus fünf Größen.
Das entwertet die Messung nicht. Lighthouse ist ein ausgezeichnetes Werkzeug, kostenlos, quelloffen, in jedem Chrome eingebaut. Es ist nur ein Diagnosewerkzeug und kein Zeugnis. Dieser Artikel handelt davon, wie man den Unterschied nutzt — und wie man den Wert nach dem Wechsel in der richtigen Reihenfolge zurückholt.
Was in dem Bericht eigentlich steht
Fünf Kategorien, fünf Fragen
Was ein Lighthouse-Bericht misst — und was er nicht beweist
Der Bericht liefert vier runde Zahlen und eine Quote. Das verleitet dazu, sie wie Schulnoten zu lesen. Nützlicher ist die dritte Spalte: Jede Kategorie hat einen klar umrissenen Zuständigkeitsbereich und endet genau dort, wo die eigentlich interessanten Fragen anfangen.
Performance
für Shops entscheidend0–100, gewichteter Mittelwert aus fünf Messwerten
- Misst
- Wie schnell sichtbarer Inhalt erscheint, wie lange der Hauptthread blockiert ist und wie stark das Layout dabei springt.
- Beweist
- Dass die geprüfte Seite unter genau diesen Laborbedingungen technisch sauber lädt.
- Beweist nicht
- Wie schnell Ihre Kundschaft den Shop erlebt. Das ist eine andere Messung mit anderen Werten.
Accessibility
für Shops entscheidend0–100, automatisiert prüfbare Regeln
- Misst
- Kontraste, Alternativtexte, Beschriftung von Bedienelementen, Dokumentstruktur.
- Beweist
- Dass die maschinell prüfbaren Barrierefreiheitsregeln eingehalten sind.
- Beweist nicht
- Dass der Shop bedienbar ist. Der maschinell prüfbare Anteil deckt schätzungsweise ein Drittel der Anforderungen ab — Tastaturbedienung und Fokusreihenfolge gehören nicht dazu.
Best Practices
für Shops wichtig0–100, Liste technischer Einzelprüfungen
- Misst
- HTTPS, veraltete Programmierschnittstellen, Konsolenfehler, Bildauflösungen, unsichere Einbindungen.
- Beweist
- Dass keine der bekannten technischen Altlasten offen im Quelltext liegt.
- Beweist nicht
- Dass der Shop sicher ist. Über Ihre App-Berechtigungen, Zugriffsrechte und Datenflüsse sagt die Kategorie nichts.
SEO
für Shops wichtig0–100, rund ein Dutzend Grundlagenprüfungen
- Misst
- Indexierbarkeit, Titel und Beschreibung, sprechende Verweise, gültige Auszeichnung strukturierter Daten.
- Beweist
- Dass die Seite technisch gefunden und gelesen werden kann.
- Beweist nicht
- Dass Sie ranken. Der Wert kennt weder Ihre Inhalte noch Ihre Weiterleitungen noch Ihren Wettbewerb — und genau dort entscheidet sich eine Migration.
Agentic Browsing
situativ relevantBestanden-Quote, kein 0–100-Wert
- Misst
- Ob ein automatisierter Agent die Seite versteht und bedienen kann: strukturierte Inhalte, stabile Bedienelemente, maschinenlesbare Hinweise.
- Beweist
- Dass eine Handvoll fester Prüfungen bestanden ist — als Zähler, etwa „3 von 4“.
- Beweist nicht
- Eine Rangfolge. Die Kategorie ist bewusst kein gewichteter Index, weil die Standards dafür noch entstehen.
Für einen Shop im Systemwechsel ist die Reihenfolge der Aufmerksamkeit damit vorgezeichnet: Performance und Accessibility beschreiben etwas, das Ihre Kundschaft unmittelbar spürt. Best Practices und SEO sind Hygieneprüfungen — dort ist ein Wert unter 90 ein Hinweis auf eine konkrete Nachlässigkeit, ein Wert von 100 aber kein Ergebnis, auf das man sich berufen sollte.
Der wichtigste Satz über Lighthouse wird in Projekten fast nie ausgesprochen: Ein Wert von 100 ist weder für jede Seite realistisch noch für jede Seite nötig. Der Score ist als Diagnose gebaut, nicht als Prüfungsnote — er soll Ihnen sagen, welche Datei zu groß und welches Skript zu teuer ist, nicht, ob Ihr Shop gut ist.
Für ein Migrationsprojekt folgt daraus eine praktische Regel, die zwei Drittel der Diskussionen erledigt: Der Bericht ist eine Arbeitsliste, keine Kennzahl. Er gehört ins Entwicklungsteam, nicht ins Reporting. Was ins Reporting gehört, steht weiter unten — es sind die Felddaten, und die sehen anders aus.
Der Score ist ein Mittelwert, und die Gewichte sind öffentlich
Woraus die eine Zahl entsteht
Drei von fünf Messwerten machen 80 Prozent des Performance-Scores aus
Der Performance-Score ist ein gewichteter Mittelwert, und die Gewichtung ist dokumentiert. Das ist deshalb wertvoll, weil sie die Reihenfolge der Arbeit vorgibt: Wer den schwersten Posten kennt, diskutiert nicht mehr darüber, ob zuerst die Bilder oder zuerst die Apps drankommen.
- TBT Total Blocking Time 30 %
Wie lange der Hauptthread blockiert ist, sodass die Seite auf Tippen und Wischen nicht reagiert.
Der Posten, der beim Wechsel am stärksten ausschlägt. Er hängt an JavaScript — also an Apps, Tracking und Drittanbieter-Skripten, nicht am Theme.
- LCP Largest Contentful Paint 25 %
Wann das größte sichtbare Element steht — auf Produktseiten fast immer das Produktbild.
Wird durch Bildformate, Bildgrößen und Ladepriorität entschieden. Auf Shopify weitgehend im Theme lösbar, in ein bis zwei Tagen.
- CLS Cumulative Layout Shift 25 %
Wie stark das Layout nachträglich springt, während die Seite fertig lädt.
Entsteht durch Elemente ohne reservierten Platz: Bannerleisten, Bewertungssterne, Größentabellen, nachgeladene Schriften.
- FCP First Contentful Paint 10 %
Wann überhaupt der erste Inhalt sichtbar wird.
Auf Shopify selten ein Problem — die Auslieferung liegt auf deren Infrastruktur, nicht auf Ihrem Server.
- SI Speed Index 10 %
Wie zügig sich der sichtbare Bereich insgesamt füllt.
Folgt in aller Regel den anderen vier. Ein eigener Arbeitsschritt dafür lohnt fast nie.
Diese Tabelle ist der nützlichste Einzelfund für jedes Migrationsprojekt, weil sie eine Diskussion beendet, die sonst nach Geschmack entschieden wird: Womit fängt man an?
Zwei Beobachtungen daraus tragen den größten Teil der Arbeit.
Erstens: Der schwerste Posten ist kein Theme-Problem. Total Blocking Time trägt 30 Prozent und misst, wie lange der Hauptthread mit JavaScript beschäftigt ist. JavaScript kommt in einem Shopify-Shop überwiegend nicht aus dem Theme, sondern aus Apps, aus Tracking und aus Skripten von Drittanbietern. Dieser Posten sinkt also nicht, wenn jemand besseren Code schreibt, sondern wenn jemand eine Auswahl trifft. Das ist eine Managemententscheidung, keine Entwicklungsaufgabe — und der Grund, warum diese Optimierungsrunde in Projekten so oft im Kreis läuft.
Zweitens: Zwei Drittel des lösbaren Teils sind Handwerk. Largest Contentful Paint und Cumulative Layout Shift ergeben zusammen 50 Prozent. Beide werden im Theme entschieden: Bildformate, Bildgrößen, Ladepriorität für das erste sichtbare Bild und reservierte Flächen für alles, was nachgeladen wird. Das ist gut umrissene Arbeit mit absehbarem Aufwand, und sie steht in keinem Konflikt mit irgendwelchen Marketing-Interessen. Deshalb sollte sie zuerst passieren — nicht weil sie am meisten bringt, sondern weil sie ohne Abstimmungsrunde erledigt werden kann.
First Contentful Paint und Speed Index stehen zusammen für 20 Prozent und folgen den anderen dreien fast immer nach. Eine eigene Arbeitsrunde dafür lohnt in der Praxis nie.
Die Unterscheidung, an der die meisten Gespräche scheitern
Zwei Messungen, ein Missverständnis
Lighthouse misst im Labor. Bewertet werden Sie im Feld.
Beide Messungen tragen dieselben Namen und liefern verschiedene Zahlen. Das ist kein Fehler, sondern Absicht: Die eine soll Ursachen finden, die andere soll Wirklichkeit abbilden. Erst wenn man weiß, welche Zahl gerade auf dem Tisch liegt, lässt sich sinnvoll über sie streiten.
Labor Lighthouse, PageSpeed Insights
- Ein einzelner Durchlauf, auf Knopfdruck wiederholbar
- Simuliertes Mittelklasse-Telefon, künstlich gedrosseltes Netz
- Ihr Standort, Ihre Verbindung, keine Anmeldung, kein Warenkorb
- Ergebnis in Sekunden, auch für eine Seite, die noch niemand kennt
Zweck Ursachen finden. Der Bericht sagt, welche Datei, welches Skript, welches Bild.
Feld Chrome-Nutzerdaten, eigenes Monitoring
- 28 Tage echter Aufrufe, zusammengefasst über alle Besuche
- Echte Geräte, echte Netze, echte Kundschaft, auch im Funkloch
- Alle Seiten, auch Warenkorb und angemeldete Bereiche
- Reagiert träge: eine Verbesserung wird erst nach Wochen sichtbar
Zweck Bewerten. Das ist die Datenlage, auf die sich Google beruft.
Wenn Sie aus diesem Artikel eine einzige Sache mitnehmen, dann diese: Der Lighthouse-Score und die Werte, auf die Google sich beruft, sind zwei verschiedene Messungen. Die eine entsteht in einer künstlichen Umgebung auf Knopfdruck, die andere aus 28 Tagen echter Besuche.
Das ist keine Spitzfindigkeit, sondern hat drei sehr konkrete Folgen für ein Migrationsprojekt.
Eine Verbesserung im Labor ist am nächsten Tag sichtbar, im Feld erst nach Wochen. Die Felddaten sind ein gleitender Durchschnitt über 28 Tage. Wer in der Go-live-Woche optimiert und in der Woche darauf nachsieht, sieht dort noch überwiegend den alten Shop. Diese Verzögerung ist in Projekten eine verlässliche Quelle für Fehlschlüsse — meistens für den falschen Schluss, die Optimierung habe nichts gebracht.
Nach einem Domainwechsel oder einem Relaunch beginnen die Felddaten neu. Wenn Ihr Shop nach der Migration unter neuen Adressen läuft, dauert es Wochen, bis überhaupt genug echte Aufrufe für eine belastbare Auswertung zusammengekommen sind. In dieser Zeit ist Lighthouse tatsächlich das Einzige, was Sie haben — und genau in dieser Zeit sollten Sie es am vorsichtigsten interpretieren.
Die Größe, die Ihre Kundschaft am deutlichsten spürt, kommt in Lighthouse gar nicht vor. INP misst, wie schnell der Shop auf ein Antippen reagiert. Es ist eines der drei Core Web Vitals und im Lighthouse-Bericht schlicht nicht enthalten. An seiner Stelle steht Total Blocking Time als Stellvertreter. Der korreliert gut genug, um damit zu arbeiten, aber er ist nicht dasselbe. Ein Shop kann im Labor solide aussehen und sich auf einem drei Jahre alten Android-Telefon trotzdem zäh anfühlen.
Warum der Wert nach dem Wechsel zuverlässig fällt
Der Verlauf, den niemand ankündigt
Der Tiefpunkt fällt in die Go-live-Woche — und das ist kein Zufall
Der Rohbau eines neuen Shopify-Themes misst besser als jedes gewachsene Altsystem, weil noch nichts darin ist. Von da an kostet jede Funktion Punkte. Wer diese Kurve vorher kennt, führt in Woche elf ein anderes Gespräch als jemand, der sie zum ersten Mal sieht.
- 1 Der Wert, gegen den verglichen wird 74
Gemessen auf der Startseite des alten Shops, meist vor Jahren und ohne festgehaltene Bedingungen. Genau dieser Wert wird später zitiert.
- 2 Das neue Theme, noch leer 96
Kein Tracking, keine Bewertungen, kein Einwilligungsbanner, keine Produktdaten. Dieser Wert wird gern in Statusrunden gezeigt und hält keine Woche.
- 3 Die Funktionen sind eingezogen 58
Bewertungen, Suche, Newsletter, Größentabelle, Wunschliste. Jede App bringt eigenes JavaScript mit, und Total Blocking Time ist der schwerste Posten im Score.
- 4 Der Tiefpunkt, und alle sehen ihn 49
Jetzt kommen Marketing-Skripte, Einwilligungsbanner und Tracking dazu. Zeitgleich misst zum ersten Mal jemand nach, der nicht im Projekt sitzt.
- 5 Skripte gezählt und gestrichen 67
Die günstigste Runde des ganzen Projekts: doppeltes Tracking entfernen, Apps ohne Nutzung deinstallieren, Reste alter Apps aus dem Theme werfen.
- 6 Bilder, Ladepriorität, reservierte Flächen 84
Largest Contentful Paint und Cumulative Layout Shift zusammen — 50 Prozent des Scores, lösbar im Theme und ohne Grundsatzentscheidung.
- 7 Der Wert, mit dem Sie leben 88
Über 90 ist mit vollem Funktionsumfang selten und meist auch nicht nötig. Ab hier zählen die Felddaten, nicht mehr der Laborwert.
Diese Kurve hat fünf Ursachen, und keine davon ist ein Fehler im neuen Shop. Es lohnt sich, sie zu kennen, weil man dann die richtige Frage stellt.
Es werden zwei verschiedene Dinge verglichen. Der Wert des Altsystems stammt fast immer von der Startseite und wurde zu unbekannten Bedingungen erhoben. Der neue Wert stammt oft von einer Produktseite mit Bewertungen, Größentabelle, Verfügbarkeitshinweis und Cross-Selling. Die Startseite eines Shops ist die am besten optimierte Seite, die es gibt. Produktseiten sind es nie.
Die Funktionen sind mitgewachsen. Kaum ein Shop wird beim Wechsel eins zu eins nachgebaut. Es kommen Bewertungen dazu, eine bessere Suche, ein Konfigurator, ein Wunschzettel. Jede dieser Funktionen ist bewusst bestellt worden, und jede bringt JavaScript mit. Der Score misst das korrekt — er kann nur nicht wissen, dass es beabsichtigt war.
Der Einwilligungsdialog wird selten mitgedacht. Er lädt früh, blockiert oft und verschiebt regelmäßig das Layout. In vielen Shops ist er der teuerste Einzelposten im gesamten Bericht, und in kaum einem Projekt taucht er in der Performance-Diskussion auf, weil er als Rechtsthema geführt wird.
Der Rohbau war der Referenzwert, und das war ein Fehler. Der Zwischenstand mit leerem Theme misst 95 und mehr. Diese Zahl wandert in einen Statusbericht und wird stillschweigend zur Erwartung. Sie bedeutet aber nur, dass der Shop zu diesem Zeitpunkt noch nichts konnte.
Ein einzelner Durchlauf schwankt. Netzqualität, Auslastung des Rechners, Browser-Erweiterungen, laufende A/B-Tests, Antwortzeiten von Drittanbietern: Zwei Messungen derselben Seite im Abstand von fünf Minuten können sich um zehn Punkte unterscheiden. Wer einmal misst, misst Rauschen.
Ein Messprotokoll, das eine Diskussion aushält
Der Aufwand für eine belastbare Messung ist überschaubar, und er lohnt sich vor allem deshalb, weil er die Zahl aus dem Bereich der Meinung herausholt. Sechs Punkte reichen.
Messen Sie vor dem Wechsel, nicht danach. Der Ausgangswert des Altsystems muss erhoben werden, solange das Altsystem noch läuft — mit demselben Protokoll, das Sie später auf den neuen Shop anwenden. Diese halbe Stunde ist die einzige Gelegenheit dafür, und sie ist unwiederbringlich.
Messen Sie Seitentypen, nicht Seiten. Startseite, eine Kategorieseite mittlerer Größe, eine typische Produktseite, eine Produktseite mit vielen Varianten, der Warenkorb. Fünf Adressen, festgehalten in einer Liste, in beiden Systemen dieselben Typen. Lighthouse prüft immer nur eine einzelne Adresse — eine Aussage über „den Shop“ entsteht erst durch diese Auswahl.
Messen Sie fünfmal und nehmen Sie den Median. Nicht den besten Wert, nicht den letzten, den mittleren. Das kostet pro Seite drei Minuten und entfernt den größten Teil der Schwankung.
Halten Sie die Bedingungen fest. Mobil oder Desktop, privates Fenster ohne Erweiterungen, gleiche Tageszeit, gleicher Ort, notiert im selben Dokument wie die Zahlen. Eine Messung ohne notierte Bedingungen ist beim nächsten Mal wertlos, weil sie sich nicht wiederholen lässt.
Trennen Sie Labor und Feld sauber. Der Lighthouse-Wert gehört ins Entwicklungsteam als Arbeitsliste. Ins Reporting gehören die Felddaten aus der Google Search Console — dort, wo die drei Core Web Vitals als Anteil bestandener Aufrufe stehen. Das ist die Zahl, die eine Geschäftsführung interessieren sollte, weil sie echte Besuche beschreibt.
Messen Sie den Rohbau ruhig, aber schreiben Sie ihn nicht auf. Der Wert des leeren Themes ist als Ausgangspunkt nützlich und als Kennzahl irreführend. Er gehört in kein Dokument, das jemand später wiederfindet.
Die Reihenfolge, in der repariert wird
Die Empfehlung, „erst die Fehler mit dem größten Einfluss“ zu beheben, ist richtig und hilft niemandem, weil der Bericht selbst nicht sagt, was das ist. In Shopify-Projekten hat sich eine konkretere Reihenfolge bewährt.
- Skripte zählen, bevor irgendetwas optimiert wird. Wie viele Apps laden auf der Produktseite JavaScript? Welche davon werden benutzt? Welche sind Reste einer Anwendung, die längst deinstalliert ist, deren Codeschnipsel aber noch im Theme steht? Diese Liste ist in zwei Stunden erstellt und streicht in fast jedem Shop zwischen drei und acht Einträge.
- Doppeltes Tracking entfernen. Nach einer Migration laufen erfahrungsgemäß zwei Analyse-Werkzeuge parallel, weil niemand das alte abschalten wollte, bevor das neue nachweislich funktioniert. Setzen Sie dafür ein Datum.
- Das erste sichtbare Bild priorisieren. Auf Produktseiten ist das Produktbild fast immer das größte Element. Richtiges Format, richtige Größe, hohe Ladepriorität, kein verzögertes Nachladen für das, was sofort sichtbar ist. Das ist der schnellste messbare Gewinn im gesamten Projekt.
- Flächen reservieren für alles, was nachlädt. Bewertungssterne, Verfügbarkeitshinweise, Bannerleisten, der Einwilligungsdialog. Jedes Element, das ohne festen Platz erscheint, verschiebt das Layout und kostet 25 Prozent des Scores anteilig mit.
- Den Einwilligungsdialog anfassen. Er ist ein Performance-Thema, auch wenn er als Rechtsthema geführt wird. Eigene Auslieferung statt fremder Domain, so früh wie nötig und so klein wie möglich.
- Erst danach über das Theme reden. Wenn die ersten fünf Punkte erledigt sind und der Wert immer noch nicht trägt, ist es tatsächlich Theme-Arbeit. Was dort zählt, haben wir in Mobile First auf Shopify im Detail aufgeschrieben.
Der Punkt an dieser Reihenfolge ist nicht, dass sie schneller wäre. Sie ist billiger: Die ersten beiden Schritte kosten keine Entwicklungszeit, sondern Entscheidungen — und sie bewegen ausgerechnet den Posten, der mit 30 Prozent am schwersten wiegt.
Checkliste
Performance-Messung im Migrationsprojekt: zwölf Punkte
Die ersten drei Punkte müssen erledigt sein, solange das Altsystem noch läuft — danach sind sie nicht mehr nachholbar. Ihre Häkchen bleiben in diesem Browser gespeichert.
0 von 12 erledigt
Was für Ihre Ausgangslage sinnvoll ist
| Ihre Situation | Empfehlung |
|---|---|
| Migration steht bevor, Altsystem läuft noch | Diese Woche die Ausgangswerte erheben — Labor und Felddaten. Später ist die Vergleichsgrundlage weg |
| Rohbau misst 95, Geschäftsführung hat es gesehen | Jetzt einordnen, nicht nach dem Go-live. Ein Satz im Statusbericht spart eine Eskalation |
| Score fiel nach dem Go-live um 30 Punkte | Normal. Erst Skripte zählen, dann Bilder — nicht umgekehrt anfangen |
| Neue Domain, Felddaten noch leer | Vier bis acht Wochen einplanen, bis wieder bewertet werden kann. Solange Lighthouse nur als Diagnose lesen |
| Score gut, Shop fühlt sich trotzdem zäh an | Das ist der INP-Fall. Felddaten heranziehen, nicht weiter im Labor suchen |
| Über 15 Apps installiert | Der lohnendste Posten im ganzen Projekt. Eine Auswahlentscheidung, keine Entwicklungsaufgabe |
| Zwei Analyse-Werkzeuge laufen parallel | Abschaltdatum setzen. Das ist der billigste Punkt auf der Liste |
| Score schwankt zwischen zwei Messungen stark | Nicht deuten, sondern fünfmal messen und den Median nehmen |
| Accessibility-Wert bei 100 | Kein Ergebnis. Der maschinell prüfbare Anteil ist etwa ein Drittel — Tastaturbedienung separat testen |
| SEO-Wert bei 100, Sichtbarkeit gefallen | Zwei verschiedene Dinge. Die Ursache liegt bei den Weiterleitungen, nicht im Bericht |
Was Sie aus diesem Artikel mitnehmen sollten
Der Lighthouse-Score ist beim Systemwechsel weder wertlos noch aussagekräftig — er ist ein Werkzeug mit einem klar umrissenen Zweck, das regelmäßig für einen anderen benutzt wird.
Drei Punkte tragen den größten Teil des Ergebnisses:
Der Ausgangswert wird vor der Migration erhoben, nicht danach. Ohne eine mit festgehaltenen Bedingungen gemessene Vergleichsbasis im Altsystem ist jede spätere Diskussion über „besser oder schlechter“ eine Meinungsfrage. Diese halbe Stunde bekommen Sie kein zweites Mal.
Der Bericht ist eine Arbeitsliste, die Felddaten sind die Kennzahl. Lighthouse gehört ins Entwicklungsteam, die Core Web Vitals aus der Search Console ins Reporting. Wer beides vermischt, optimiert die falsche Zahl und erklärt der Geschäftsführung Schwankungen, die nur Messrauschen sind.
Der schwerste Posten ist eine Entscheidung, kein Codeproblem. Total Blocking Time trägt 30 Prozent und hängt an Apps und Skripten. Man kann ihn nicht wegprogrammieren, man kann ihn nur auswählen. Deshalb beginnt die Optimierung mit einer Liste und nicht mit einem Editor.
Wer diese drei Punkte beherzigt, führt in der Go-live-Woche kein Krisengespräch, sondern eine Terminfrage: Der Wert ist gefallen, das war so erwartet, hier steht, wann er wieder oben ist. Wie sich solche Punkte in den Gesamtablauf einordnen, steht in Wie lange dauert ein Shopsystem-Wechsel; welche Risiken in Migrationen tatsächlich eintreten, haben wir in Risikomanagement beim Plattformwechsel beschrieben, und die Frage, welche Funktionen überhaupt eine eigene App brauchen, klärt Custom Liquid oder Custom App.
Wenn bei Ihnen ein Wechsel ansteht und Sie wissen wollen, wo Ihr künftiger Shop wirklich stehen wird — welche Ihrer Apps den Score kosten, welche Werte realistisch sind und was davon vor dem Go-live erledigt sein muss: Lassen Sie uns sprechen. Wie wir Migrationen insgesamt aufsetzen, steht auf Shopsystem-Migration.
