Rohe Datensatzmengen können Migrationskapazität einfacher erscheinen lassen, als sie tatsächlich ist. Product, Customer, Order und Blog Post tragen nicht im gleichen Umfang zum gezählten Bedarf bei. Gleichzeitig enthält ein Shop viele wichtige Strukturen, die selbst keine Entity Points verbrauchen.
Entity Points sind das gewichtete Kapazitätsmodell der Next-Cart Migration Services. Sie lösen eine konkrete Planungsaufgabe: Vier nach Entity Points gezählte Datenkategorien werden in einen gewichteten Kapazitätsbedarf umgerechnet. Entity Points bewerten nicht die Komplexität, garantieren keine Kompatibilität, begrenzen die Migration nicht auf die beim Kauf angegebenen Mengen und beweisen nicht, dass der Zielshop nutzbar sein wird.
Diese Abgrenzung ist wesentlich. Werden Entity Points als vollständiger Maßstab des Projekts behandelt, kann ein vorhersehbarer Shop mit großem Datenvolumen unnötig komplex erscheinen, während ein Shop mit geringem Volumen und individuellen Beziehungen fälschlich einfach wirkt.
Kapazität und Migrationsschwierigkeit unterscheiden
Für Entity Points werden folgende Datenkategorien gezählt:
- Product;
- Customer;
- Order;
- Blog Posts.
Weitere unterstützte Daten können trotzdem Teil der Migration sein, darunter Taxes, Manufacturers, Categories, Reviews, Coupons und CMS Pages. Diese Strukturen können für das Ergebnis entscheidend sein, auch wenn sie keine eigenen Entity Points verbrauchen.
Migrationsschwierigkeit kann außerdem entstehen durch:
- Beziehungen zwischen Product-Optionen und Varianten;
- benutzerdefinierte Felder oder Tabellen;
- Daten aus Anwendungen, Plugins, Modulen oder Erweiterungen;
- externe Kennungen;
- Einschränkungen des Datenmodells der Zielplattform;
- Anforderungen an Add-ons oder Custom Service;
- Abhängigkeiten bei Validierung und Launch.
Zwei Shops können dieselbe Entity-Points-Kapazität benötigen und dennoch unterschiedliche Migrationsansätze erfordern. Kapazität beschreibt das gezählte Volumen. Komplexität beschreibt die Arbeit, die erforderlich ist, um Bedeutung zu erhalten und ein akzeptables Ergebnis zu erreichen.
Zulässige Datensätze in gewichtete Kapazität umrechnen
Jede von Entity Points gezählte Datenkategorie hat ein festgelegtes Gewicht:
| Gezählte Datenkategorie | Gewicht |
|---|---|
| Product | 1.0 |
| Customer | 0.5 |
| Order | 0.8 |
| Blog Posts | 0.6 |
Die Berechnung lautet:
Entity Points
= (Product x 1.0)
+ (Customer x 0.5)
+ (Order x 0.8)
+ (Blog Posts x 0.6)
Angenommen, ein Quellshop enthält folgende geschätzte Mengen:
| Gezählte Datenkategorie | Geschätzte Datensätze | Gewicht | Geschätzte Entity Points |
|---|---|---|---|
| Product | 200 | 1.0 | 200 |
| Customer | 200 | 0.5 | 100 |
| Order | 150 | 0.8 | 120 |
| Blog Posts | 100 | 0.6 | 60 |
| Gesamt | 480 |
Der geschätzte Bedarf beträgt 480 Entity Points. Ein Plan mit 500 Punkten könnte diese Schätzung mit 20 Punkten Reserve abdecken. Ein Plan mit 1.000 Punkten würde 520 Punkte Reserve lassen.
Die Rechnung ist einfach. Die eigentliche Planungsentscheidung besteht darin, ob die Mengen realistisch sind und wie viele zusätzliche Datensätze der Quellshop voraussichtlich erzeugt, bevor die Migration abgeschlossen ist.
Die Kauf-Schätzung ist eine Prognose
Die beim Kauf angegebenen Mengen dienen der Schätzung der Entity Points und der Planauswahl. Sie erzeugen keine automatischen Datensatzfilter.
Werden 200 Products angegeben, der ausgewählte Quellumfang enthält aber 260 erfasste Products, stoppt die Migration nicht automatisch bei Datensatz 200. Tatsächlich erfolgreich migrierte gezählte Datensätze verbrauchen die verfügbare Kapazität.
Daraus ergeben sich drei unterschiedliche Werte:
| Wert | Bedeutung |
|---|---|
| Geschätzter Bedarf | Prognose zur Auswahl eines Plans |
| Plankapazität | Maximale gezählte Kapazität des erworbenen Plans |
| Tatsächlicher Verbrauch | Entity Points, die durch erfolgreich migrierte zulässige Datensätze verbraucht wurden |
Wer diese Werte trennt, vermeidet zwei häufige Fehler. Erstens ist die Schätzung kein festes Migrationslimit. Zweitens verschwindet ungenutzte Kapazität nicht, nur weil die ursprüngliche Schätzung niedriger war.
Sollen nur ausgewählte Datensätze migriert werden, muss die Anforderung über Data Filter mit feldbasierten Bedingungen für die jeweilige Datenkategorie definiert oder als individuelle Filterung geprüft werden, wenn die verfügbare Funktionsweise nicht ausreicht.
Abweichungen und Wachstum des Quellshops einplanen
Schätzungen unterscheiden sich häufig vom tatsächlichen Verbrauch, weil das Quellinventar unvollständig war, der Shop weiter verkauft hat oder übersehene Blog Posts, Customers oder Orders in den Umfang aufgenommen wurden.
Angenommen, für die oben genannte Schätzung von 480 Punkten wurde ein Plan mit 1.000 Punkten gewählt. Steigt der tatsächliche Verbrauch auf 800 Entity Points, bleibt die Migration innerhalb des Plans und 200 Punkte sind weiterhin verfügbar.
| Kapazitätsposition | Entity Points |
|---|---|
| Plankapazität | 1.000 |
| Kauf-Schätzung | 480 |
| Tatsächlicher Verbrauch | 800 |
| Verbleibende Kapazität | 200 |
Die ursprüngliche Schätzung verhindert nicht, dass zusätzliche zulässige Datensätze migriert werden. Die Plankapazität bleibt die praktische Grenze.
Reserve ist besonders nützlich, wenn:
- der Quellshop während der Vorbereitung aktiv bleibt;
- Datensatzmengen aus unvollständigen Berichten stammen;
- historische Daten zunächst aus der Schätzung ausgeschlossen wurden;
- Blog Posts oder archivierte Orders leicht übersehen werden;
- vor dem Launch weitere Migrationsaktivitäten erwartet werden.
Reserve sollte dennoch bewusst geplant werden. Ein wesentlich größerer Plan löst keine Unklarheit beim Umfang, keine individuellen Datenanforderungen und keine unzureichende Validierung.
Was geschieht, wenn die Kapazität ausgeschöpft ist?
Der tatsächliche Verbrauch folgt dieser Reihenfolge der gezählten Daten:
Product -> Customer -> Order -> Blog Posts
Sind die verfügbaren Entity Points aufgebraucht, bevor alle gezählten Datensätze migriert wurden, pausiert die Verarbeitung an dem Punkt, an dem die Kapazität erreicht ist. Anschließend kann ein höherer Entity Points Plan gewählt werden, um die zusätzlich benötigte Kapazität bereitzustellen.
Betrachten Sie einen Shop mit einem tatsächlichen gezählten Bedarf von 1.175 Entity Points:
| Gezählte Datenkategorie | Tatsächliche Datensätze | Gewicht | Benötigte Entity Points |
|---|---|---|---|
| Product | 600 | 1.0 | 600 |
| Customer | 600 | 0.5 | 300 |
| Order | 250 | 0.8 | 200 |
| Blog Posts | 125 | 0.6 | 75 |
| Gesamt | 1.175 |
Bei einem Plan mit 1.000 Punkten verbrauchen Products 600 Punkte und Customers weitere 300. Es bleiben nur 100 Punkte für Orders, ausreichend für 125 Orders zu jeweils 0,8 Punkten. Für die verbleibenden 125 Orders und 125 Blog Posts ist zusätzliche Kapazität erforderlich.
| Verbrauchsschritt | Verwendete Punkte | Laufende Summe | Ergebnis innerhalb von 1.000 Punkten |
|---|---|---|---|
| Product | 600 | 600 | 600 Products |
| Customer | 300 | 900 | 600 Customers |
| Order | 100 von 200 erforderlich | 1.000 | 125 Orders |
| Blog Posts | 0 von 75 erforderlich | 1.000 | Keine Blog Posts vor Ausschöpfung der Kapazität |
Das Beispiel zeigt, warum Kapazitätsplanung sowohl die Rechnung als auch Kenntnisse über den Quellshop benötigt. Schon eine kleine Unterschätzung kann aufgrund der Verbrauchsreihenfolge eine spätere Datenkategorie betreffen.
Kapazitätsreihenfolge nicht mit Migrationsreihenfolge verwechseln
Der Migrationsprozess verarbeitet unterstützte Daten in dieser Reihenfolge:
Taxes -> Manufacturers -> Categories -> Products -> Customers -> Orders -> Reviews -> Coupons -> CMS Pages -> Blog Posts
Der Verbrauch von Entity Points gilt nur für Product, Customer, Order und Blog Posts. Die beiden Reihenfolgen beschreiben unterschiedliche Aspekte derselben Migration:
- Die Migrationsreihenfolge beschreibt, wie unterstützte Datenkategorien verarbeitet werden.
- Die Entity-Points-Reihenfolge beschreibt, wie gezählte Kapazität verbraucht wird.
Diese Unterscheidung erklärt, warum Categories oder Reviews für das Ergebnis wichtig sein können, ohne als separate Entity-Points-Belastung aufzutreten. Ihre Bedeutung ist strukturell und wird nicht durch die Kapazitätsformel definiert.
Entity Points bei späteren Migrationsaktivitäten anwenden
Entity Points hängen von gezählten Datensätzen und davon ab, ob diese bereits innerhalb der erworbenen Migration und ihres festen Migrationspfads gezählt wurden.
| Situation des Datensatzes | Auswirkung auf die Kapazität |
|---|---|
| Ein zulässiger Datensatz wird zum ersten Mal erfolgreich migriert | Entity Points werden entsprechend seinem festgelegten Gewicht verbraucht |
| Ein zulässiger Datensatz wurde innerhalb der erworbenen Migration und des festen Pfads bereits gezählt | Derselbe Datensatz verbraucht nicht erneut Entity Points, nur weil eine weitere Migrationsaktion ihn verarbeitet |
| Ein neuer zulässiger Datensatz wird später hinzugefügt und migriert | Entity Points werden verbraucht, wenn er zum ersten Mal erfolgreich migriert wird |
| Eine neue Migrationsaktion umfasst zulässige Datensätze, die innerhalb derselben erworbenen Migration und des festen Pfads bereits gezählt wurden | Diese zuvor gezählten Datensätze verbrauchen nicht erneut Entity Points |
Die Migrationsaktion selbst entscheidet nicht über den Verbrauch. Continue the Migration with the Last Used Configuration, Continue the Migration with a New Configuration und Perform a New Migrationkönnen jeweils eine Mischung aus bestehenden und neuen Datensätzen verarbeiten. Der Verbrauch hängt davon ab, ob der jeweilige zulässige Datensatz innerhalb der erworbenen Migration und des festen Pfads bereits gezählt wurde.
Diese Regel macht verbleibende Kapazität für spätere Aktivitäten im Quellshop nutzbar. Sie bedeutet zugleich, dass das Projekt neu hinzugekommene Products, Customers, Orders und Blog Posts verfolgen sollte, wenn der Quellshop aktiv bleibt.
Entity Points für die richtige Entscheidung verwenden
Entity Points sollten unterstützen bei:
- Planauswahl;
- Planung einer Reserve;
- Überwachung des tatsächlichen Kapazitätsverbrauchs;
- Plan-Upgrades;
- späterem Wachstum zulässiger Datensätze.
Sie sollten nicht entscheiden:
- Standard, Managed oder Custom Service;
- ob ein Add-on benötigt wird;
- ob eine individuelle Datenstruktur unterstützt wird;
- ob die Implementierung der Zielplattform enthalten ist;
- ob das Migrationsergebnis akzeptabel ist.
Für diese Entscheidungen sind Nachweise zum Umfang, eine Analyse der Verantwortlichkeiten und Validierung erforderlich. Eine genaue Entity-Points-Summe ist für die Preisberechnung notwendig, ersetzt aber nicht das Verständnis der Daten.
Diese Trennung verhindert zwei gegensätzliche Planungsfehler. Ein Shop kann einen größeren Entity Points Plan benötigen und dennoch unkompliziert zu migrieren sein. Ein anderer kann in einen kleineren Plan passen, aber individuelle Beziehungen enthalten, die eine tiefergehende Prüfung erfordern. Kapazität und Komplexität sollten daher gemeinsam bewertet, aber niemals als dieselbe Größe behandelt werden.
Fazit
Innerhalb der Next-Cart Migration Services rechnen Entity Points die Mengen von Product, Customer, Order und Blog Posts in gewichtete Migrationskapazität um. Die Kauf-Schätzung hilft bei der Planauswahl, die Plankapazität definiert die verfügbare Grenze, und die tatsächlich erfolgreich migrierten zulässigen Datensätze bestimmen den Verbrauch.
Die wichtigste Planungsregel ist die Trennung der Konzepte. Kapazität ist nicht Komplexität. Geschätzte Mengen sind keine Filter. Migrationsreihenfolge ist nicht Entity-Points-Reihenfolge. Eine spätere Aktion verbraucht nicht automatisch erneut Punkte für Datensätze, die innerhalb der erworbenen Migration und des festen Pfads bereits gezählt wurden.
Mit diesen Unterscheidungen werden Entity Points zu einem nützlichen Planungsinstrument statt zu einer irreführenden Bewertung der gesamten Migration.
Häufige Fragen
Welche Datensätze zählen für Entity Points?
Product, Customer, Order und Blog Posts sind die vier gezählten Datenkategorien.
Wie werden Entity Points berechnet?
Product hat ein festes Gewicht von 1,0, Customer 0,5, Order 0,8 und Blog Posts 0,6.
Begrenzen die beim Kauf angegebenen Mengen, welche Datensätze migriert werden?
Nein. Sie dienen der Schätzung und Planauswahl. Sie wirken nicht als Datensatzfilter.
Was passiert, wenn der tatsächliche Verbrauch höher ist als geschätzt?
Die Migration kann fortgesetzt werden, solange genügend Plankapazität verfügbar ist. Ist die Kapazität ausgeschöpft, pausiert die Verarbeitung, bis zusätzliche Kapazität bereitsteht.
Können ungenutzte Entity Points spätere Migrationsaktivitäten unterstützen?
Ja. Verbleibende Kapazität kann für zulässige Datensätze genutzt werden, die später innerhalb derselben erworbenen Migration und desselben festen Pfads migriert werden.
Verbrauchen Datensätze bei einer späteren Aktion erneut Entity Points?
Nicht, wenn dieselben gezählten Datensätze innerhalb der erworbenen Migration und des festen Pfads bereits erfasst wurden. Neu migrierte zulässige Datensätze verbrauchen Punkte, wenn sie zum ersten Mal erfolgreich migriert werden.
Verbrauchen Categories, Reviews oder CMS Pages Entity Points?
Sie verbrauchen nicht unabhängig Entity Points. Sie können dennoch wichtige Bestandteile des unterstützten Migrationsumfangs und der Validierung sein.