Zum Hauptinhalt springen

Aktueller Produktablauf · 11 Prüfpunkte

Alle Stripe-Abonnements migrieren — ohne beim Cutover zu raten

Dies ist die vollständige MoveMRR-Betriebsanleitung: was du anklickst, warum jede Phase existiert, was schiefgehen kann und welche Nachweise du vor dem nächsten Schritt brauchst.

Der Ablauf

Verbinden → Katalog → Kunden → Konfigurieren → Proben → Starten → Prüfen

Aktive Arbeitszeit

Etwa 1–2 Stunden plus Stripe-Verarbeitung

Erforderlicher Zugriff

Stripe-Adminzugriff auf Quelle und Ziel

Sicherer Standard

Vor Live zuerst in der Sandbox proben

?

Eine Entscheidung vor dem Start

Wenn deine Stripe-Sandboxes bereits realistische Abonnements und Katalogdaten enthalten, folge dieser Anleitung direkt. Sind sie leer, stoppe nach „Verbinden“, nutze die separate Seeding-Anleitung und kehre anschließend zum Katalog zurück.

Hauptanleitung starten Meine Sandboxes sind leer →
1 Vor dem Start

Beide Stripe-Konten vorbereiten und eine Umgebung wählen

Eine Migration ist ein koordinierter Cutover zwischen einem Quellkonto des Verkäufers und einem Zielkonto des Käufers. Klare Rollen verhindern den gefährlichsten späteren Fehler: Objekte im falschen Konto anzulegen oder zu kündigen.

So gehst du vor

  1. 1

    Auf beiden Seiten eine verantwortliche Person bestimmen

    Halte je eine Person mit Stripe-Administratorzugriff auf Quell- und Zielkonto verfügbar. Beide sollten Zwei-Faktor-Authentifizierung aktiviert haben und eingeschränkte API-Schlüssel erstellen können.

  2. 2

    Sandbox oder Live-Migration wählen

    Beginne in der Sandbox für eine risikofreie Probe im Stripe-Testmodus. Sandbox-Projekte sind kostenlos, verwenden Testschlüssel und benötigen keinen Haftungsausschluss. Wähle Live nur für den Produktions-Cutover; dabei entstehen echte Abonnements, echte Abrechnung kann betroffen sein und eine Migrationslizenz wird verbraucht.

  3. 3

    Ein ruhiges Betriebsfenster festlegen

    Vermeide Änderungen an Produkten, Preisen, Gutscheinen, Kunden und Abonnements während der finalen Probe und des Live-Laufs. Ist eine Änderung nötig, schließe sie zuerst ab und prüfe anschließend die Bereitschaft erneut.

  4. 4

    Zielkonto-ID notieren

    Kopiere im Stripe-Dashboard des Zielkontos die mit acct_ beginnende Konto-ID. Du benötigst sie, wenn das Quellkonto den Customer Data Copy startet.

Erst fortfahren, wenn

  • Du kannst zwischen beiden Stripe-Konten wechseln, ohne den Zugriff zu verlieren.
  • Du weißt eindeutig, welches Konto Quelle und welches Ziel ist.
  • Du hast entschieden, ob dieses Projekt eine Sandbox-Probe oder der Live-Cutover ist.

Achtung

Ein MoveMRR-Sandbox-Projekt und eine Stripe-Sandbox gehören zusammen, sind aber nicht dasselbe: Das MoveMRR-Projekt verbindet zwei Stripe-Testumgebungen. Sind sie leer, nutze nach „Verbinden“ die optionale Seeding-Anleitung.

2 Projekt einrichten

Das Migrationsprojekt anlegen

Das Projekt ist der dauerhafte Arbeitsbereich für Schlüssel, Zuordnungen, Konfiguration, Proben, Läufe, Auditverlauf und Prüfung. Die siebenstufige Leiste links dient gleichzeitig als Live-Checkliste.

