Großhandelskunden zu Shopify-Unternehmen migrieren: ein Agentur-Playbook

Es gibt zwei Wege, auf denen Großhandelskunden zu Shopify-Unternehmen werden, und der Unterschied entscheidet über Ihren gesamten Plan. Liegen die Bestellungen bereits als D2C-Bestellungen in Shopify, läuft es über den Admin: 250 Kundinnen auf einmal, die gesamte Historie einer Kundin oder gar keine, auf genau einen Unternehmensstandort – und dafür gibt es keine API, weil die zuständigen Mutations Shopify-intern sind. Liegen die Bestellungen in einem Altsystem, kommen sie als importierte Bestellungen über orderCreate mit einem Unternehmensstandort herein, was skriptbar ist, aber voraussetzt, dass Unternehmen, Standort, Kontakt und Rolle vorher existieren.

Die meisten Migrationspläne, die schiefgehen, nehmen an, der erste Weg habe eine API. Hat er nicht, und das nach unterschriebenem Lastenheft zu entdecken, ist teuer.

Diese Seite ist das Playbook für die Agentur, die den Umzug scoped: was die zwei Wege sind und wie Sie erkennen, auf welchem Sie sind, die Abhängigkeitskette, die die Reihenfolge der Arbeit bestimmt, eine Tabelle der Grenzen fürs Lastenheft, welcher Durchsatz im Rate-Limit des jeweiligen Tarifs zu erwarten ist, wie Sie pilotieren und was sich rückgängig machen lässt und was nicht. Wo beschrieben wird, wie sich eine Angebotsebene während einer Migration verhält, ist das eine Implementierung und als solche gekennzeichnet.

Alles über Shopify wurde am 23. September 2026 gegen Shopifys eigene Seiten in API-Version 2026-07 geprüft; die Quellen stehen am Ende.

Die zwei Wege

Eine Frage entscheidet: Sind die Bestellungen, die an ein Unternehmen sollen, schon Shopify-Bestellungen, oder liegen sie woanders? Der erste Weg läuft über den Admin und ist nicht skriptbar; der zweite läuft über orderCreate und ist es.

Weg A – die Bestellungen sind bereits Shopify-D2C-Bestellungen. Das ist der Shop, der bisher über gewöhnliche Kundenkonten an Gewerbekunden verkauft hat, mit Tags oder einem Rabattcode als Behelf – die Form, die den Wholesale Channel abgelöst hat, und jetzt Unternehmen will. Shopifys Admin macht das: Sie wählen auf der Kundenseite Kundinnen aus – „bis zu 250 B2B-Kundinnen gleichzeitig, oder führen Sie den Vorgang in kleineren Stapeln durch“ – und fügen sie einem neuen oder bestehenden Unternehmen hinzu. Ihre bisherigen D2C-Bestellungen wandern mit.

Was Sie wissen sollten, bevor Sie den Aufwand anbieten: dafür gibt es keine öffentliche API. Ein Shopify-Mitarbeiter hat es im Dezember 2025 im Entwicklerforum bestätigt – „CompanyLocationMigrateOrdersMutation und CompanyLocationRevertMigratedOrders sind intern und nicht in der öffentlichen API verfügbar“, abgestimmt mit dem B2B-Produktteam. Unternehmen, Standorte und Kontakte können Sie über die Admin-API den ganzen Tag anlegen; der Schritt, der die Bestellhistorie trägt, ist eine Person, die im Admin klickt, 250 Kundinnen auf einmal.

Weg B – die Bestellungen liegen anderswo. Ein altes ERP, eine frühere Plattform, ein eingestellter Großhandelskanal. Hier migrieren Sie nicht innerhalb von Shopify, Sie importieren hinein, und dafür gibt es eine API: orderCreate mit companyLocationId und customer.toAssociate, was Shopify ausdrücklich für historische Bestelldaten dokumentiert. Die Anforderung, über die Builds stolpern: „Die Kundin muss eine Rollenzuweisung für den angegebenen Unternehmensstandort haben. Hat sie keine, wird ein Fehler zurückgegeben“ – und allgemeiner: „Ein B2B-Händler muss alle relevanten Unternehmen, Unternehmensstandorte, Unternehmenskontakte und Produkte in Shopify importieren oder anlegen, bevor B2B-Bestellungen importiert werden können.“

