Den richtigen Migrationsansatz für Storeden zu wählen bedeutet, den Next-Cart-Servicepfad mit der tatsächlichen betrieblichen Komplexität des Shops abzugleichen. Als potenzielle Zielplattform wird Storeden in seiner heutigen TeamSystem-Commerce-Umgebung besonders für Händler bewertet, die Cloud-Commerce, Katalog- und Bestandssteuerung, professionelles Order-Management, integrierte Zahlungen, Logistik, Marktplatzverkauf, Apps, API-Ressourcen und Geschäftssystemverbindungen benötigen. Genau diese Stärken erzeugen jedoch Planungsfragen, die vor der Full Migration geklärt sein sollten.
Der richtige Ansatz ergibt sich nicht allein aus dem Plattformnamen. Entscheidend sind Struktur und Qualität der Quelldaten, die geplante Storeden-Zielkonfiguration, der gewünschte Umfang der Ausführungsunterstützung und die Frage, ob das erwartete Ergebnis durch unterstützte Datenmigration, optionale Add-ons, Custom Service oder Konfiguration nach der Migration erreicht wird.
Die Auswahl sollte auf Nachweisen beruhen: Katalogstichproben, Customer- und Order-Beispiele, Marktplatzabhängigkeiten, App-eigene Werte, TeamSystem- oder andere externe IDs, SEO-Kontinuitätsanforderungen und Ergebnisse der Demo Migration. Der Plan muss so klar sein, dass alle Beteiligten verstehen, was Next-Cart migriert, was Storeden auf der Zielseite konfigurieren muss und was Händler oder verbundene Anbieter außerhalb der eigentlichen Migration vorbereiten.
Innerhalb der Next-Cart Migrationsservices müssen Storeden-Nachweise unterstützte Daten, Ausführungsverantwortung, klar begrenzte Add-ons, Marktplatz-/Fremdsystemabhängigkeiten und Zielkonfiguration voneinander trennen.
Grundprinzip für die Wahl des Storeden-Migrationsansatzes
Der Ansatz muss zwei Fragen gleichzeitig beantworten: Wie viel Unterstützung bei der Durchführung wird benötigt und wie viel Anpassung ist erforderlich? Beides hängt zusammen, ist aber nicht dasselbe.
Ein Händler kann vollständig unterstützte, saubere Daten besitzen und trotzdem wünschen, dass Next-Cart die Ausführung übernimmt; dann spricht vieles für Managed Service. Ein anderer kann die Ausführung selbst steuern, benötigt aber individuelle Behandlung für App-Daten, Marktplatz-IDs oder Fremdsystemreferenzen; dann ist Custom Service zu prüfen. Ein dritter benötigt nur unterstützte Datensatzfilterung, Transformation von Feldwerten oder eine andere Zuordnung kompatibler Felder; dafür kann ein Add-on ausreichen.
| Entscheidungsfaktor | Bedeutung für Storeden | Wahrscheinliche Serviceauswirkung |
|---|---|---|
| Unterstützte Datenstruktur | Products, Customers, Orders, Categories, Reviews, Coupons, CMS und SEO-Werte entsprechen unterstütztem Migrationsverhalten. | Standard Service oder Managed Service kann ausreichen. |
| Ausführungsaufwand | Der Händler möchte, dass Next-Cart die Migration ausführt, statt zentrale Schritte selbst zu übernehmen. | Managed Service kann besser passen als Standard Service. |
| Add-on-Bedarf | Berechtigte Datensätze benötigen datentypspezifische Bedingungen, Feldwerte eine Expression oder Quellfelder ein kompatibles Ziel. | Data Filter, Advanced Data Mapping oder Data Transformation können das Ergebnis innerhalb unterstützten Scope verfeinern. |
| Individuelle/nicht unterstützte Daten | App-Daten, externe IDs, Marktplatzwerte, individuelle Product-Logik oder TeamSystem-bezogene Referenzen benötigen Sonderbehandlung. | Custom Service muss geprüft werden. |
| Abhängigkeit von Zielkonfiguration | Zahlungen, Logistik, Themes, Apps, Channels oder Integrationen müssen in Storeden eingerichtet werden. | Das ist Ziel-Setup und darf nicht mit migrierten Daten verwechselt werden. |
| Unklare Nachweislage | Demo-Migration-Stichproben beweisen noch nicht, dass der gewählte Pfad zum realen Shop passt. | Ansatz vor Freigabe der Full Migration erneut prüfen. |
Der sicherste Ansatz ist der leichteste Pfad, der das erwartete Ergebnis dennoch zuverlässig schützt. Ein unnötig schwerer Pfad verschwendet Aufwand; ein zu leichter Pfad trotz nicht unterstützter Anforderungen erzeugt Launch-Risiko.
Wann Standard Service zu Storeden passen kann
Standard Service kann passen, wenn die Quelldaten sauber und unterstützt sind, der Händler den Storeden-Zielshop vorbereiten kann und das erwartete Ergebnis keine individuelle Migrationslogik benötigt. Typisch ist dies bei nachvollziehbarer Katalogstruktur, nicht ungewöhnlich komplexen Product-Optionen, Orders, die hauptsächlich als Historie benötigt werden, gewöhnlichen Customer-/Adressdaten und separat konfigurierbaren Zahlungen, Logistik, Themes, Apps und Marktplatzkanälen.
Besonders geeignet ist Standard Service, wenn der Händler intern ausreichend Klarheit besitzt, um Ergebnisse der Demo Migration zu prüfen, Fehler zu erkennen und nach akzeptabler Stichprobe zur Full Migration überzugehen.
| Standard-Fit-Signal | Storeden-Einordnung | Nachweis |
|---|---|---|
| Katalogdaten sind sauber | Products, Bilder, Preise, Categories und Bestandswerte passen in unterstützte Zielstrukturen. | Product-Stichproben werden in Storeden korrekt dargestellt. |
| Product-Optionen sind vorhersehbar | Varianten oder Optionen benötigen keine individuelle Transformation. | Varianten erhalten SKU-, Preis-, Bestands- und Bildbedeutung. |
| Customer-Daten sind gewöhnlich | Customers, Adressen und Order-Verknüpfungen hängen nicht von ungewöhnlicher Kontologik ab. | Repräsentative Customer-Historien bleiben verständlich. |
| Orders dienen der Historie | Alte Orders werden für Service und Finanzen benötigt, nicht zum Wiederaufbau von Live-Checkout-Regeln. | Stichproben zeigen Products, Summen, Zahlungs-/Versandangaben und verständliche Status. |
| Storeden-Setup ist separat verantwortet | Theme, Zahlung, Versand, Logistik, Apps, Marktplätze und Integrationen werden auf der Zielseite eingerichtet. | Migrationsabnahme hängt nicht von unfertigen Konfigurationsarbeiten ab. |
Standard Service sollte nicht nur deshalb gewählt werden, weil ein Shop klein ist. Auch kleine Shops können App-eigene Daten, individuelle Product-Funktionen oder externe IDs besitzen und Custom Service benötigen. Umgekehrt kann ein großer Shop mit sauberen unterstützten Strukturen standardfähig bleiben, wenn Vorbereitung und Prüfung intern geleistet werden können.
Wann Managed Service besser passt
Managed Service ist passend, wenn die Daten innerhalb der unterstützten Migrationsfunktionen bleiben, der Händler aber möchte, dass Next-Cart die Ausführung des Migrationsprozesses übernimmt. Der Mehrbedarf liegt dann in der operativen Unterstützung, nicht zwingend in Anpassung.
Das kann Storeden-Projekten mit relevantem Katalog, Customer-/Order-Historie, SEO-Anforderungen oder engem Launch-Zeitplan helfen, wenn der Händler nicht jeden Migrationsschritt selbst steuern möchte. Managed Service reduziert den Ausführungsaufwand, ohne den unterstützten Datenrahmen automatisch zu erweitern.
| Managed-Fit-Signal | Warum es wichtig ist | Was weiterhin außerhalb der Migration liegt |
|---|---|---|
| Händler wünscht geführte Ausführung | Das Projekt benötigt klareren Prozess und weniger kundenseitige Durchführung. | Storeden-Zieleinstellungen brauchen weiterhin Händler- oder Plattformkonfiguration. |
| Daten sind unterstützt, Prüfaufwand aber hoch | Product-, Customer-, Order- und SEO-Stichproben benötigen organisierte Prüfung. | Entscheidungen über Scope, Ausschlüsse und Ziel-Setup bleiben beim Händler. |
| Launch-Timing muss koordiniert werden | Timing, Demo-Migration-Prüfung und Full-Migration-Abnahme brauchen Struktur. | Live-Zahlung, Logistik, Apps, Channels und Integrationen müssen separat bestätigt werden. |
| Interne Kapazität ist begrenzt | Das Team kann nicht jeden Schritt selbst verwalten. | Individuelle Anforderungen brauchen weiterhin Custom Service, wenn sie unterstütztes Verhalten überschreiten. |
Managed Service ersetzt Custom Service nicht. Wenn das Ergebnis App-Daten, Marktplatz-IDs, Fremdsystemdaten, nicht unterstützte Feldbehandlung oder Transformation außerhalb des Add-on-Scope benötigt, bleibt eine Custom-Service-Prüfung erforderlich - auch wenn zusätzlich Managed Service für die Ausführung gewünscht ist.
Wo Add-ons helfen können
Add-ons helfen, wenn Daten grundsätzlich im unterstützten Migrationsrahmen bleiben, aber zusätzliche Kontrolle benötigen. Bei Storeden sind sie besonders relevant, wenn Datensätze pro Datenkategorie anhand von Feldbedingungen gefiltert, Feldwerte durch Expressions transformiert oder Quellfelder auf kompatible Zielfelder abgebildet werden sollen.
| Add-on | Storeden-Anwendungsfall | Klare Grenze |
|---|---|---|
| Data Filter | Unterstützte Feldbedingungen für Product-, Customer-, Order-, CMS-Page- oder Blog-Post-Datensätze anwenden, sodass nur passende Datensätze migriert werden. | Geschätzte Datensatzanzahlen sind keine Filter; jede Bedingung muss ausdrücklich definiert werden. |
| Advanced Data Mapping | Unterstützte Quellfelder auf kompatible Storeden-Zielfelder neu zuordnen. | Mapping muss Feldbedeutung erhalten und innerhalb unterstützter Plattformfunktionen bleiben. |
| Data Transformation | Expressions verwenden, um unterstützte Labels, Namen, Status oder andere Feldwerte während der Migration zu transformieren. | Expressions erzeugen keine individuelle App-Migration oder nicht unterstützte Geschäftslogik. |
Die feste Verarbeitung folgt Data Filter → Advanced Data Mapping → Data Transformation für die in diesem Storeden-Pfad anwendbaren Add-ons. Eine zusätzliche datenbankbasierte Mapping-Stufe gehört nicht zum Storeden-Artikel-Scope und wird hier nicht eingeführt.
Add-ons sind passend, wenn der Händler Datenkategorie und Bedingung, Transformationsausdruck oder Quell-/Zielfeld eindeutig beschreiben kann. Muss das Add-on-Verhalten selbst außerhalb der verfügbaren Funktion angepasst werden, wechselt die Anforderung zu Custom Service.
Wann Custom Service erforderlich ist
Custom Service ist erforderlich, wenn das erwartete Storeden-Ergebnis von Individualisierung, nicht unterstützten App-/Plugin-Daten, benutzerdefinierten Feldern außerhalb des unterstützten Mapping-Scope, Interpretation einer individuellen Plattform, externen IDs, marktplatzspezifischer Sonderbehandlung oder Anpassung der Migrationslogik abhängt.
Das betrifft insbesondere Daten, die nicht zum gewöhnlichen Output von Katalog-, Customer-, Order-, Category-, Content- oder SEO-Migration gehören. Apps, ERP-Verbindungen, Marktplatzfeeds, B2B-Logik, individuelle Checkout-Funktionen, eigene Order-Metadaten oder Integrations-IDs können solche Anforderungen erzeugen.
| Custom-Service-Signal | Storeden-Beispiel | Warum Standard Service oder Add-ons nicht ausreichen können |
|---|---|---|
| App-eigene Daten tragen Geschäftslogik | App-Felder steuern Aktionen, Customer-Gruppen, Listings oder Fulfillment-Kontext. | Standardmigration umfasst nicht zwingend nicht unterstützte App-Daten. |
| Externe IDs müssen weiter nutzbar sein | ERP-, Buchhaltungs-, Lager-, POS-, CRM- oder TeamSystem-IDs werden nach dem Launch benötigt. | IDs können individuelles Mapping oder Transformation benötigen. |
| Product-Verhalten ist individuell | Bundles, konfigurierbare Products, nicht standardmäßige Varianten, Custom Fields oder Channel-Attribute beeinflussen den Verkauf. | Daten passen möglicherweise nicht in normale Product-/Variantenstrukturen. |
| Marktplatzwerte benötigen Sonderbehandlung | Marktplatz-IDs, Channel-Categories, Listing-Status oder Ursprungsreferenzen müssen erhalten bleiben. | Channel-Daten unterscheiden sich möglicherweise vom normalen Storefront-Katalog. |
| Orders enthalten individuelle operative Metadaten | Zahlungsreferenzen, Logistik-IDs, Fulfillment-Notizen, Steuerlabels oder externe Referenzen benötigen spezielle Interpretation. | Historischer Order-Import erhält den erwarteten Kontext möglicherweise nicht ohne individuelle Arbeit. |
| individuelle Plattform als Quelle | Das Quellsystem ist individuell oder besitzt keine vorhersehbare Exportstruktur. | Regeln können erst nach individueller Quellinterpretation angewandt werden. |
Custom Service definiert den Anpassungspfad. Er bedeutet nicht automatisch vollständige Ausführungssteuerung, sofern Migration Management nicht im finalen Plan enthalten ist.
Custom Service umfasst außerdem nicht automatisch App-Installation, Marktplatz-Setup, Zahlungs-/Versandkonfiguration, Theme-Implementierung, Deployment einer TeamSystem-Integration oder vollständigen Wiederaufbau von Storeden, sofern dies nicht ausdrücklich vereinbart wurde.
Entity Points und Auswirkung auf den Migrationsscope
Entity Points messen das berechtigte Datensatzvolumen, nicht die vollständige Komplexität einer Storeden-Migration. Gezählt werden Products, Customers, Orders und Blog Posts, wenn sie innerhalb der gekauften Migration und des festen Migrationspfads erstmals migriert werden. Categories, CMS Pages, Reviews, Coupons, Varianten, Marktplatzreferenzen, App-Daten, benutzerdefinierte Felder und externe IDs können Scope oder Servicekomplexität erhöhen, werden aber nicht zu separaten Entity-Points-Datensatztypen.
Bei späteren Storeden-Aktivitäten bleiben bereits gezählte berechtigte Datensätze auf demselben Pfad einmal gezählt; Marktplatz-, Logistik-, App- und Geschäftssystemkomplexität wird separat bewertet. Neu berechtigte Products, Customers, Orders und Blog Posts können Entity Points verbrauchen, wenn sie erstmals migriert werden.
| Scope-Signal | Was Entity Points anzeigen | Was separat bewertet werden muss |
|---|---|---|
| Großer Product-Katalog | Gezähltes Product-Volumen | Varianten, Marktplatz-Mappings, Bestandsverantwortung, Bilder, Custom Attributes |
| Große Customer-Basis | Gezähltes Customer-Volumen | B2B-Rollen, Einwilligungen, Dubletten, CRM-Referenzen, App-eigene Felder |
| Umfangreiche Order-Historie | Gezähltes Order-Volumen | Zahlung, Steuer, Fulfillment, Marktplatz- und Fremdsystemkontext |
| Blog-Inhalte | Gezähltes Blog-Posts-Volumen | CMS Pages, Landingpages, SEO-Pfade, Medien und Theme-Wiederaufbau |
Entity Points unterstützen die Kapazitätsentscheidung; Demo Migration und Scope-Prüfung zeigen dagegen, ob Storeden-spezifische Strukturen Add-ons, Custom Service, Zielkonfiguration oder akzeptierte Ausschlüsse benötigen.
Optionen für spätere Migrationen und spätere Migrationsaktionen
Die Optionen für spätere Migrationen werden danach gewählt, was sich seit der früheren Migrationsaktivität geändert hat: nur Daten, unterstützte Konfiguration oder die gesamte Projektbasis.
| Aktuelle Aktion | Storeden-Anwendungsfall | Erforderliche Revalidierung |
|---|---|---|
| Continue the Migration with the Last Used Configuration | Neue berechtigte Datensätze wurden erstellt, während freigegebener Scope und Konfiguration weiterhin passen. | Neue Products, Customers, Orders und Blog Posts sowie repräsentative Regression-Stichproben prüfen. |
| Continue the Migration with a New Configuration | Unterstützte Filterung, Mapping, Auswahl der Datenkategorien oder Konfiguration muss sich ändern. | Jedes betroffene Product-, Varianten-, Customer-, Order-, Content-, Marktplatz- und Fremdreferenzfeld neu validieren. |
| Perform a New Migration | Zielplan oder vorgesehenes Storeden-Ergebnis hat sich so stark geändert, dass vorherige migrierte Ergebnisse nicht mehr die Arbeitsbasis sein sollen, während der gekaufte Quellplattform-Zielplattform-Migrationspfad unverändert bleibt. | Aktualisiertes Zielergebnis validieren und bestätigen, dass vorheriger Output nicht mehr als maßgeblich gilt. |
Diese Aktionen bauen keine Themes neu, konfigurieren keine Live-Zahlungen oder Versandarten, verbinden Marktplätze nicht automatisch erneut, deployen keine Apps und stellen TeamSystem-/Fremdsystemintegrationen nicht von selbst wieder her. Diese Verantwortlichkeiten müssen im finalen Scope ausdrücklich bleiben.
Demo Migration als Entscheidungspunkt für den Ansatz
Die Demo Migration soll bestätigen, ob der gewählte Ansatz zur tatsächlichen Storeden-Situation passt. Die Stichprobe sollte genau jene Datensätze enthalten, die Product-, Katalog-, Customer-, Order-, Content-, Marktplatz-, App- und Integrationskomplexität sichtbar machen.
| Demo-Stichprobe | Was sie nachweisen sollte | Was ein Fehler nahelegt |
|---|---|---|
| Varianten-Product | Optionen, SKU, Bestand, Preis und Bilder bleiben sinnvoll. | Mapping- oder Custom-Service-Prüfung kann nötig sein. |
| Marktplatzsensitives Product | Channel-IDs oder Listing-Kontext sind dort sichtbar, wo erforderlich. | Marktplatzdaten benötigen möglicherweise separate Behandlung. |
| Customer mit Order-Historie | Kontodetails, Adressen und Order-Bezüge sind verständlich. | Customer-/Order-Beziehungen müssen überprüft werden. |
| B2B-/Unternehmens-Customer | Unternehmen, Steuer, Gruppe oder Kontokontext bleibt im vereinbarten Scope erhalten. | B2B-Logik kann Custom Service oder Zielkonfiguration benötigen. |
| Komplexe Order | Products, Rabatte, Steuern, Zahlungs-/Versandangaben und Fulfillment-Kontext bleiben lesbar. | Historische Order-Bedeutung kann Mapping oder individuelle Prüfung benötigen. |
| Fremdsystemdatensatz | ERP-, Buchhaltungs-, Lager-, API- oder TeamSystem-IDs erscheinen wie erwartet. | Integrationsabhängige Daten können Custom Service benötigen. |
| Priorisierte URL oder Content-Seite | SEO- und Content-Kontinuität ist prüfbar. | Redirect-, CMS- oder manuelle Content-Planung kann unvollständig sein. |
Belegen die Demo-Migration-Ergebnisse den Ansatz, kann das Projekt mit höherer Sicherheit weitergehen. Zeigen sie nicht unterstützte Daten, App-Abhängigkeiten, fehlende externe IDs, unklaren Order-Kontext oder schwache Product-Bedeutung, sollte der Servicepfad vor der Full Migration neu bewertet werden.
Warnsignale für einen zu leichten Ansatz
Ein Storeden-Ansatz ist möglicherweise zu leicht, wenn er sich auf Datensatzbewegung konzentriert und operative Abhängigkeiten ignoriert. Das passiert häufig, wenn angenommen wird, die Zielplattform stelle alte Workflows automatisch wieder her.
Typische Warnsignale sind:
- Marktplatz-Products oder -Orders sind wichtig, Channel-IDs fehlen aber in der Scope-Prüfung;
- TeamSystem-, ERP-, Buchhaltungs-, Lager-, CRM-, POS- oder API-Referenzen sind operativ wichtig, werden aber nicht getestet;
- Apps oder Plugins steuern Preise, Customer-Gruppen, Fulfillment, Marketing oder Reporting;
- Product-Optionen, Attribute, Filter oder Bestandsregeln werden wie einfacher Text behandelt;
- B2B-Verhalten wird erwartet, ohne Konto-, Preis-, Steuer- oder Freigabelogik zu bestätigen;
- Orders werden akzeptiert, ohne Zahlung, Versand, Fulfillment, Refund, Steuer oder Logistik zu prüfen;
- Live-Checkout, Zahlungsanbieter, Logistik, Marktplätze und Apps werden mit migrierter Historie verwechselt;
- SEO-Prüfung wird bis nach dem Launch verschoben;
- Demo-Migration-Stichproben enthalten nur einfache Datensätze.
Treten diese Signale auf, sollte das Projekt nicht ohne erneute Ansatzprüfung in die Full Migration wechseln. Der nächste Schritt kann eine bessere Demo-Migration-Stichprobe, Add-on-Konfiguration, Custom-Service-Prüfung oder eine klarere Trennung von Migrationsscope und Storeden-Setup sein.
Fazit
Der richtige Storeden-Migrationsansatz hängt davon ab, ob das Projekt unterstützte Standardmigration, von Next-Cart geführte Ausführung, optionale Bedingungen je Datenkategorie, Wert-Expressions, Feldziele, Custom Service oder eine Kombination davon benötigt. Standard Service kann für saubere unterstützte Strukturen passen. Managed Service eignet sich, wenn der primäre Bedarf in Ausführungsunterstützung liegt. Add-ons verfeinern unterstützte Datensatzfilterung, Feldwerttransformation und Feldzuordnung. Custom Service ist erforderlich, wenn das Ergebnis von nicht unterstützten Daten, App-eigenen Werten, externen IDs, marktplatzspezifischer Sonderbehandlung, Interpretation einer individuellen Plattform oder Anpassung der Migrationslogik abhängt.
Die Demo Migration sollte der Kontrollpunkt für diese Entscheidung sein. Verhalten sich repräsentative Products, Customers, Orders, Marktplatzdatensätze, externe IDs und priorisierte URLs wie erwartet, lässt sich der gewählte Pfad fundierter freigeben. Zeigen die Stichproben nicht unterstützte Daten oder individuelle Logik, muss der Ansatz vor der Full Migration angepasst werden.
Häufige Fragen
Reicht Standard Service für eine Storeden-Migration aus?
Standard Service kann ausreichen, wenn Quelldaten in unterstütztes Migrationsverhalten passen, der Händler das Storeden-Zielsetup verwalten kann und das erwartete Ergebnis keine App-Daten, externen IDs, individuelle Transformation oder nicht unterstützte Logik benötigt.
Wann sollte bei einer Storeden-Migration stattdessen Managed Service gewählt werden?
Managed Service ist sinnvoll, wenn die Daten innerhalb unterstützter Migrationsfunktionen liegen, der Händler aber möchte, dass Next-Cart die Ausführung verwaltet. Er reduziert Prozessaufwand, ersetzt aber Custom Service nicht, wenn Anpassung erforderlich ist.
Wie unterscheiden sich Add-ons und Custom Service bei Storeden?
Add-ons unterstützen klar begrenzte Datensatzfilterung, Feldwerttransformation und Feldzuordnung für unterstützte Migrationsdaten. Custom Service ist erforderlich bei nicht unterstützter Datenbehandlung, App-/Plugin-Daten, externen IDs, Interpretation einer individuellen Plattform oder Anpassung der Migrationslogik.
Was sollte Demo Migration für Storeden vor Full Migration nachweisen?
Sie sollte zeigen, dass repräsentative Storeden-Datensätze sinnvoll funktionieren: Products, Varianten, Bestände, Categories, Customers, Orders, marktplatzsensitive Werte, externe IDs und priorisierte URLs oder Content-Seiten. Zeigen diese Beispiele nicht unterstützte Daten oder individuelle Anforderungen, muss der Ansatz vor Full Migration überprüft werden.
Welche Additional Migration Option sollte für Storeden verwendet werden?
Continue the Migration with the Last Used Configuration passt für neu hinzugekommene Datensätze, wenn die freigegebenen Storeden-, Marktplatz- und Fremdreferenzannahmen unverändert gelten. Continue the Migration with a New Configuration wird verwendet, wenn unterstützter Scope, Filter, Mapping oder Konfiguration geändert werden müssen. Perform a New Migration ist richtig, wenn sich das gewünschte Migrationsergebnis oder die Projektbasis wesentlich verändert hat.