So gehst du vor

  1. 1

    Migrationen öffnen

    Wähle in der MoveMRR-Seitenleiste „Migrations“ und danach „New migration“. In einem leeren Konto nutzt du „Create your first migration“.

  2. 2

    Umgebung auswählen

    Wähle Sandbox für Testschlüssel und Testdaten oder Live migration für die Produktion. Diese Wahl steuert Schlüsselprüfung, Lizenz, Haftungsausschluss und welche Stripe-Objekte verändert werden dürfen; sie ist keine rein visuelle Kennzeichnung.

  3. 3

    Projekt benennen

    Verwende einen Namen, der beide Seiten nennt, etwa „Acme → BuyerCo · Produktion“. Ergänze Deal-Datum oder Cutover-Fenster in der Beschreibung, damit der Auditverlauf später verständlich bleibt.

  4. 4

    Projekt erstellen

    Wähle „Create migration“. MoveMRR öffnet die erste unvollständige Phase. Es gibt keinen Easy-/Advanced-Modus: Jedes Projekt folgt demselben Ablauf; empfohlene Aktionen stehen zuerst, manuelle Kontrollen bleiben bei Bedarf verfügbar.

MoveMRR-Ansicht für Schritt 2

Erst fortfahren, wenn

  • Das Umgebungs-Badge zeigt wie beabsichtigt SANDBOX oder LIVE.
  • Der Projektname macht die Migrationsrichtung eindeutig.
  • Die Seitenleiste zeigt Connect, Catalog, Customers, Configure, Rehearse, Launch und Verify.
3 Phase 1 · Verbinden

Beide Stripe-Schlüssel erzeugen, prüfen und speichern

MoveMRR muss das Quellkonto lesen und zugeordnete Objekte im Ziel anlegen. Eingeschränkte Schlüssel begrenzen diesen Zugriff auf die für die Migration erforderlichen Rechte.

So gehst du vor

  1. 1

    Mit der Karte des Quellkontos beginnen

    Wähle „Generate“. Der Dialog erstellt einen Stripe-Deep-Link mit vorausgewählten Rechten. Prüfe vor dem Öffnen, dass das genannte Stripe-Konto das Verkäufer-/Quellkonto ist und Live- oder Testmodus zum Projekt passt.

  2. 2

    Eingeschränkten Schlüssel in Stripe erstellen und kopieren

    Öffne den erzeugten Stripe-Link, prüfe die Rechte, erstelle den Schlüssel und kopiere ihn sofort. Stripe zeigt das vollständige Secret nur einmal. Kehre zu MoveMRR zurück, füge es im Feld Source ein und wähle „Validate & store“.

  3. 3

    Für das Ziel wiederholen

    Wiederhole den Vorgang über die Destination-Karte im Stripe-Konto des Käufers. Der Zielschlüssel benötigt Schreibrechte, weil MoveMRR dort Produkte, Preise, Gutscheine, Abonnements und — falls gewählt — Stripe-Webhook-Endpunkte anlegt.

  4. 4

    Stripe-Connect-Konten bei Aufforderung auflösen

    Gehört ein Schlüssel zu einer Connect-Plattform, wähle das verbundene Konto, dem die Abonnements tatsächlich gehören. „Acting as the platform account“ bedeutet, dass kein verbundenes Konto gewählt wurde. Gib den Schlüssel erneut ein, wenn du ein verbundenes Konto anwendest, da gespeicherte Secrets nie an den Browser zurückgegeben werden.

  5. 5

    Migration von Stripe-Webhook-Endpunkten entscheiden

    Wenn aktiviert, fordert MoveMRR zusätzliche Endpoint-Rechte an und erstellt die Stripe-Webhook-Endpunkte der Quelle beim Cutover im Ziel neu. Jeder neue Endpoint erhält ein neues whsec_-Signatur-Secret, das nach dem Lauf ausgerollt werden muss.

MoveMRR-Ansicht für Schritt 3

