Irgendwann kommt für die meisten Subscription-Unternehmen der Moment, in dem das bestehende Abrechnungssystem an seine Grenzen stößt. Vielleicht ist es eine selbst gebastelte Lösung in einer Tabellenkalkulation, die bei 200 Kunden nicht mehr handhabbar ist. Vielleicht ist es ein veraltetes System ohne E-Rechnungs-Support oder ohne DATEV-Schnittstelle. Vielleicht fehlen Webhooks, eine REST-API oder die Möglichkeit zur Provisionsverwaltung. Was auch immer der Auslöser ist: Die Entscheidung, die Subscription-Software zu wechseln, ist leichter gefällt als umgesetzt. Denn anders als bei vielen anderen Softwarewechseln betrifft eine Migration hier das Herzstück des Geschäftsbetriebs – laufende Kundenverträge, aktive Zahlungsmandate und ein ununterbrochener Abrechnungsrhythmus.

Phase 1: Bestandsaufnahme und Datenmapping

Jede erfolgreiche Migration beginnt mit einer vollständigen Bestandsaufnahme der vorhandenen Daten. Welche Kundendaten liegen im alten System vor? Welche Vertragsstrukturen müssen abgebildet werden – Tarife, Laufzeiten, Kündigungsfristen, Sonderkonditionen? Welche offenen Rechnungen und Forderungen sind zu berücksichtigen? Welche historischen Buchungsdaten werden für die Buchhaltung und steuerliche Prüfpfade benötigt?

Parallel dazu steht das Datenmapping: Wie entsprechen die Datenstrukturen des alten Systems denen des neuen? Ein Kunde im Altsystem hat vielleicht eine andere Feldstruktur als im neuen – Unterschiede bei Adressfeldern, Steuernummern, Zahlungsreferenzen oder Tarifbezeichnungen müssen identifiziert und Transformationsregeln definiert werden. Diese Phase ist oft mühsamer als erwartet, weil Altsysteme häufig inkonsistente oder unvollständige Daten enthalten.

Phase 2: Parallelbetrieb in der Sandbox

Bevor auch nur ein einziger Produktivdatensatz migriert wird, empfiehlt sich ein ausgedehnter Parallelbetrieb in der Sandbox-Umgebung des neuen Systems. Testdaten – idealerweise eine repräsentative Teilmenge der realen Kundendaten – werden importiert, alle Tarife und Konfigurationen werden eingerichtet und alle Kernprozesse werden durchgespielt: Vertragsabschluss, Rechnungslauf, Zahlungseinzug, Kündigung, Tarifwechsel, Mahnwesen.

Dieser Schritt deckt Lücken im Datenmapping auf, zeigt ob alle Tarife korrekt übertragen wurden und gibt dem Team die Möglichkeit, das neue System gründlich kennenzulernen, bevor es im Produktivbetrieb eingesetzt wird. Je gründlicher diese Phase, desto weniger Überraschungen im Go-live.

Phase 3: Migration der Zahlungsmandate

Der technisch heikelste Schritt jeder Subscription-Migration ist die Übertragung der Zahlungsmandate. Bei Kreditkartenzahlungen liegen die eigentlichen Kartendaten nicht im Abrechnungssystem, sondern tokenisiert beim Payment-Provider. Wechselt man auch den Payment-Provider, müssen Kunden im ungünstigsten Fall ihre Zahlungsdaten erneut eingeben – was Reibung erzeugt und Churn auslösen kann.

Viele Payment-Provider bieten jedoch Token-Migrationsservices an, über die bestehende Zahlungstoken auf einen neuen Provider übertragen werden können, ohne dass der Kunde aktiv werden muss. Bei SEPA-Lastschriften ist die Situation einfacher: Das Mandat ist an den Gläubiger gebunden. Wechselt der Gläubiger – also das Unternehmen – seine Gläubiger-Identifikationsnummer, muss dies dem Kunden vorab schriftlich mitgeteilt werden, das Mandat selbst bleibt aber gültig.

Phase 4: Gestaffelter Go-live

Ein Fehler, den viele Unternehmen bei der Migration begehen, ist der Versuch, alle Kunden gleichzeitig auf das neue System umzustellen. Ein gestaffelter Go-live ist deutlich risikoärmer: Zunächst werden Neukunden ausschließlich im neuen System angelegt. Dann werden Bestandskunden in Wellen migriert – beginnend mit den einfachsten Vertragsstrukturen, endend mit den komplexesten Sonderfällen.

Während der Übergangszeit laufen beide Systeme parallel – das Altsystem für die noch nicht migrierten Bestandskunden, das neue System für Neukunden und die bereits migrierten Verträge. Das erfordert klare Prozesse und eine gute Kommunikation im Team, vermeidet aber das Risiko eines kompletten Systemausfalls im Falle von Migrationsproblemen.

Phase 5: Datenabgleich und Hypercare

Unmittelbar nach dem Go-live beginnt die Hypercare-Phase: ein intensives Monitoring aller abrechnungsrelevanten Prozesse. Werden Rechnungen korrekt erstellt? Stimmen die Beträge? Werden Zahlungen korrekt eingezogen und den richtigen Verträgen zugeordnet? Funktionieren Webhooks und Systemintegrationen zuverlässig? Diese Phase dauert typischerweise ein bis zwei vollständige Abrechnungszyklen – also mindestens einen Monat.

Fakturia unterstützt Neukunden im Rahmen des Premium-Onboardings gezielt durch den gesamten Migrationsprozess: von der Sandbox-Einrichtung über das Datenmapping bis zur Übertragung aller Einstellungen in die Produktivumgebung. Wer eine sorgfältige Migration plant und sich dabei professionelle Unterstützung holt, wechselt nicht nur das System – sondern schafft die Grundlage für einen Abrechnungsbetrieb, der langfristig skaliert und keine manuellen Notlösungen mehr benötigt.