Die meisten echten Projekte sind eine Mischung: Manche Konten haben Shopify-Historie, manche Historie im Altsystem, einige beides. Sortieren Sie die Liste nach Weg, bevor Sie irgendetwas sequenzieren – die zwei Wege haben unterschiedlichen Durchsatz, unterschiedliche Menschen, die sie ausführen, und unterschiedliche Fehlerfälle.

Die Abhängigkeitskette

Jeder Schritt blockiert den nächsten, weshalb Migrationen, die Schritte parallel fahren, Waisen erzeugen.

1. Den Unternehmensbaum festlegen. Ein Unternehmen je einkaufender Organisation, ein Standort je Ort mit eigenen Preisen, Zahlungszielen, Steuerstatus oder Lieferadresse. Das ist die Entscheidung, die sich später teuer ändert, weil jeder Katalog, jedes Ziel und jede Bestellung an einem Standort hängt.
2. Unternehmen und Standorte anlegen, mit externalId an beiden aus den Kunden- und Lieferadress-Kennungen des Quellsystems. Dieses Feld ist Ihr einziger Join zurück in die alten Daten, und alles Spätere – der folgende Abgleich, die Abstimmung, das Audit – hängt daran.
3. Kontakte verknüpfen. companyAssignCustomerAsContact macht aus einer bestehenden Shopify-Kundin einen Unternehmenskontakt; danach „wird die Kundin zu einem Unternehmenskontakt, der im Namen des Unternehmens bestellen kann, mit Zugriff auf alle Kataloge, Preise und Zahlungsziele, die für die Standorte des Unternehmens konfiguriert sind“. companyCreate kann Unternehmen, einen Standort und einen Kontakt auch in einem einzigen Aufruf anlegen, was für einen frischen Baum die effiziente Form ist.
4. Rollen am Standort zuweisen. Nur Bestellen oder Standort-Admin. Ohne das funktioniert nichts weiter: kein Bestellen, kein Bestellimport.
5. Kataloge zuweisen. Ein Standort braucht einen Katalog, bevor seine Käuferinnen überhaupt Preise sehen. Außerhalb von Plus über einen B2B-Markt, mit drei aktiven Katalogen über alle Märkte als Grenze; auf Plus lässt sich ein Katalog direkt einem Unternehmen oder Standort zuweisen. Woher der Startpreis einer Anfrage kommt beschreibt, wie sich der Katalog für eine angemeldete Käuferin auflöst.
6. Zahlungsziele und Steuer setzen. Beides lebt am Standort – eine Zentrale auf Netto 60 und eine Filiale auf Netto 30 ist ein normaler Aufbau, kein Workaround. Shopify-B2B-Zahlungsziele nennt die aufgezählten Typen und ihr Verhalten auf einer Bestellung.
7. Dann die Historie, auf dem jeweils passenden Weg. Zuletzt, weil das der Schritt ist, den Sie nicht teilweise zurücknehmen können.

Die käuferseitige Folge dieser Reihenfolge: Die Schritte 1 bis 6 ergeben bereits einen funktionierenden B2B-Shop. Preise, Ziele und Bestellungen funktionieren, bevor eine einzige historische Bestellung umgezogen ist. Das zählt für den Cutover-Plan: Historie ist Auswertung, nicht Funktion.

Grenzen fürs Lastenheft