Erst fortfahren, wenn

  • Beide Karten zeigen Stored und Validated.
  • Die angezeigten Konto-IDs entsprechen der vorgesehenen Quelle und dem Ziel.
  • Beide Schlüssel zeigen den richtigen LIVE- oder TEST-Modus.
  • Connect ist in der Phasenleiste vollständig.

Achtung

Füge niemals einen Live-Schlüssel in ein Sandbox-Projekt oder einen Testschlüssel in ein Live-Projekt ein. Nutze „Generate“ auf der richtigen Karte, statt Rechte manuell zu erraten.

Gut zu wissen

Schlüssel werden verschlüsselt gespeichert und nach dem Speichern nicht an den Browser zurückgegeben. Der Zugriff läuft in MoveMRR nach 30 Tagen ab; „Rotate“ setzt diese Frist zurück. Der Kontoinhaber widerruft den Schlüssel nach dem Projekt weiterhin selbst in Stripe.

Referenz für eingeschränkte Stripe-Schlüssel →
4 Optionaler Zweig · nur Sandbox

Enthalten deine Stripe-Sandboxes bereits realistische Daten?

Eine Sandbox-Migration ist nur aussagekräftig, wenn sie dieselben Katalog- und Abonnementformen wie die Produktion durchläuft. Seeding bleibt bewusst außerhalb des Hauptpfads, weil viele Teams bereits repräsentative Sandboxes pflegen.

So gehst du vor

  1. 1

    Wenn deine Sandboxes bereit sind

    Überspringe das Seeding und fahre direkt mit dem Katalog fort. „Bereit“ bedeutet: Die Quell-Sandbox enthält die zu testenden Produkte, Preise, Gutscheine, Kunden und Abonnements, und die Ziel-Sandbox ähnelt dem Käuferkonto genug, um Zuordnungskonflikte sichtbar zu machen.

  2. 2

    Wenn eine Sandbox leer ist

    Öffne auf der Connect-Seite den Arbeitsbereich „Sandbox Seeding“. Die separate Anleitung behandelt Live-Schlüsselprüfung mit Lesezugriff, Seeding von Quelle und Ziel, Vorschauzahlen, Objektauswahl, Laufergebnisse, Kundensynchronisierung und die erzeugte Zuordnungs-CSV.

  3. 3

    Nach der Kundensynchronisierung zurückkehren

    Die Seeding-Anleitung führt hierher zurück. Fahre mit dem Katalog fort; verwende bei „Customers“ die von Customer sync erzeugte Zuordnungs-CSV statt Stripe Customer Data Copy.

MoveMRR-Ansicht für Schritt 4

Erst fortfahren, wenn

  • Abonnements in der Quell-Sandbox verweisen auf realistische Quellpreise.
  • Die Ziel-Sandbox enthält den bereits vorhandenen Käuferkatalog, gegen den du testen möchtest.
  • Du weißt, ob Customers die Stripe-CSV für Live oder die erzeugte Customer-sync-CSV für Sandbox nutzt.
Vollständige Sandbox-Seeding-Anleitung öffnen →
5 Phase 2 · Katalog

Produkte, Preise, Gutscheine und Promotion Codes zuordnen

Abonnements verweisen auf unveränderliche Stripe-Preis-IDs. Ein Zielabonnement kann die Quellpreis-ID nicht verwenden; deshalb muss jeder benötigte Quellpreis vor der Probe zum richtigen Zielpreis aufgelöst sein.

