# Kunden und Bestellungen werden nicht migriert **URL:** \ **Category:** Shopware 6 (German)\ **Created:** [21. Januar 2025 um 16:41 UTC](https://forum.shopware.com/t/kunden-und-bestellungen-werden-nicht-migriert/106317 "2025-01-21T16:41:12Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![Andreas\_147](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@Andreas\_147](https://forum.shopware.com/u/Andreas_147)\ **Post date:** [21. Januar 2025 um 16:41 UTC](https://forum.shopware.com/t/kunden-und-bestellungen-werden-nicht-migriert/106317/1 "2025-01-21T16:41:12Z")
Hallo zusammen, ich habe ein Problem bei der Migration. **Voraussetzungen** : Ich verwende Shopware 6.6.9.0 sowie das Migrations-Plugin in der Version 14.0. Ich habe zwei Shopware 5 Shops, welche in einen Shopware 6 Shop zusammengeführt werden. Die erste Migration von Shop 1 lief problemlos (mit Startschwierigkeiten…) alles wurde übernommen. Jetzt habe ich eine neue Verbindung angelegt und Shop 2 migriert. Soweit so gut - es werden Kategorien, Produkte Bilder etc. alles wurde übernommen. **Alles, bis auf die Kunden und Bestellungen. Diese fehlen komplett.** Fehlerangabe nach der Migration: **Konnte payment\_method nicht finden** **Konnte salutation nicht finden** Zahlarten und Anreden waren korrekt zugewiesen, wie schon bei Migration von Shop 1. Ich habe in der Datenbank im Feld „ **swag\_migration\_connection-\>premapping** “ nachgesehen, es ist alles korrekt zugeordnet, das Mapping für Anrede oder Zahlungsarten fehlt nicht. Testweise habe ich das Mapping von Shop 1 übernommen, die Prüfsumme gelöscht, customersOrders migriert, keine Änderung, selber Fehler. Auch eine Migration für die PuTTY mit den Consolen-Befehlen brachte keine Abhilfe. Ich habe sogar neue Anreden angelegt, mit anderem technischen Namen und diese vor einer weiteren Migration zugewiesen. Nochmal Prüfsumme zurückgesetzt, keine Änderung, selber Fehler. **Auszug aus dem Log** : ```auto [warning] SWAG_MIGRATION_PAYMENT_METHOD_ENTITY_UNKNOWN Cannot find payment_method The customer entity with the source id "15" cannot find the depended payment_method entity with the source id "7". ``` **Oder für die Anrede:** ```auto [warning] SWAG_MIGRATION_SALUTATION_ENTITY_UNKNOWN Cannot find salutation The order entity with the source id "47" cannot find the depended salutation entity with the source id "ms". ``` Seltsam dabei, nachfolgender Auszug stammt aus dem Migration-Log, nachdem ich eine neue Anrede für „ms“ angelegt hatte (technischer Name war dabei „fr“): ```auto [warning] SWAG_MIGRATION_SALUTATION_ENTITY_UNKNOWN Cannot find salutation The order entity with the source id "47" cannot find the depended salutation entity with the source id "ms". ``` Also die gleiche Fehlermeldung. Ich habe auch in der Datenbank vom Shopware 5 geprüft, ob die Spalte „salutation“ in der Bestellung befüllt ist – ob nun order-entity 47 oder 10042, es war überall eine Anrede vorhanden. Wer hatte diesen Fehler auch schon, wie habt ihr ihn gelöst? Wer hat Vorschläge für weitere Fehlersuche? ---
**Author:** ![R4M](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/r4m/32/9983_2.png) [@R4M](https://forum.shopware.com/u/R4M)\ **Post date:** [22. Januar 2025 um 10:28 UTC](https://forum.shopware.com/t/kunden-und-bestellungen-werden-nicht-migriert/106317/2 "2025-01-22T10:28:18Z")
Kürzlich hatte ich schon überlegt, ob ich nicht zum Thema Migration SW5 → SW6 ein YouTube Channel mache. Nun ja … > [@Andreas\_147](#): > > `Cannot find payment_method` Bei den Bestellungen gibt es Bestellungen die mit einer Zahlungsart verbunden sind, die es jedoch im SW5 nicht mehr gibt. Dadurch kann die jeweilige Bestellung nicht migriert werden. Das muss alles im Vorfeld genau analysiert werden. Eine Arbeit, was die meisten Shopbetreiber gar nicht machen können. > [@Andreas\_147](#): > > `Cannot find salutation` Hier sollte man beachten, dass die Anrede an meheren Stellen in SW5 steht. Alle Kundenangaben, müssen in allen DB-Tabellen ausgefüllt und korrekt sein. Selbst erstellte Anreden (solche Fälle gibt es) müssen vor der Migration in SW6 erst angelegt werden. > [@Andreas\_147](#): > > Wer hatte diesen Fehler auch schon, wie habt ihr ihn gelöst? Mit vielen eigenen Scripten und Tools die SW5 DB korrigiert. Dafür ist leider jede Menge an Zeit verloren gegangen. Am Ende bleibt einem aber nichts übrig. Jede Fehlerneldung muss man zudem individuell betrachten. Es gibt kein Tool was global alle Fehler korrigiert. Bei Bestellungen wo Zahlungsarten fehlen (durchaus normal) habe ich Bestellungen auf eine andere Zahlungsart eingestellt. In einigen Fällen habe ich extra für die Migration in SW5 eine Dummy-Zahlungsart angelegt und die Bestellungen mit dieser verbunden. Somit kommen die Bestellungen in SW6 an. Ja und bei allen Kundendaten natürlich ALLE Felder ALLER Tabellen durchgegangen mit mittels SQL ergänzt, wenn wo was fehlen sollte. ---
**Author:** ![Andreas\_147](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@Andreas\_147](https://forum.shopware.com/u/Andreas_147)\ **Post date:** [22. Januar 2025 um 17:42 UTC](https://forum.shopware.com/t/kunden-und-bestellungen-werden-nicht-migriert/106317/3 "2025-01-22T17:42:26Z")
Ich danke dir für deine Antwort. Ich habe das mal alles möglichst akribisch abgearbeitet. Zu den Zahlungsarten: Es gibt in dem Shop die drei Zahlungsarten Vorkasse, PayPal und Rechnung, alle drei sind auch im 6er Shop vorhanden. Er liefert Fehler für eben alle diese 3 Zahlungsarten, das sie nicht vorhanden wären. Das eine Bestellung mit einer Zahlungsart verbunden ist, die es im 5er Shopware nichtmehr gibt, kann ich wohl ausschließen. Ich habe dazu – funktioniert ja gut über den Filter „Zahlungsart“ im 5er – geprüft, ob inaktive Zahlungsarten irgendwo in einer Bestellung verwendet wurden. Dann auch nochmal zusätzlich in der Datenbank nachgesehen, es gibt nur die drei genannten Zahlungsarten mit passenden IDs, nichts fehlt, kein Feld ist leer. Wenn nur eine Zahlungsart fehlen würde, müsste er ja zumindest die anderen Bestellungen migrieren? Er migriert aber leider nichts. Das mit den Anreden habe ich auch geprüft. Alle Tabellen in der 5er Datenbank, in denen „Salutation“ als Spalte genannt war, habe ich überprüft. Es fehlt nichts. Selbst erstellte Anreden kann ich als Fehler auch ausschließen. Dann probierte ich heute einfach mal nen „Schuss ins Blaue“ und ich deinstallierte das Migrations-Plugin Version 14 – könnte ja daran liegen. Alle Daten zum Plugin gelöscht und manuell Version 13.2 hochgeladen. Neu die Verbindung zu Shop 2 angelegt – nur die Adressen und Bestellungen migriert - und siehe da, es läuft, alles migriert, keiner der genannten Fehler tritt mehr auf… Gut, Plugin Version 13.2 deinstalliert, 14.0er Version hochgeladen, Shop 2 Verbindung angelegt, Kunden/Bestellungen migriert – passt, klappt! Also dann Shop 1 Verbindung angelegt, Kunden/Bestellungen migriert – und siehe da, selbe Fehlermeldung wie beim eröffnen meines Tickets – bloß diesesmal für Shop 1, bei dem vorher alles klappte: **Konnte payment\_method nicht finden** **Konnte salutation nicht finden** Ich hab dann zum Test nochmal die 13.2er vom Migrations-Plugin draufgemacht, Verbindung für Shop 1 und Shop 2 angelegt, Shop 1 migriert – geht alles. Dann Shop 2 – und wieder die gleiche Fehlermeldung wie oben wie beim eröffnen meines Tickets. Mein Problem kommt also vom Migrationsplugin, welches nicht mit zwei Verbidungen umgehen kann, was mich doch schon enttäuscht, denn lt. Shopware (siehe erste Antwort) ([Mehrere Shopware 5 (2) Shops in einen Shopware 6 Shop migrieren per Migration Assistant](https://forum.shopware.com/t/mehrere-shopware-5-2-shops-in-einen-shopware-6-shop-migrieren-per-migration-assistant/97497)) soll man bei mehreren Shops einfach einen nach dem anderen migrieren – klappt so aber nicht. Testweise dann mal Verbindung zu Shop 1 ausgewählt und auf „Migration abschließen“ gedrückt – leider schließt er aber dann die komplette Migration, die Verbindung zu Shop 2 ist dann ebenfalls weg, da scheinbar pauschal die Migration unabhängig der gewählten Verbindung als abgeschlossen betrachtet wird. ---
**Author:** ![R4M](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/r4m/32/9983_2.png) [@R4M](https://forum.shopware.com/u/R4M)\ **Post date:** [23. Januar 2025 um 07:29 UTC](https://forum.shopware.com/t/kunden-und-bestellungen-werden-nicht-migriert/106317/4 "2025-01-23T07:29:54Z")
Nun ja, zunächst sehe ich nur deine Fehlermeldungen. Kann daher nur anhand dieser so so aus der Ferne beurteilen. > [@Andreas\_147](#): > > `customer entity with the source id "15"` Gibt es noch einen User mit ID 15 in der SW5 DB? Siehe SW5 Tabelle „s\_user“ > [@Andreas\_147](#): > > `payment_method entity with the source id "7"` In der Regel war das bei SW5 Paypal. Ist das in der SW5 DB noch so? Gibt es zur ID 7 noch eine Zahlungsart? Siehe SW5 Tabelle „s\_core\_paymentmeans“ > [@Andreas\_147](#): > > nachdem ich eine neue Anrede für „ms“ angelegt hatte (technischer Name war dabei „fr“): Ja da geht das komsiche schon los, denn im SW5 Standard gibt es nur „mr,ms,not\_defined“ - also so weit mir noch bekannt. Ein „fr“ gibt es im Standard gar nicht. Bedeutet also, Daten wurden verändert. > [@Andreas\_147](#): > > Es gibt in dem Shop die drei Zahlungsarten Vorkasse, PayPal und Rechnung Ja das kann sein, aber vielleicht wurden in der Vergangenheit Zahlungsarten verändert? Vielleicht wurde mal Paypal gelöscht und komplett neu isntalliert. Somit ändert sich die ID in der SW5 Tabelle „s\_core\_paymentmeans“. > [@Andreas\_147](#): > > Er migriert aber leider nichts. Die Produkte wurden aber schon migriert? > [@Andreas\_147](#): > > Mein Problem kommt also vom Migrationsplugin, welches nicht mit zwei Verbidungen umgehen kann Hm, das ist zwar eine ungewöhnliche Methode, glaube ich aber nicht. Wenn dein Shop 1 und Shop 2 ist keinster Weise in Verbindung stehen, kommt sich da nichts in die Quere. Jede Migration legt im SW6 Shop sein Mapping an. Im SW5 wird gar nichts angelegt. Ich bin auch noch sehr skeptisch, was die SW5 Datenbank betrifft. Aber wieso macht ihr 2 Migrationen? Laufen Shop 1 und Shop2 auf getrennten Datenbanken? Sind die irgendwie miteinander verbunden? Wie muss ich das verstehen? SW5 → Migration zu Shop1 SW5 → Migration zu Shop2 ??? Sind die Migrations-Plugins in allen Shops auf aktuellem Stand? ---
**Author:** ![area-net-gmbh](https://dub1.discourse-cdn.com/flex013/user_avatar/forum.shopware.com/area-net-gmbh/32/21995_2.png) [@area-net-gmbh](https://forum.shopware.com/u/area-net-gmbh)\ **Post date:** [23. Januar 2025 um 10:54 UTC](https://forum.shopware.com/t/kunden-und-bestellungen-werden-nicht-migriert/106317/5 "2025-01-23T10:54:04Z")
> [@Andreas\_147](#): > > Zu den Zahlungsarten: Es gibt in dem Shop die drei Zahlungsarten Vorkasse, PayPal und Rechnung, alle drei sind auch im 6er Shop vorhanden. Er liefert Fehler für eben alle diese 3 Zahlungsarten, das sie nicht vorhanden wären. Das eine Bestellung mit einer Zahlungsart verbunden ist, die es im 5er Shopware nichtmehr gibt, kann ich wohl ausschließen. Das Mapping der Zahlungsarten (und mehr) muss vor der Migration einmalig vorgenommen werden. Ich hatte den Fall schonmal, dass das Premapping nicht gespeichert wurde. Dann kam/kommt es zu diesem Fehler. Schau mal in der Tabelle _ **swag\_migration\_connection** _, ob das Feld _ **premapping** _ gefüllt ist. Und wenn ja, ob die Zahlunsgarten gemappt sind - sollte etwas ähnliches wie das hier sein: ```auto {"entity":"payment_method","mapping":[{"sourceId":"5", destinationUuid":"01913741102a72538f8f7b1a59559b81"}]} ``` ---
**Author:** ![Andreas\_147](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@Andreas\_147](https://forum.shopware.com/u/Andreas_147)\ **Post date:** [23. Januar 2025 um 12:38 UTC](https://forum.shopware.com/t/kunden-und-bestellungen-werden-nicht-migriert/106317/6 "2025-01-23T12:38:48Z")
Zunächst vielen Dank euch beiden für eure Hilfe! @ [area-net-gmbh](https://forum.shopware.com/u/area-net-gmbh) - das hatte ich überprüft, im Mapping ist alles korrekt angegeben. * * * [{„entity“:„payment\_method“,„mapping“:[{„sourceId“:„default\_payment\_method“,„description“:„Standard Payment Method“,„destinationUuid“:„018dd127e0e573b2b70e93fcfcd0db88“},{„sourceId“:„6“,„description“:„SEPA“,„destinationUuid“:„018dd12ac7d370b1a2da1690facca657“},{„sourceId“:„7“,„description“:„PayPal“,„destinationUuid“:„018dd12ac7d071ad9d9bc353b5ad29ab“},{„sourceId“:„2“,„description“:„Lastschrift“,„destinationUuid“:„018dd127e0dd73f9b6443971389dec4f“},{„sourceId“:„3“,„description“:„Nachnahme“,„destinationUuid“:„018dd127e0e3703296c613b995bdc5f2“},{„sourceId“:„4“,„description“:„Rechnung“,„destinationUuid“:„018dd127e0e172a78fbfc5d743ed7ec8“},{„sourceId“:„5“,„description“:„Vorkasse“,„destinationUuid“:„018dd127e0e573b2b70e93fcfcd0db88“}],„choices“:},{„entity“:„salutation“,„mapping“:[{„sourceId“:„not\_defined“,„description“:„not\_defined“,„destinationUuid“:„018dd127dfa87276b7a16fe7b327065d“},{„sourceId“:„ms“,„description“:„ms“,„destinationUuid“:„018dd127dfa77367967ee532f993dd45“},{„sourceId“:„divers“,„description“:„divers“,„destinationUuid“:„018dd127dfa87276b7a16fe7b327065d“},{„sourceId“:„mr“,„description“:„mr“,„destinationUuid“:„018dd127dfa27253bfdd70382b56bb1c“}],„choices“:}, Also hier passt eigentlich alles. ---
**Author:** ![Andreas\_147](https://avatars.discourse-cdn.com/v4/letter/a/59ef9b/32.png) [@Andreas\_147](https://forum.shopware.com/u/Andreas_147)\ **Post date:** [23. Januar 2025 um 13:00 UTC](https://forum.shopware.com/t/kunden-und-bestellungen-werden-nicht-migriert/106317/7 "2025-01-23T13:00:20Z")
> [@R4M](#): > > Hm, das ist zwar eine ungewöhnliche Methode, glaube ich aber nicht. Wenn dein Shop 1 und Shop 2 ist keinster Weise in Verbindung stehen, kommt sich da nichts in die Quere. Jede Migration legt im SW6 Shop sein Mapping an. Im SW5 wird gar nichts angelegt. > > Ich bin auch noch sehr skeptisch, was die SW5 Datenbank betrifft. > > Aber wieso macht ihr 2 Migrationen? Laufen Shop 1 und Shop2 auf getrennten Datenbanken? Sind die irgendwie miteinander verbunden? Wie muss ich das verstehen? > > SW5 → Migration zu Shop1 > SW5 → Migration zu Shop2 ??? > > Sind die Migrations-Plugins in allen Shops auf aktuellem Stand? Ich habe vor Jahren zusätzlich zu meinem eigenen Shopware 5 einen anderen Shopware 5 Shop übernommen. Dieser besitzt eine eigene Datenbank und ist in keiner Weise mit dem anderen Shop verbunden. Beide laufen aber auf dem selben Server. Im Zuge der Umstellung möchte ich Shopware 5 Shop 1 und Shopware 5 Shop 2 zusammen in den neuen Shopware 6 Shop migrieren. > [@R4M](#): > > Gibt es noch einen User mit ID 15 in der SW5 DB? Siehe SW5 Tabelle „s\_user“ Ich habs überprüft, diese ID ist nur einmal im 5er Shop 2 vorhanden. Es gibt aber IDs, welche sowohl im 5er Shop 1 wie auch im 5er Shop 2 vorhanden sind - da es ja fortlaufend ist, 1 bis X, das sich das überschneidet ist klar. > [@R4M](#): > > In der Regel war das bei SW5 Paypal. Ist das in der SW5 DB noch so? Gibt es zur ID 7 noch eine Zahlungsart? Siehe SW5 Tabelle „s\_core\_paymentmeans“ In beiden Shopware 5-Shops ist PayPal auch die ID7, siehe auch mein Auszug aus _ **swag\_migration\_connection** _ oben. Es gibt keine weitere Zahlungsart mit gleicher ID. > [@R4M](#): > > Ja da geht das komsiche schon los, denn im SW5 Standard gibt es nur „mr,ms,not\_defined“ - also so weit mir noch bekannt. Ein „fr“ gibt es im Standard gar nicht. Bedeutet also, Daten wurden verändert. Das war nicht auf Shopware 5 sondern auf 6 bezogen. Ich habe zum Test in Shopware 6 die Anreden alle nochmal angelegt, und für Frau dann „fr“ als technischen Namen verwendet. Das Standard „mrs“ aus Shopware 6 ist noch vorhanden - ich habe quasi alle drei Anreden nochmal mit neuem technischen Namen hinzugefügt, da ich angenommen hatte, es kommt hier evtl. zu einer Überschneidung der beiden Shops. In Shopware 5 hatte ich dabei nichts verändert. > [@R4M](#): > > Ja das kann sein, aber vielleicht wurden in der Vergangenheit Zahlungsarten verändert? Vielleicht wurde mal Paypal gelöscht und komplett neu isntalliert. Somit ändert sich die ID in der SW5 Tabelle „s\_core\_paymentmeans“. Nein, die Zahlarten hatte ich nicht verändert. Die IDs sind für die Zahlarten in Shopware 5 Shop 1 und 2 identisch = Vorkasse ist ID5, PayPal ID7 und Rechnung ID4. > [@R4M](#): > > Die Produkte wurden aber schon migriert? Ja, er hat die Vertriebskanäle, die Kategorien, Produkte und Medien alle ordentlich übernommen. Sowohl von Shopware 5 Shop 1 wie auch 2. Das Problem tritt ausschließlich bei Migration der Kunden & Bestellungen auf. Ich kann so vorgehen - Shopware 5 Shop 1 komplett migrieren, dann von Shopware 5 Shop 2 die Basisdaten, Produkte und Medien. Will ich die Kunden & Bestellungen migrieren, geht das aktuell nur, wenn ich aus der Datenbank swag\_migration\_connection den Eintrag für Shopware 5 Shop 1 lösche und somit dessen Verbindung entferne. Das ist nicht schön, aber es klappt dann, ich habe es probiert. Die Fehlermeldung tritt solange auf, wie zwei Verbindungen angelegt sind. Egal, ob ich zuerst die Daten von Shopware 5 Shop 2 migriere (dann wird hier ALLES migriert) und anschließend Shopware 5 Shop 1 (dann gibt es hier die Fehlermeldung bei Kunden & Bestellungen) oder ob ich es andersherum mache. Der Fehler tritt immer beim migrieren des zweiten Shops auf, unabhängig davon, welcher der zweite Shop ist. Ich habe es gestern mehrfach probiert. Die Kunden und Bestellungen werden dann jeweils nur migriert, wenn die eine Verbindung entfernt (also z.B. aus der Datenbank gelöscht) wurde. Sie überschreiben sich auch gegenseitig nicht, Kunden mit z.B. der ID65 sind ebenso von Shopware 5 Shop 1 wie 2 vorhanden, wenn ich so vorgehe, ebenfalls wie z.B. in s\_order die ID 101 - auch hier sind dann beide Bestellungen im Shopware 6, wenn ich eine der Migrationsverbindungen löse.