Der Migrationsumfang wird häufig zu spät und zu ungenau definiert. Viele Teams beginnen mit einer Exportliste, den Mengen einzelner Datenkategorien oder der Annahme, dass einfach alles übertragen werden sollte. Das wirkt vorsichtig, umgeht aber meist die wichtigere Planungsfrage: Was muss das Unternehmen nach der Migration weiterhin tun können?
Ein Shop hängt nicht nur davon ab, dass Datensätze vorhanden sind. Products müssen weiterhin kommerziell nutzbar sein, Navigationspfade verständlich bleiben, Customer- und Order-Historie operative Abläufe unterstützen und kontinuitätskritische Seiten weiterhin ihren Zweck erfüllen. Wenn der Umfang nur anhand von Mengen definiert wird, können wichtige Verluste bis zu einer späten Prüfung unbemerkt bleiben.
Eine belastbarere Definition beginnt deshalb mit der geschäftlichen Bedeutung, die erhalten werden muss. Bevor festgelegt wird, was zum Umfang gehört, sollte das Unternehmen entscheiden, was nach dem Go-live weiterhin gelten muss, welche Unterschiede akzeptabel sind und welche Bereiche vor der Ausführung genauer geprüft werden müssen.
Der Migrationsumfang ist eine Planungsgrenze, nicht nur eine Datenliste
Der Migrationsumfang sollte die Grenze dessen definieren, wofür das Projekt beim Erhalten, Verändern, Ausschließen oder Prüfen verantwortlich ist. Diese Grenze ist breiter als eine Liste von Datensatzarten, weil nutzbare Shopdaten meist von Beziehungen, Funktionen und Geschäftskontext abhängen.
Eine praktische Umfangsdefinition sollte klären:
- welche Geschäftsergebnisse nach dem Go-live weiterhin nutzbar sein müssen;
- welche Datenkategorien, Content-Typen und unterstützenden Strukturen enthalten sind;
- welche Datensätze oder historischen Zeiträume bewusst ausgeschlossen werden können;
- welche Plattformunterschiede akzeptabel sind, wenn die geschäftliche Bedeutung erhalten bleibt;
- welche Bereiche eine Stichprobenprüfung benötigen, bevor der Migrationsansatz als sicher gelten kann;
- welche Verantwortlichen bestätigen sollen, ob das Ergebnis akzeptabel ist.
Dadurch wird der Umfang zu einem Steuerungsinstrument. Er schafft die Grundlage für Entscheidungen darüber, was übertragen werden muss, was sich ändern darf, was bereinigt werden kann und was nicht als Go-live-Anforderung behandelt werden sollte.
Beginnen Sie mit den zu erhaltenden Ergebnissen
Eine sinnvolle Umfangsplanung beginnt mit Ergebnissen und nicht mit Exportkategorien. Die wichtigste Frage ist nicht nur, ob Products, Customers, Orders, Categories oder Content übertragen werden können. Entscheidend ist, ob der migrierte Shop die geschäftlich wichtigen Tätigkeiten weiterhin unterstützt.
Typische zu erhaltende Ergebnisse sind:
| Ergebnisbereich | Was der Umfang schützen muss | Beispiel für den Prüffokus |
|---|---|---|
| Kaufverhalten bei Products | Kundinnen und Kunden können die vorgesehenen Products auswählen und kaufen | Varianten, Optionen, Preise, Bestandsbedeutung, Bilder, Product-Status |
| Katalogauffindbarkeit | Products bleiben über erwartete Navigationswege auffindbar | Categories, Collections, Filter, Suchfelder, Landingpages |
| Customer-Kontinuität | Mitarbeitende können Customer-Kontext nach dem Go-live weiterhin verstehen | Konten, Adressen, Order-Referenzen, Einwilligungsstatus, Segmentierungsrelevanz |
| Operative Nutzbarkeit | Interne Teams können wichtige Abläufe fortsetzen | Order-Historie, Referenzen zur Auftragsabwicklung, Supportnotizen, externe Kennungen |
| Kommerzielle Kontinuität | Umsatzkritische Regeln bleiben bewusst erhalten oder werden gezielt neu aufgebaut | Promotions, Coupons, Preisregeln, Steuerkontext, wichtige Customer-Gruppen |
| SEO-Kontinuität | Wichtige Seiten bleiben erreichbar und erfüllen weiterhin ihren Zweck | URLs, Weiterleitungen, Metadaten, Content-Seiten, hochwertige Landingpfade |
Wer mit Ergebnissen beginnt, verhindert einen zu breiten oder zugleich zu oberflächlichen Umfang. So lässt sich erkennen, welche Daten wesentlich sind, welche nützlich, aber nicht kritisch sind und welche historischen oder veralteten Informationen ohne Beeinträchtigung der Go-live-Bereitschaft ausgeschlossen werden können.
Kerndatenkategorien und unterstützende Strukturen identifizieren
Der Umfang beginnt häufig mit Kerndatenkategorien, sollte dort aber nicht enden. Kerndatensätze entfalten ihren Wert meist nur dann, wenn auch ihre unterstützenden Strukturen mit ausreichender Bedeutung erhalten bleiben.
Typische Kernkategorien sind:
- Products;
- Customers;
- Orders;
- Categories oder Collections;
- Reviews;
- Coupons und Promotions;
- Steuern und zugehörige Konfigurationsreferenzen;
- CMS Pages;
- Blog Posts, wenn Traffic, Conversion oder Kontinuität von ihnen abhängen.
Auch unterstützende Strukturen benötigen häufig eine ausdrückliche Umfangsentscheidung:
- Varianten und Product-Optionen;
- Product- und Variantenbilder;
- Product-Attribute für Filter, Vergleich oder Merchandising;
- Customer-Adressen und Kontostatus;
- Product-Beziehungen, Bundles, gruppierte Artikel oder Cross-Selling-Regeln;
- Category-Zuordnungsregeln und Navigationspfade;
- Berechtigungsregeln für Promotions und Coupon-Bedingungen;
- SEO-kritische URLs, Metadaten, Weiterleitungen und Landingpfade;
- operative Metadaten für Reporting, Support, Auftragsabwicklung oder externe Systeme;
- von Apps, Plugins, Modulen oder Erweiterungen verwaltete Felder, die Storefront- oder Adminfunktionen beeinflussen.
Auch ein kleiner Shop kann einen breiten Umfang haben, wenn seine kommerziellen Abläufe von mehreren Strukturebenen abhängen. Ein größerer Shop kann dagegen einen engeren Go-live-Umfang haben, wenn ungenutzte historische Daten bewusst ausgeschlossen werden und klar definiert ist, was nutzbar bleiben muss.
Muss erhalten bleiben, darf transformiert werden, optional und ausgeschlossen unterscheiden
Der Umfang lässt sich leichter steuern, wenn jeder wesentliche Datenbereich einen Planungsstatus erhält. Nicht alle enthaltenen Daten müssen identisch erhalten werden, und nicht alle ausgeschlossenen Daten bedeuten einen Verlust.
| Umfangsklassifizierung | Bedeutung | Beispiel |
|---|---|---|
| Muss erhalten bleiben | Das Geschäftsergebnis darf sich nicht sicherheitsrelevant verändern | Bestseller müssen ihre Kauflogik und Order-Bedeutung behalten |
| Darf transformiert werden | Die Struktur darf sich ändern, wenn die geschäftliche Bedeutung akzeptabel erhalten bleibt | Category-Bäume können auf der Zielplattform als Collections oder Navigationsgruppen umgesetzt werden |
| Kann bereinigt werden | Daten sollten korrigiert oder konsolidiert werden, weil dies Unklarheiten oder Risiken reduziert | Doppelte Attributwerte können normalisiert werden, bevor sie die Filterprüfung beeinflussen |
| Kann ausgeschlossen werden | Für Go-live oder laufende Abläufe nicht erforderlich | Veraltete Products, abgelaufene Kampagnen, alte Test-Customers, ungenutzte Content-Entwürfe |
| Benötigt besondere Prüfung | Die Anforderung kann über die übliche Plattform-zu-Plattform-Behandlung hinausgehen | Benutzerdefinierte Felder, externe Systemkennungen, Erweiterungsdaten, ungewöhnliche Regelwerke |
Diese Einteilung verhindert, dass jedes Ergebnis, das anders aussieht, automatisch als Fehler gilt. Manche Unterschiede sind akzeptabel. Manche sind sogar Verbesserungen. Andere stellen echte Risiken für die Kontinuität dar. Die Umfangsplanung sollte diese Unterschiede sichtbar machen, bevor die Prüfung beginnt.
Festlegen, was funktional gleichwertig bleiben muss
Die höchste Priorität im Umfang haben Daten und Funktionen, die nach der Migration funktional gleichwertig bleiben müssen. Funktionale Gleichwertigkeit bedeutet nicht immer identische Struktur. Sie bedeutet, dass der migrierte Shop weiterhin dasselbe praktische Geschäftsergebnis unterstützt.
Typische Beispiele sind:
- umsatzstarke Products mit intakter Kauflogik;
- Customer- und Order-Beziehungen, die für Support benötigt werden;
- Category- oder Collection-Strukturen, die wichtige Navigationsabsichten abbilden;
- umsatzkritische Promotions und Preisregeln;
- Customer-Gruppen oder Segmente, die Preise, Zugriff, Kommunikation oder Serviceabläufe beeinflussen;
- hochwertige Seiten mit relevantem Traffic, Conversion-Beitrag oder Markenwirkung.
Diese Bereiche sollten die Auswahl der Stichproben und die Validierungspriorität bestimmen. Sie dürfen nicht erst geprüft werden, nachdem sämtliche Daten übertragen wurden. Wenn sich ein Bereich, der erhalten bleiben muss, auf der Zielplattform anders verhält, braucht das Team frühzeitig eine Entscheidung, ob der Unterschied akzeptabel, transformierbar oder ein Umfangsproblem ist.
Entscheiden, was sich in der Darstellung ändern darf
Einige Elemente müssen erhalten bleiben, obwohl die Zielplattform sie anders abbildet. Besonders zwischen Plattformen mit unterschiedlichen Katalog-, Customer-, Content- oder Promotion-Modellen existiert häufig keine direkte Eins-zu-eins-Struktur.
Typische Beispiele sind:
- Category-Logik, die als Collections, Menüs, Tags oder Landingpages dargestellt wird;
- Customer-Gruppen, die als Segmente, Tags, Listen oder Regeln umgesetzt werden;
- Product-Attribute, die als Felder, Metafelder, Spezifikationen, Optionswerte oder Filterquellen erscheinen;
- CMS-Content, der über einen anderen Page Builder, ein anderes Theme oder Blockmodell umgesetzt wird;
- Promotion-Logik, die über eine andere Regel- oder Rabattengine realisiert wird.
Solche Änderungen sind nicht automatisch Fehler. Sie sind Umfangsentscheidungen. Entscheidend ist, ob die geschäftliche Bedeutung in der neuen Darstellung erhalten bleibt. Wenn Kundinnen und Kunden Products weiterhin richtig finden, beurteilen und kaufen können, kann ein Strukturunterschied akzeptabel sein. Wenn er Preise, Berechtigung, Auffindbarkeit, Supportnutzbarkeit oder Reporting-Bedeutung verändert, muss er genauer geprüft werden.
Bereiche mit sensiblen Beziehungen früh benennen
Viele Umfangsprobleme entstehen durch Beziehungen und nicht durch fehlende Datensätze. Products, Customers, Orders, Reviews, Coupons und Content hängen häufig von anderen Datensätzen ab, um ihre Bedeutung zu behalten.
Beispiele für beziehungsabhängige Bereiche sind:
- Orders mit korrekten Customer- und Product-Referenzen;
- Reviews mit richtigen Products, Customers, Bewertungsstatus und Moderationsstatus;
- Coupons mit richtigen Product-, Category-, Customer- oder Datumsbedingungen;
- Products mit sinnvollem Category-, Hersteller-, Steuer-, Bestands- und Medienkontext;
- Customer-Datensätze mit Adressen, Order-Historie, Einwilligungsstatus oder Kontostatus;
- Content-Seiten mit URL-, Weiterleitungs-, Bild-, Metadaten- und Navigationskontext.
Die Umfangsplanung muss nicht jede Beziehung technisch im Detail beschreiben. Diese Tiefe gehört in die weiterführende Analyse von Datenbeziehungen. Sie sollte aber markieren, wo zusammenhängende Bedeutung wichtig ist. Andernfalls kann ein Projekt die erwarteten Datensatzmengen erreichen und dennoch den Kontext verlieren, der die Daten nutzbar macht.
Drittanbieter- und individuelle Logik als Umfangssignal behandeln
Der Umfang wird oft unterschätzt, weil Teams sichtbaren Storefront-Content inventarisieren, aber verborgene Felder, Regeln, Kennungen und von Erweiterungen verwaltete Daten übersehen, die für den Betrieb des Shops wichtig sind.
Zu dieser verborgenen Ebene können gehören:
- benutzerdefinierte Product-Felder für Darstellung, Filter, Merchandising oder Reporting;
- von Apps, Plugins, Modulen oder Erweiterungen verwaltete Loyalty-, Review-, Abo-, Such- oder Personalisierungsfunktionen;
- Order-Metadaten für Support, Erstattungen, Auftragsabwicklung oder Reporting;
- Kennungen für ERP-, CRM-, Versand-, Steuer-, Marketing-Automation- oder Marketplace-Systeme;
- individuelle Collection-, Landingpage- oder Navigationslogik;
- Geschäftsregeln außerhalb der Plattform, die Shopfunktionen beeinflussen.
Wenn diese Elemente Umsatz, Auffindbarkeit, Betrieb oder Customer-Kontinuität wesentlich beeinflussen, gehören sie früh in die Umfangsplanung. Sie sollten nicht erstmals während der abschließenden Validierung auftauchen.
Wichtige individuelle Logik sollte außerdem nach Geschäftswert klassifiziert werden. Manche Felder sind nur historisch. Manche sind für die Administration nützlich. Andere sind für Customer Experience, Preisbildung, Auftragsabwicklung oder die Kontinuität externer Systeme unverzichtbar. Nur die wesentlichen und operativ relevanten Bestandteile sollten den Umfang erweitern.
Selektive Migration bewusst einsetzen
Eine selektive Migration kann eine sinnvolle Planungsentscheidung sein. Viele Unternehmen benötigen nicht sämtliche historischen Datensätze, um go-live-bereit zu sein.
Ein selektiver Umfang kann beispielsweise priorisieren:
- aktive Products und aktuelle Katalogstrukturen;
- aktive Customers;
- aktuelle Orders, die für Support oder Buchhaltungsreferenzen benötigt werden;
- hochwertige CMS Pages und Blog Posts;
- wichtige Categories, Collections, URLs und Landingpages;
- Datensätze, die von externen Systemen oder Abläufen nach dem Go-live benötigt werden.
Selektive Migration ist jedoch nicht automatisch einfach. Sie wird komplexer, wenn die Auswahlregel präzise oder beziehungsabhängig ist oder die Bedeutung verknüpfter Datensätze verändern kann. Wenn beispielsweise nur aktuelle Orders migriert werden, die zugehörigen Customers, Products, Coupons oder Referenzen zur Auftragsabwicklung aber fehlen, kann die Order-Historie praktisch deutlich weniger nützlich sein.
Ein selektiver Umfang sollte deshalb über Geschäftsergebnisse und nicht nur über Reduktionsziele definiert werden.
Filterregeln vor der Ausführung planen
Filterentscheidungen sollten vor der Ausführung geplant werden. Geschätzte Mengen je Datenkategorie helfen bei Planung und Auswahl des Kapazitätsplans, legen aber nicht automatisch fest, welche Datensätze übertragen werden sollen.
Eine Filterentscheidung sollte klären:
- welche Datensätze aufgenommen werden;
- welche Datensätze ausgeschlossen werden;
- warum die Auswahlregel das Geschäftsziel unterstützt;
- ob die Regel verknüpfte Daten beeinflusst;
- ob die Auswahl nach der Migration validiert werden kann;
- wer die Folgen des ausgeschlossenen Verlaufs akzeptiert.
Einige Filteranforderungen sind einfach, etwa inaktive Products auszuschließen oder nur Orders nach einem bestimmten Datum zu übertragen. Andere sind komplexer, insbesondere wenn sie von mehreren Bedingungen, benutzerdefinierten Feldern, Statuswerten von Drittanbietern, externen Kennungen oder Beziehungsregeln abhängen. Wenn Filteranforderungen über standardmäßige Auswahllogik hinausgehen, muss die Anforderung gegebenenfalls im Rahmen einer gezielten Datensatzfilterung oder eines individuellen Migrationsdesigns geprüft werden.
Umfangsvolumen und Preisbestandteile getrennt betrachten
Der Umfang wirkt sich auf unterschiedliche Weise auf den Preis aus. Diese Effekte sollten nicht in einer einzigen Schätzung zusammengefasst werden. Das Datensatzvolumen bestimmt die erforderliche Kapazität. Die Ausführungsverantwortung beeinflusst Koordination und Arbeitsaufwand. Filter-, Mapping- und Konfigurationsanpassungen erzeugen begrenzten Zusatzaufwand. Nicht-standardmäßige Anforderungen decken Anpassungen oder Änderungen ab, die über die gewöhnlichen Möglichkeiten hinausgehen.
| Umfangsentscheidung | Preiseffekt |
|---|---|
| Anzahl von Products, Customers, Orders und Blog Posts | Bestimmt den erforderlichen Kapazitätsplan oder zusätzliche Kapazität. |
| Kundengeführte oder expertengestützte Ausführung | Verändert die Annahmen zu Verantwortung, Koordination und Kosten des Projekts. |
| Gezielte Filterung, Mapping oder Konfiguration | Fügt begrenzten Zusatzaufwand hinzu, wenn relevant. |
| Benutzerdefinierte Felder, Drittanbieterdaten, Custom Platform Handling, individuelle Transformation oder individuelles Filter-/Mapping-Verhalten | Kann eine Prüfung des individuellen Migrationsdesigns und einen separat akzeptierten Custom-Umfang erfordern. |
Diese Trennung verhindert zwei gegensätzliche Fehler. Ein großer Shop sollte nicht allein deshalb als individuelles Migrationsdesign eingestuft werden, weil mehr Kapazität benötigt wird. Ein kleinerer Shop sollte umgekehrt nicht automatisch als einfach gelten, wenn geschäftskritische Daten eine maßgeschneiderte Behandlung benötigen. Der Umfang sollte Volumen, Zuständigkeit, Transformationsanforderungen und erwartete Nachweise dokumentieren, bevor Migrationsansatz und Preise geprüft werden.
Akzeptable Änderungen vor Beginn der Prüfung dokumentieren
Ein Umfangsplan sollte nicht nur definieren, was enthalten ist. Er sollte auch festhalten, welche Unterschiede akzeptabel sind.
Akzeptable Änderungen können beispielsweise sein:
- eine andere interne administrative Organisation, solange die Arbeitsabläufe praktikabel bleiben;
- Anpassungen von Category-Namen oder Gruppierung, die die Navigationsabsicht nicht schwächen;
- Unterschiede im Content-Layout, die Erreichbarkeit, Klarheit oder Conversion nicht beeinträchtigen;
- plattformnative Feldpositionen anstelle einer älteren Anordnung benutzerdefinierter Felder;
- bewusster Ausschluss eingestellter Products oder veralteten Contents;
- Neuaufbau alter Kampagnenregeln statt einer exakten Migration.
Die Dokumentation akzeptabler Änderungen reduziert Reibung in der Prüfung. Prüfer können zwischen erwarteten Unterschieden der Zielplattform und echten Umfangsfehlern unterscheiden. Ohne diese Trennung kann jede Abweichung zu einer späten Grundsatzdiskussion werden.
Umfang in Prüfprioritäten übersetzen
Der Umfang sollte die nächsten Planungsentscheidungen vorbereiten. Er sollte helfen zu erkennen, wodurch die Migration komplex wird, welcher Ansatz zur Anforderung passt und was die Validierung nachweisen muss.
Eine nützliche Priorisierung kann so aussehen:
| Priorität | Umfangsbereich | Zweck der Prüfung |
|---|---|---|
| Kritisch | Umsatz, Checkout, Support, SEO, Kontinuität externer Systeme | Bestätigen, dass go-live-blockierende Geschäftsergebnisse weiterhin funktionieren |
| Hoch | Katalogauffindbarkeit, Customer-Kontinuität, wichtiger Content | Bestätigen, dass wichtige Abläufe weiterhin nutzbar sind |
| Mittel | Administrative Bequemlichkeit, historische Referenz, interne Organisation | Bestätigen, dass Änderungen verstanden und akzeptiert sind |
| Niedrig | Veraltete, doppelte oder ungenutzte Daten | Bewussten Ausschluss oder Bereinigung bestätigen |
So wird vermieden, dass alle Bereiche gleich viel Prüfaufwand erhalten und wenig relevante historische Daten genauso viel Aufmerksamkeit bekommen wie go-live-kritische Funktionen. Der Umfang sollte den Prüfern zeigen, wo die meiste Zeit investiert werden muss und welches Nachweisniveau erforderlich ist.
Was eine belastbare Umfangsdefinition enthalten sollte
Eine belastbare Definition des Migrationsumfangs sollte folgende Punkte klar machen:
- was das Unternehmen nach dem Go-live keinesfalls verlieren darf;
- welche Datenkategorien und Content-Typen enthalten sind;
- welche unterstützenden Strukturen und Beziehungen ausdrücklich behandelt werden müssen;
- welche Daten transformiert, bereinigt, ausgeschlossen oder verschoben werden können;
- welche Plattformunterschiede verstanden und akzeptabel sind;
- welche Bereiche besondere Prüfung oder individuelle Behandlung benötigen;
- welche Datensätze ausgewählt oder gefiltert werden sollen und warum;
- welche Prüfprioritäten nachweisen, dass der Umfang erfüllt wurde.
Diese Klarheit erfordert keine perfekte Dokumentation. Sie erfordert disziplinierte Entscheidungen darüber, was der migrierte Shop weiterhin leisten muss.
Fazit
Der Migrationsumfang beantwortet nicht nur die Frage „Welche Daten sollen übertragen werden?“. Er beantwortet die Frage „Was muss nach der Migration weiterhin funktionieren, welche Strukturen tragen dieses Ergebnis und welche Änderungen sind akzeptabel?“. Wenn der Umfang über zu erhaltende Ergebnisse, unterstützende Strukturen, beziehungsabhängige Funktionen, Regeln für selektive Migration und den bewussten Umgang mit Unterschieden der Zielplattform definiert wird, lassen sich spätere Planungsentscheidungen besser steuern.
Definieren Sie den Umfang anhand dessen, was das Unternehmen nach dem Go-live weiterhin tun können muss. Nutzen Sie ihn anschließend, um zu bestimmen, wo die Komplexität konzentriert ist, welcher Migrationsansatz geeignet ist und was die Validierung nachweisen muss, bevor der Shop als bereit gilt.
Häufige Fragen
Bedeutet Migrationsumfang immer, dass alles migriert werden muss?
Nein. Selektive Migration kann sinnvoll sein, wenn das Unternehmen den Umfang klar definiert und die Auswirkungen auf verknüpfte Funktionen, Supportnutzbarkeit, Reporting, Customer-Kontinuität und Go-live-Ziele versteht. Entscheidend ist nicht, ob jeder Datensatz übertragen wird. Entscheidend ist, ob der gewählte Umfang die Geschäftsergebnisse unterstützt, von denen das Unternehmen abhängt.
Was ist der größte Fehler bei der Umfangsplanung?
Ein häufiger Fehler ist, den Umfang mit „alles“ zu definieren, ohne festzulegen, was tatsächlich erhalten werden muss. Dadurch wird die schwierigere Entscheidung über unverzichtbare Kontinuität, akzeptable Änderungen, Ausschlüsse, Bereinigung und Prüfpriorität nur auf später verschoben.
Reichen Products, Customers und Orders aus, um den Umfang zu definieren?
Meist nicht. Unterstützende Strukturen wie Varianten, Attribute, Navigationslogik, Bilder, Promotions, URLs, operative Metadaten, Customer-Adressen, Order-Referenzen sowie von Apps, Plugins, Modulen oder Erweiterungen verwaltete Funktionen tragen häufig die geschäftliche Bedeutung, die Kerndatenkategorien überhaupt nutzbar macht.
Wann sollten Umfangserkenntnisse für eine spezialisierte Prüfung eskaliert werden?
Eskalieren Sie, wenn wichtige Datensätze, Beziehungen, individuelle Strukturen, externe Kennungen oder erforderliche Transformationen nicht mehr durch den unterstützten Umfang beschrieben werden können. Dokumentieren Sie die geschäftliche Bedeutung, das erwartete Ergebnis, repräsentative Nachweise und verbleibende Arbeiten auf der Zielplattform, bevor Sie Serviceoptionen prüfen.