So gehst du vor

  1. 1

    Abdeckungsleiste lesen

    Products, Prices und Coupons zeigen geprüfte Zahlen für zugeordnet/erforderlich. „Source total unknown“ ist nicht null; starte den passenden Scan. Fahre nicht fort, solange ein erforderliches Segment nicht zugeordnet oder nicht prüfbar ist.

  2. 2

    Katalog automatisch migrieren

    Wähle die hervorgehobene Aktion „Migrate catalog automatically“, prüfe den Plan und bestätige. MoveMRR erstellt fehlende Zielprodukte und aktive Preise, speichert Zuordnungen und verarbeitet Gutscheine sowie Promotion Codes. Beobachte jeden Teilschritt und prüfe die Ergebnisse, statt den Dialog sofort zu schließen.

  3. 3

    Produkte prüfen

    Bestätige, dass Zielprodukte dieselben Pläne oder Add-ons repräsentieren. Eine Zuordnung ist eine Identitätsentscheidung: Zwei Produkte dürfen nur dann verbunden werden, wenn sie für Abrechnung und Anwendung dasselbe bedeuten.

  4. 4

    Preise auflösen

    Öffne Prices und filtere nach Unmapped. Nutze Auto-suggest erst nach Prüfung von Betrag, Währung, Intervall, Nutzungsart, Staffelung und Produkt. Verwende bei großen Katalogen Bulk import, ansonsten eine manuelle Zuordnung.

  5. 5

    Gutscheine und Promotion Codes auflösen

    Öffne Coupons, scanne die Quelle und erstelle oder ordne verbleibende Einträge automatisch beziehungsweise manuell zu. Prüfe die Gutschein-Nutzung, damit kein von einem migrierenden Abo verwendeter Gutschein übersehen wird.

MoveMRR-Ansicht für Schritt 5

Erst fortfahren, wenn

  • Die erforderliche Produkt- und Preisabdeckung ist vollständig.
  • Jeder zugeordnete Preis hat dieselbe wirtschaftliche Bedeutung, Währung, denselben Betrag und dasselbe Intervall.
  • Von migrierenden Abonnements verwendete Gutscheine sind abgedeckt.
  • Jedes automatische Ergebnis mit Status skipped oder failed wurde geprüft.

Achtung

Ordne nicht allein nach einem ähnlichen Namen zu. „Pro Monthly“ kann sich bei Währung, Betrag, Steuerverhalten, Nutzungsart oder Intervall unterscheiden. Diese Unterschiede verändern die Kundenabrechnung.

6 Außerhalb von MoveMRR · Live-Projekte

Kunden- und Zahlungsdaten in Stripe kopieren

MoveMRR erstellt Abonnements neu, nicht Kartendaten. Stripe Customer Data Copy überträgt Kunden und wiederverwendbare Zahlungsmethoden-Referenzen sicher und erzeugt die von MoveMRR benötigte Zuordnung alter zu neuer Kunden-IDs.

So gehst du vor

  1. 1

    Kopie im Quellkonto starten

    Öffne im Stripe-Dashboard der Quelle Customers, wähle Copy und danach Copy all customers. Trage die Zielkonto-ID ein oder wähle sie und sende die Anfrage. Weicht die Oberfläche ab, suche in Stripe nach „Copy customers“, während du im Quellkonto bleibst.

  2. 2

    Im Zielkonto annehmen

    Wechsle zum Stripe-Zielkonto. Öffne Customers und akzeptiere die eingehende Kopieranfrage. Prüfe vor „Accept“, dass das Banner das erwartete Quellkonto nennt.

  3. 3

    Auf Stripe warten

    Lade keine unvollständige oder ältere Zuordnung hoch. Stripe verarbeitet die Übertragung asynchron; warte, bis die Kopie abgeschlossen und das Dokument „Data Migrations“ verfügbar ist.

  4. 4

    Zuordnungs-CSV herunterladen

    Öffne im Zielkonto Settings → Compliance and documents → My documents. Suche das Data-Migrations-Dokument für genau dieses Quell-/Zielpaar und wähle Download.

Erst fortfahren, wenn

  • Die Zielanfrage nennt das richtige Quellkonto.
  • Die Zahl kopierter Kunden ist für den Migrationsumfang plausibel.
  • Die heruntergeladene CSV gehört zu dieser und nicht zu einer früheren Übertragung.

Achtung

Öffne und speichere die CSV nicht mit Excel, Numbers oder Google Sheets. Diese Programme können IDs, Anführungszeichen, Kodierung oder führende Zeichen verändern. Lade die originale Stripe-Datei hoch.