Grenze	Detail	Folge für den Plan
Welche Bestellungen wandern	Nur D2C-Bestellungen. „B2B-Bestellungen bleiben bei dem Unternehmen, für das sie erstellt wurden, und können nicht zu einem anderen migriert werden“	Eine falsche Unternehmenszuordnung lässt sich nicht durch erneutes Migrieren heilen. Erst den Baum richtig bauen
Wie viel Historie	„Sie können nur die vollständige Bestellhistorie einer Kundin einem Unternehmen hinzufügen, eine teilweise Migration wird nicht unterstützt“	Zwei Jahre mitnehmen und den Rest lassen geht nicht. Alles oder nichts, je Kundin
Wo die Historie landet	„Bestellungen können nicht auf mehrere Standorte aufgeteilt werden“	Eine Kundin, die für drei Filialen gekauft hat, landet auf einem Standort. Entscheiden Sie welchen – und halten Sie es fest
Ausgeschlossene Bestellungen	„Stornierte oder gelöschte Bestellungen können nicht migriert werden“	Abstimmzahlen passen nicht zur Quelle, wenn Sie diese nicht vorher herausnehmen
Stapelgröße	„Bis zu 250 B2B-Kundinnen gleichzeitig“	20.000 Kundinnen sind 80 Admin-Stapel, von Hand
Automatisierung	Die Migrations- und Rücknahme-Mutations sind Shopify-intern	Für Weg A Admin-Zeit einplanen, nicht Skriptzeit
Was mitkommt	Bisherige Bestellungen, Steuerbefreiungen, „Käufer dürfen an jede Adresse liefern lassen“, „alle Bestellungen zur Prüfung als Entwürfe einreichen“, Zahlungsziele	Das sind migrierte Einstellungen – setzen Sie sie also, wo möglich, vorher an der Quellkundin
Was nicht mitkommt	Steuerbefreiungen, die „durch Deaktivieren von Steuer erheben gesetzt wurden, werden nicht migriert“	Diese als echte Befreiungen am Standort neu setzen
Rücknahme – neues Unternehmen	Unternehmen löschen	Sauberes Undo, solange das Unternehmen neu und frei von B2B-Bestellungen ist
Rücknahme – bestehendes Unternehmen	Kundin entfernen, mit „einer Option, die ursprünglich migrierten Bestellungen zu entfernen“	Das Undo ist je Kundin, nicht je Bestellung
Voraussetzung	Bestehende D2C-Kundinnen im Admin	Weg A gilt nicht für Konten, die nie Shopify-Kundinnen waren

Durchsatz: was 20.000 Kundinnen wirklich kosten

Zwei verschiedene Antworten, eine je Weg.

Weg A ist Personal, nicht Durchsatz. 250 Kundinnen je Stapel ist der einzige Hebel. Zwanzigtausend Kundinnen sind achtzig Durchgänge im Admin, jeder mit jemandem, der die richtigen Kundinnen auswählt und das richtige Unternehmen trifft – die echte Beschränkung ist also, wie gut Ihre Zuordnungsdatei vorbereitet ist, nicht wie schnell Shopify ist. Bauen Sie die Zuordnung als Tabelle über dieselbe externalId, die auch an den Unternehmen steht, sortieren Sie sie so, dass jeder Stapel die Kundinnen eines Unternehmens ist, und das Klicken wird mechanisch statt zu einer Ermessensfrage, 20.000-mal.

Weg B ist Rate-Limit. Die Unternehmens-Mutations stehen nicht auf der Liste der Bulk-Operationen, es gibt also keinen JSONL-Import für Unternehmen: Es sind gewöhnliche API-Aufrufe gegen das Punktebudget des Tarifs. Die GraphQL-Admin-API füllt 100 Punkte pro Sekunde auf Standard, 200 auf Advanced, 1.000 auf Plus und 2.000 auf Commerce Components nach, keine einzelne Abfrage darf mehr als 1.000 Punkte kosten, und über dem Budget kommt 429 Too Many Requests zurück. Rechnen Sie Ihre Kosten je Unternehmen aus – ein companyCreate, das auch Standort und Kontakt anlegt, plus Rollenzuweisung, plus Katalogzuweisung –, multiplizieren Sie und teilen Sie durch die Auffüllrate. Das ergibt eine belastbare Zahl für den Plan; alles Genauere ist geraten, bis Sie Ihre eigenen Mutation-Kosten auf einem Entwicklungsshop gemessen haben.

Der Bestellimport in Weg B rechnet je Bestellung genauso, und Bestellungen sind die große Zahl: Ein Shop mit 20.000 Kundinnen und fünf Jahren Historie importiert Hunderttausende Datensätze – ein geplanter Job über Tage, mit Idempotenz über die Bestellnummer der Quelle, damit ein Neuversuch nichts doppelt anlegt.

Identität: der Teil, den niemand einplant

Die Migration ist ein Datenbereinigungsprojekt im Kostüm einer API. Drei Fragen entscheiden über die Dauer, und keine davon ist technisch:

