Ein nachvollziehbarer Weg für eine der heikelsten SaaS-Übergaben

Bei einem SaaS-Verkauf lassen sich Domain, Quellcode und Dokumentation vergleichsweise sichtbar übergeben. Aktive Abonnements sind schwieriger: Sie stehen für laufende Kundenbeziehungen, zukünftige Rechnungen und den Zugang zum Produkt. Wird das Stripe-Konto nicht als Ganzes weitergeführt, entstehen im Zielkonto neue Abonnementobjekte. Damit ändern sich Kennungen, Zugriffsrechte, Webhooks und häufig auch Teile des Produktkatalogs. Genau diese Verbindung aus Abrechnung und Anwendung machte einen strukturierten Ablauf nötig.

MoveMRR behandelt die Migration deshalb nicht als bloßes Kopieren von Datensätzen. Verkäufer und Käufer sollen denselben Umfang, dieselben Zuordnungen und dieselben offenen Ausnahmen sehen. Ein Probelauf macht bekannte Probleme vor dem Live-Lauf sichtbar. Die Quellabonnements werden nicht beiläufig deaktiviert, sondern nach einer gewählten Strategie und erst im kontrollierten Ablauf. Anschließend liefern Einzelergebnisse und Kennungszuordnungen die Grundlage für Abstimmung, Anwendungsschwenk und Support.

Aleksandar Jovanovic ist Gründer und Entwickler von MoveMRR. Seine Arbeit verbindet Produktentwicklung, Web- und App-Entwicklung sowie Erfahrungen mit kleinen und wachsenden SaaS-Unternehmen. Neben MoveMRR betreibt er mit The CodeCave GmbH eine Softwareagentur und arbeitet an weiteren digitalen Produkten. Diese Nähe zu realen Übergaben prägt den nüchternen Produktansatz: Risiken werden benannt, Zuständigkeiten sichtbar gemacht und Ergebnisse nicht als Garantie verkauft.

Das Produkt wird öffentlich und mit direktem Kontakt zum Gründer entwickelt. Dadurch können ungewöhnliche Abrechnungsmodelle, Migrationsgrenzen und Rückmeldungen aus tatsächlichen Projekten in die Weiterentwicklung einfließen. Gleichzeitig bleibt die Grenze klar: MoveMRR ist weder Stripe noch eine Rechts-, Steuer- oder M&A-Beratung. Kontoeignung, Zahlungsdatenübertragung, Vertragsfragen und die endgültige Freigabe einer Transaktion müssen von Stripe und den jeweils qualifizierten Beteiligten bestätigt werden.

Erstens gilt: Der richtige Kontoweg kommt vor der Werkzeugwahl. Bei manchen Unternehmenskäufen kann das bestehende Stripe-Konto mit dem Unternehmen fortgeführt und dessen Inhaberschaft geändert werden. In anderen Fällen braucht der Käufer ein separates Konto. Ein Wechsel von Rechtsträger oder Land muss mit Stripe geklärt werden. MoveMRR setzt dort an, wo eine getrennte Kontomigration tatsächlich erforderlich und zulässig ist.

Zweitens müssen Produktversprechen die technischen Grenzen abbilden. Stripe kann berechtigte Kundendaten und unterstützte gespeicherte Zahlungsmethoden kopieren, aber keine bestehenden Subscription-Objekte, Rechnungen, Pläne, Gutscheine, Ereignisse oder Protokolle. Zielabonnements erhalten neue Kennungen. Nicht unterstützte Zahlungsmethoden, fehlende Standardzahlungsarten, Ablehnungen oder eine starke Kundenauthentifizierung können auch nach guter Vorbereitung eine Kundenaktion erfordern.

Ein Projekt prüft eingeschränkte API-Schlüssel, liest die erforderlichen Kontoinformationen und hilft bei der Zuordnung von Kunden, Produkten, Preisen, Gutscheinen und Abonnements. Abrechnungszyklen, laufende Testphasen, Metadaten und mehrere Positionen können im vorbereiteten Ablauf berücksichtigt werden. Ein Probelauf schreibt keine Live-Abonnements, zeigt aber bekannte Lücken, Warnungen und geplante Aktionen. Der Live-Lauf speichert Ergebnisse so, dass Wiederholungen nicht unbemerkt doppelte Objekte erzeugen.

Nach der Anlage im Zielkonto bleibt die Übergabe eine gemeinsame Aufgabe. Der Käufer muss neue Stripe-Kennungen in seiner Datenbank berücksichtigen, Zielschlüssel ausrollen, Webhook-Endpunkte und Signaturgeheimnisse umstellen sowie Kundenportal, Mahnwesen, Berichte und Berechtigungslogik prüfen. MoveMRR stellt Zuordnungen und Ausführungsergebnisse bereit; es kann nicht entscheiden, wie eine individuelle Anwendung ihre Zugriffsrechte modelliert oder welche steuerliche Behandlung richtig ist.

MoveMRR verarbeitet keine rohen Kartennummern. Berechtigte Zahlungsdaten werden über den von Stripe vorgesehenen Kopierprozess übertragen. Für den Migrationsablauf werden zweckgebundene eingeschränkte Schlüssel verwendet und die benötigten Berechtigungen geprüft. Gespeicherte Live-Schlüssel liegen im Supabase Vault, laufen in MoveMRR nach 30 Tagen ab und werden nach der Speicherung nicht wieder an den Browser ausgegeben. Der Kontoinhaber widerruft sie nach dem Projekt weiterhin selbst in Stripe.

Ein erfolgreicher technischer Lauf ist dennoch nicht gleichbedeutend mit einem garantierten Geschäftsergebnis. Banken können spätere Zahlungen ablehnen, SCA kann eine Authentifizierung verlangen und unbekannte Sonderfälle können manuelle Nacharbeit auslösen. Unsere Aufgabe ist, den bekannten Zustand, geplante Entscheidungen und tatsächliche Ergebnisse sichtbar zu machen. Diese überprüfbare Grundlage ist wertvoller als die Behauptung, eine komplexe Migration sei grundsätzlich risikofrei.