Was Stripe Customer Data Copy umfasst →
7 Phase 3 · Kunden

Kundenzuordnung hochladen und prüfen

Die Kundenzuordnung verbindet jede Quellkunden-ID mit dem von Stripe erzeugten Zielkunden. Ohne gültige Zeile kann MoveMRR das neu erstellte Abonnement oder die Zahlungsmethode dieses Kunden nicht sicher zuordnen.

So gehst du vor

  1. 1

    Richtige Zuordnungsquelle wählen

    Verwende für ein Live-Projekt die unveränderte, von Stripe geladene CSV. Öffne bei einem geseedeten Sandbox-Projekt Customer sync im Seeding-Arbeitsbereich; der abgeschlossene Lauf erzeugt und lädt die Zuordnung automatisch hoch.

  2. 2

    CSV hochladen

    Wähle auf Customers die Datei im Upload-Bereich aus oder ziehe sie hinein. Warte, bis Processing abgeschlossen ist. MoveMRR prüft Dateistruktur, doppelte IDs, Zeilenwerte und Kontokompatibilität, bevor der Upload als Valid markiert wird.

  3. 3

    Ausgewählten Upload prüfen

    Der Arbeitsbereich wählt automatisch den neuesten gültigen Upload. Prüfe Zeilenanzahl und ungültige Zeilen. Wenn du eine Korrektur hochlädst, stelle vor der Probe sicher, dass der neue Dateiname gewählt ist.

  4. 4

    Abdeckung der Zahlungsmethoden prüfen

    Starte den Zahlungsmethoden-Scan. Untersuche Kunden ohne nutzbare Standardzahlungsart jetzt; sonst kann ihr Abonnement ohne die für die nächste Verlängerung nötige Zahlungseinrichtung entstehen.

MoveMRR-Ansicht für Schritt 7

Erst fortfahren, wenn

  • Mindestens ein Upload ist als Valid markiert.
  • Die Zahl der Zuordnungen entspricht der erwarteten Kundenpopulation.
  • Der aktuell ausgewählte Upload ist die beabsichtigte Datei.
  • Lücken bei Zahlungsmethoden sind verstanden oder behoben.

Achtung

Erstelle niemals eine Zuordnung durch Abgleich von E-Mail-Adressen. E-Mails sind weder eindeutig noch unveränderlich. Nutze die von Stripe erzeugten alten und neuen Kunden-IDs.

8 Phase 4 · Konfigurieren

Migrationsverhalten prüfen — besonders die Deaktivierung der Quelle

Die Konfiguration bestimmt, was angelegt wird, was mit den Verkäufer-Abonnements geschieht und wie Abrechnungsdaten, Testphasen, Metadaten und Kunden mit mehreren Abonnements behandelt werden. Die Standards sind sicher, müssen aber ausdrücklich geprüft werden.

So gehst du vor

  1. 1

    Umfang bestätigen

    Lasse „Migrate subscriptions“ für die Kernmigration aktiviert. „Migrate products“ steuert die Katalogerstellung. Aktiviere „Migrate Stripe webhook endpoints“ nur, wenn du bereit bist, die nach dem Lauf angezeigten neuen whsec_-Secrets auszurollen.

  2. 2

    Deaktivierung der Quelle wählen

    „Cancel at period end“ ist der Standard: Die Quelle endet nach dem bezahlten Zeitraum, während das Ziel den Abrechnungsplan erhält. „Cancel immediately“ ist ein harter Cutover und kann durch Rollback nicht automatisch reaktiviert werden. „Pause collection“ belässt das Quellabo, stoppt aber den Einzug. „None“ erfordert manuelle Deaktivierung und birgt bis dahin Doppelabrechnungsrisiko.

  3. 3

    Erweiterte Einstellungen prüfen

    Atomare Verarbeitung mehrerer Abos verschiebt für einen Kunden alle Abonnements gemeinsam oder keines. Entscheide, ob alle, ausgewählte oder keine Metadaten kopiert, Testphasen erhalten oder beendet und Abrechnungszyklen erhalten, neu ausgerichtet oder neu gestartet werden. „Preserve“ überrascht Kunden am wenigsten.

  4. 4

    Speichern oder Standards bestätigen

    Nutze bei Änderungen die fixierte Save-Leiste. Stimmen die empfohlenen Werte bereits, wähle „Confirm defaults“. Die Phase ist erst vollständig, wenn MoveMRR deine Prüfung gespeichert hat.