• Was ist ein Unternehmen? Die Kundendatensätze des Quellsystems sind meist eine Mischung aus Organisationen, Filialen und Lieferadressen, und die Antwort auf „ist das ein Unternehmen mit vier Standorten oder sind es vier Unternehmen?“ ändert Kataloge, Ziele und Auswertung. Klären Sie das mit Finanz- und Vertriebsseite der Händlerin, bevor Sie bauen.
• Wer ist Kontakt, und an welchem Standort? Eine Person kauft oft für mehrere Filialen. Shopifys Modell erlaubt einem Kontakt eine Rolle an einem Standort; ob Ihre Quelldaten sagen können, für welche Standorte jede Person kauft, ist die Frage, die früh zu beantworten ist – die Rollenzuweisung ist das Tor zum Bestellimport.
• Welche Dubletten sind echt? Zwei Kundendatensätze mit derselben E-Mail sind eine Person; zwei mit demselben Firmennamen und verschiedenen E-Mails können zwei Filialen sein oder eine Filiale und ein Tippfehler. Lösen Sie über die externalId aus dem Quellsystem auf, nicht über Namensähnlichkeit, und heben Sie die verworfenen Treffer in einer Datei auf – danach wird gefragt.

Eine praktische Regel, die Nacharbeit spart: Entscheiden Sie im Migrationsskript nichts, was ein Mensch entscheiden sollte. Das Skript legt an, was die Zuordnungsdatei sagt; in der Zuordnungsdatei sitzt das Urteil, und sie kann von jemandem geprüft werden, der die Konten kennt.

Pilot, dann Cutover

Pilotieren Sie mit einem Unternehmen mit mindestens zwei Standorten und einem Kontakt, der für beide kauft. Dieses eine Testbild fordert jede Grenze der Tabelle heraus: Die Historie kann nur auf einem der beiden Standorte landen, die Ziele können sich je Standort unterscheiden, der Kontakt braucht an beiden eine Rolle, und die Rücknahme muss aus einem Zustand getestet werden, in dem Bestellungen bereits umgezogen sind.

Fahren Sie es zuerst auf einem Entwicklungsshop, dann im Produktivshop mit einem echten, aber kleinen Konto. Prüfen Sie in dieser Reihenfolge: Die Käuferin meldet sich an und sieht ihre Preise; eine Testbestellung trägt die richtigen Ziele; die historischen Bestellungen erscheinen am richtigen Standort; die Rücknahme bringt Kundin und migrierte Bestellungen zurück; und Ihre Abstimmabfrage passt, nachdem stornierte und gelöschte Bestellungen ausgenommen sind.

Erst dann starten Sie die Stapel. Führen Sie ein Protokoll, welche Kundinnen in welchem Stapel und zu welchem Unternehmen gingen – der Admin gibt Ihnen keines, und es ist das Artefakt, das Sie brauchen, wenn in drei Monaten jemand fragt, warum die Historie eines Kontos kurz aussieht.

Wo eine Angebotsebene dabei steht

Als eine Implementierung gekennzeichnet. Eine Angebotsebene, die Shopify liest statt eine eigene Kopie der Kundenliste zu führen, ist von der Migration in der einen Richtung unberührt und in der anderen abhängig: Sie braucht Unternehmensbaum und Kataloge (Schritte 1 bis 6), bevor sie einen unternehmensbezogenen Preis anbieten kann, und sie braucht nichts aus dem Historienschritt. Angebote können also live gehen, sobald Identität und Preise stehen – meist Wochen vor dem letzten Admin-Stapel.

QuotWay arbeitet so: Der Vorschlag an einen angemeldeten Unternehmenskontakt startet vom Katalogpreis seines Unternehmensstandorts, zur Anfragezeit aufgelöst, und das angenommene Angebot wird zu einem Bestellentwurf mit purchasingEntity und den Zahlungszielen des Standorts. Es speichert weder Kundenliste noch Preisliste selbst, es gibt auf seiner Seite also nichts zu migrieren. Unternehmensbezogene Angebote sind der Enterprise-Tarif; die Seite dazu ist die Funktionsseite zu Shopify-B2B-Angeboten, die Architektur dahinter steht in was in Shopify lebt und was in die Angebotsebene gehört, und die Tarife auf der Preisseite.

Die Shopify-Fakten in diesem Beitrag werden in der Shopify-B2B-Referenz aktuell gehalten.

Häufige Fragen

Kann ich Großhandelskunden per API zu Shopify-Unternehmen migrieren?

Unternehmen, Standorte und Kontakte können Sie über die Admin-API anlegen, aber nicht die bestehende Shopify-Bestellhistorie einer Kundin verschieben: Shopify-Mitarbeitende haben im Dezember 2025 bestätigt, dass die Migrations- und Rücknahme-Mutations intern und nicht öffentlich verfügbar sind. Dieser Schritt läuft im Admin, bis zu 250 Kundinnen auf einmal. Historische Bestellungen von außerhalb Shopifys sind eine andere Aufgabe und haben sehr wohl eine API – orderCreate mit einem Unternehmensstandort an der Bestellung.