MoveMRR-Ansicht für Schritt 8

Erst fortfahren, wenn

  • Der Umfang enthält nur die Objekttypen, die du migrieren möchtest.
  • Die Folge der Quelldeaktivierung ist für Verkäufer und Käufer akzeptabel.
  • Abrechnungszyklus und Testphasen entsprechen den Kundenzusagen.
  • Configure wird in der Phasenleiste als reviewed angezeigt.

Achtung

Bei „None“ können beide Stripe-Konten dieselben Kunden abrechnen, bis du die manuelle Deaktivierungsliste unter Verify abgearbeitet hast.

Wie Abrechnungsanker Verlängerungsdaten erhalten → Referenz zur Vermeidung von Doppelabrechnung →
9 Phase 5 · Proben

Bereitschaft prüfen, Plan im Dry Run testen und simulieren

Die Probe trennt „die Eingaben wirken vollständig“ von „dieser konkrete Migrationsplan verhält sich wie erwartet“. Keine dieser Prüfungen schreibt Produktionsabonnements.

So gehst du vor

  1. 1

    Validate readiness wählen

    Die Bereitschaftsprüfung kontrolliert Schlüssel, Katalogabdeckung, Kundenzuordnung, Konfiguration und weitere Startvoraussetzungen. Öffne fehlgeschlagene Prüfungen, kopiere gemeldete Objekt-IDs, behebe die Ursache und prüfe erneut.

  2. 2

    Dry Run ausführen

    Der Dry Run erzeugt den geplanten Aktionssatz, ohne die Migration auszuführen. Prüfe geplante Anlagen, Überspringungen, Deaktivierungen, Warnungen und Summen. Eine unerwartet niedrige Zahl deutet meist auf Umfangs- oder Zuordnungsprobleme, eine zu hohe auf eine falsche CSV oder ein falsches Konto.

  3. 3

    Simulation ausführen

    Die Simulation testet die Abonnementerstellung kontrolliert und liefert eine nähere Vorschau der Stripe-Antworten. Prüfe jede Fehlerkategorie und folge den Links zurück zu Catalog, Customers oder Configure.

  4. 4

    Nach Änderungen wiederholen

    Änderungen an Konfiguration, Zuordnungen, Schlüsseln oder CSV können frühere Bereitschaftsnachweise veralten lassen. Wiederhole Bereitschaft und Dry Run nach jeder wesentlichen Änderung; verlasse dich nicht auf ein altes grünes Ergebnis.

MoveMRR-Ansicht für Schritt 9

Erst fortfahren, wenn

  • Readiness enthält keine fehlgeschlagenen Prüfungen.
  • Die Dry-Run-Summen entsprechen der erwarteten Migrationspopulation.
  • Warnungen sind verstanden und nicht nur ignoriert.
  • Die neueste Probe entspricht aktuellen Zuordnungen, CSV und Konfiguration.

Achtung

Ein Dry Run ist ein Plan, kein Beweis, dass jeder Schreibvorgang gelingt. Nutze Dry Run und Simulation und halte danach das finale Live-Fenster frei von Konfigurationsänderungen.

10 Phase 6 · Starten

Alle Freigaben erfüllen, Lauf bestätigen und überwachen

Launch ist die kontrollierte Produktionsgrenze. Die Freigabe-Checkliste verhindert einen Start ohne Nachweise, die Bestätigung zeigt den exakten Umfang und die Laufkarte bleibt bis zum endgültigen Status die maßgebliche Quelle.