Wandert die Bestellhistorie mit, wenn eine Kundin Unternehmenskontakt wird?

Nur wenn Sie sie bewusst migrieren. Eine Kundin über die Admin-Migration einem Unternehmen hinzuzufügen, bringt ihre D2C-Bestellhistorie mit; eine Kundin über die API als Kontakt zuzuweisen, trägt für sich genommen keine Historie. B2B-Bestellungen wechseln nie das Unternehmen.

Kann ich einen Teil der Bestellhistorie migrieren?

Nein. Shopifys Dokumentation ist eindeutig: „Sie können nur die vollständige Bestellhistorie einer Kundin einem Unternehmen hinzufügen, eine teilweise Migration wird nicht unterstützt.“ Stornierte und gelöschte Bestellungen sind ganz ausgeschlossen.

Kann die Historie einer Kundin auf zwei Unternehmensstandorte aufgeteilt werden?

Nein. Bestellungen können nicht auf mehrere Standorte aufgeteilt werden, eine Käuferin, die für drei Filialen bestellt hat, landet also auf einem Standort. Halten Sie fest, welchen Sie gewählt haben und warum – sonst sieht die Auswertung nach Standort für alle, die den Shop erben, falsch aus.

Wie migriere ich 20.000 Großhandelskundinnen?

Teilen Sie die Liste zuerst nach Weg. Für Konten, deren Bestellungen bereits Shopify-D2C-Bestellungen sind, sind es achtzig Admin-Stapel zu 250 – die Arbeit steckt in einer Zuordnungsdatei, die jeden Stapel mechanisch macht. Für Konten, deren Historie im Altsystem liegt, wird es geskriptet: Baum über die Admin-API im Rate-Limit des Tarifs, dann Bestellimport mit orderCreate, idempotent über die Bestellnummer der Quelle.

Lässt sich eine Migration rückgängig machen?

Teilweise. Ein neu angelegtes Unternehmen kann gelöscht werden, was Kundin und migrierte Bestellungen zurückbringt. Eine Kundin aus einem bestehenden Unternehmen zu entfernen, bietet an, die migrierten Bestellungen mitzunehmen. Keines davon gibt ein Undo je Bestellung – deshalb kommt die Historie zuletzt.

Brauche ich Shopify Plus für die Migration zu Unternehmen?

Nein. B2B gibt es auf jedem Shopify-Tarif, Unternehmen, Standorte, Kontakte und Zahlungsziele sind also unabhängig davon verfügbar. Plus ändert die Katalogseite – unbegrenzt aktive Kataloge und direkte Zuweisung an Unternehmen oder Standort gegenüber drei aktiven Katalogen über alle B2B-Märkte darunter – und der Tarif setzt auch Ihr API-Rate-Limit, was das Tempo eines geskripteten Imports bestimmt.

Quellen

Shopify-Seiten, alle am 23. September 2026 in API-Version 2026-07 gelesen, sofern nicht anders datiert:

• Kunden zu B2B migrieren – die Nur-D2C-Regel, ganze Historie oder keine, keine Aufteilung auf Standorte, der 250er-Stapel, was mitkommt, die Rücknahmewege und der Ausschluss stornierter und gelöschter Bestellungen
• Historic orders linking to Company / Customer – Shopify Staff, 2. Dezember 2025: die Migrations- und Rücknahme-Mutations sind intern
• B2B-Bestellungen importieren – orderCreate mit companyLocationId und customer.toAssociate sowie die Anforderung der Rollenzuweisung
• companyCreate und companyAssignCustomerAsContact
• Start building for B2B – die Anlagereihenfolge und die Katalogvoraussetzung
• Rate-Limits der GraphQL-Admin-API – die Auffüllraten je Tarif und die 1.000-Punkte-Grenze je Abfrage
• Bulk-Importe (gelesen am 22. September 2026) – die Liste unterstützter Mutations, die die Unternehmens-Mutations nicht enthält
• Katalog-, Zahlungsziel- und Steuerregeln: die Shopify-B2B-Referenz, erneut geprüft am 22. und 23. September 2026

Wie sich QuotWay während einer Migration verhält, ist aus seiner eigenen Architektur und der oben verlinkten Dokumentation beschrieben.