So gehst du vor

  1. 1

    Freigabe-Checkliste erfüllen

    Behebe jede blockierende Zeile: Schlüssel, Katalogabdeckung, Kundenzuordnung, Konfigurationsprüfung, aktuelle Bereitschaft, Lizenz und bei Live-Projekten den Haftungsausschluss. Sandbox-Projekte benötigen weder Haftungsausschluss noch Lizenz.

  2. 2

    Überfällige Abonnements entscheiden

    Die Einbeziehung past-due wird pro Lauf gewählt. Sie ist standardmäßig aus, weil die offene Quellrechnung storniert und die Abrechnung erst im nächsten regulären Zyklus neu gestartet wird. Aktiviere sie nur, wenn Verkäufer und Käufer diese buchhalterische Behandlung vereinbart haben.

  3. 3

    Sofort starten oder planen

    „Start migration“ öffnet die finale Bestätigung. Prüfe Kunden- und Preiszahl, Umgebung, Deaktivierungsstrategie, Dry-Run-Status und past-due-Auswahl. Ein geplanter Lauf erfordert zur geplanten Zeit eine Bestätigung; halte eine autorisierte Person verfügbar.

  4. 4

    Live-Lauf überwachen

    Halte die Laufkonsole offen. Fortschritt, Stripe-Drosselung, Fehler und sichere Aktionen erscheinen auf der Karte. Pause ist die sichere Bremse; kündige während eines aktiven Laufs keine Quellabonnements und bearbeite keine Zuordnungen in Stripe.

  5. 5

    Endergebnis bestätigen

    Lies nach Abschluss das Ergebnis und öffne für Fehler die Laufdetails. Das Bestätigen entfernt den Endstatus-Hinweis aus der Leiste; es löscht weder den Lauf noch seinen Auditverlauf.

MoveMRR-Ansicht für Schritt 10

Erst fortfahren, wenn

  • Alle Launch-Freigaben sind vor der Bestätigung grün.
  • Finale Zahlen und Umgebung sind korrekt.
  • Eine verantwortliche Person kann bis zum Endstatus überwachen.
  • Niemand bearbeitet Quellabonnements während der Ausführung manuell.

Achtung

Starte keinen zweiten Lauf, um einen aktiven Lauf „zu lösen“. Nutze Pause oder die ausdrücklich angebotene Wiederholungs-/Folgeaktion, nachdem der aktuelle Lauf einen Endstatus erreicht hat.

11 Phase 7 · Prüfen

Beide Konten abstimmen und den Cutover abschließen

Ein abgeschlossener Lauf ist nicht das Ende der Migration. Verify macht aus Laufergebnissen eine operative Übergabe: Fehler bereinigen, Quelle und Ziel abstimmen, neue Secrets ausrollen und bestätigen, dass Verlängerungen das Käuferkonto erreichen.

So gehst du vor

  1. 1

    Ergebnisüberschrift und Aufgabenliste lesen

    Beginne mit dem neuesten Live-Lauf. Erledige serverseitig abgeleitete Folgeaufgaben wie Fehlerwiederholung, Bereinigung, Aktionen geplanter Läufe, Zahlungsmethoden-Korrektur oder Rollback, wenn ausdrücklich verfügbar. Exportiere ID-Zuordnung und eine mögliche manuelle Deaktivierungsliste.

  2. 2

    Reconciliation erzeugen

    Vergleiche Quell- und Zielabonnements, Kunden, MRR je Währung und — falls gewählt — Stripe-Webhook-Endpunkte. Untersuche verwaiste Objekte und Abweichungen. MRR wird pro Währung gezeigt und darf nicht über Währungen summiert werden.

  3. 3

    Standardzahlungsarten korrigieren

    Scanne den Zahlungsmethodenstatus erneut und nutze die Korrekturaktion für Kunden, deren migrierte Zahlungsmethode vorhanden, aber nicht als Standard gesetzt ist. Exportiere verbleibende Ausnahmen für manuelle Arbeit.

  4. 4

    Anwendungs-Cutover ausrollen

    Ersetze geheime und veröffentlichbare Stripe-Zielschlüssel der Anwendung, aktualisiere gespeicherte Produkt-/Preis-IDs, ändere Customer-Portal- und Connect-Verweise und rolle jedes neue whsec_-Signatur-Secret aus, bevor du neu erstellten Endpunkten vertraust.

  5. 5

    Echte Verlängerungen überwachen

    Beobachte die erste Verlängerungskohorte im Zielkonto, bestätige die gewählte Quelldeaktivierung und überwache Webhook-Zustellung, fehlgeschlagene Zahlungen, Supportfälle und MRR. Bewahre Projekt- und Auditexporte als Migrationsnachweis auf.

MoveMRR-Ansicht für Schritt 11

Erst fortfahren, wenn

  • Die Aufgabenliste enthält keine ungelösten serverseitig abgeleiteten Folgeaufgaben.
  • Die Abstimmung ist erfolgreich oder jede Abweichung hat eine verantwortliche Person und schriftliche Erklärung.
  • Anwendungsschlüssel, Preisverweise, Portal-Links und Webhook-Secrets zeigen auf das Ziel.
  • Eine Stichprobe anstehender Verlängerungen war im Zielkonto erfolgreich.

Achtung

Lösche oder archiviere das Quellkonto nicht sofort. Halte es mindestens für das vereinbarte Prüfzeitfenster zugänglich, damit Rechnungen, Kündigungen, Streitfälle und Abstimmungsnachweise geprüft werden können.

Finale Übergabe

Die Migration ist fertig, wenn alle Nachweise übereinstimmen

Ein grüner Laufstatus allein reicht nicht. Betrachte die Migration erst als abgeschlossen, wenn Laufergebnisse, Aufgabenliste, Abstimmungsbericht, Zielkonfiguration, Webhook-Zustellung und echte Verlängerungen dieselbe Geschichte erzählen.

Häufige Fragen

Muss ich noch Easy oder Advanced Mode wählen?

Nein. Die Modusaufteilung wurde entfernt. Jede Migration nutzt denselben siebenstufigen Ablauf. Empfohlene Aktionen stehen zuerst; manuelle Zuordnungen und erweiterte Konfiguration bleiben in der jeweiligen Phase verfügbar.

Ist Sandbox Seeding erforderlich?

Nein. Überspringe es, wenn deine Stripe-Sandboxes bereits repräsentative Daten enthalten. Nutze es, wenn eine leere Sandbox die Probe wertlos machen würde. Seeding ist nur für MoveMRR-Sandbox-Projekte verfügbar.

Kann MoveMRR Kartendaten kopieren?

Keine Anwendung sollte dabei rohe Kartendaten verarbeiten. Bei Live-Migrationen überträgt Stripe Customer Data Copy Kunden- und wiederverwendbare Zahlungsmethoden-Referenzen. Für Sandbox-Tests erstellt Customer sync Kunden mit Stripe-Testzahlungsmethoden.

Was muss ich nach einer Änderung an Zuordnung oder Konfiguration tun?

Kehre zu Rehearse zurück und prüfe die Bereitschaft erneut. Erzeuge danach einen neuen Dry Run. Die Launch-Nachweise müssen aktuelle Schlüssel, CSV, Zuordnungen und Konfiguration beschreiben — nicht eine frühere Version.

Wann ist die Migration wirklich abgeschlossen?

Wenn der Lauf beendet, die Verify-Aufgabenliste leer, die Abstimmung akzeptiert, Anwendungsschlüssel und Webhook-Secrets ausgerollt und die ersten echten Verlängerungen im Zielkonto erfolgreich sind.

Öffne MoveMRR und behalte diese Anleitung daneben

Die Phasenleiste zeigt dir, wo du bist. Diese Anleitung erklärt, warum jede Entscheidung wichtig ist, bevor du sie triffst.

MoveMRR öffnen →