SMS-Panel-Migration: von SaaS zu selbst gehostet, schrittweise

Der Abschied von einem gemieteten SMS-Panel ist ein Projekt mit bekanntem Verlauf. Was schiefgeht, ist immer dasselbe: eine Absenderkennung, die auf den Namen des Anbieters registriert ist, ein API-Hostname, den Ihre Kunden fest einprogrammiert haben, ein Kontobuch, das sich nicht exportieren lässt, eine Umstellung an einem Freitag. Dies ist die Checkliste für die SMS-Panel-Migration, die wir verwenden, wenn wir einen Reseller auf seine eigene Plattform umziehen, so geschrieben, dass Sie sie mit jeder selbst gehosteten Plattform abarbeiten können. Sie beschreibt den Wechsel vom SaaS-Panel zu selbst gehostet in sieben Phasen: Bestandsaufnahme, Exporte, die neue Plattform, die Punkte, die nicht mitwandern, der Parallelbetrieb, die Umstellung und die Abschaltung des alten Panels. Ob Sie gehen sollten, klärt der Vergleich mit SaaS-Panels; dieser Leitfaden klärt, wie.

Phase 0: den Kalender nach dem langsamsten Punkt ausrichten

Bevor Sie Daten anfassen, listen Sie alles auf, was nach der Uhr eines anderen läuft: Neuregistrierungen von Absenderkennungen und Kurzwahlnummern auf Ihre eigene Gesellschaft, regulatorische Identitäten (DLT in Indien, 10DLC in den Vereinigten Staaten und ihre Entsprechungen anderswo), Freigaben der Netzbetreiber für Ihre eigenen SMPP-Binds und, wenn Sie WhatsApp hinzunehmen, die Unternehmensverifizierung durch Meta. Jeder dieser Punkte dauert Wochen, nicht Tage, und keiner lässt sich zu früh beginnen. Starten Sie alle in der ersten Woche, parallel zu allem, was unten folgt. Dann ist der Rest der Migration fertig und wartet auf sie, nicht umgekehrt.

Phase 1: die Bestandsaufnahme für die SMS-Panel-Migration

Notieren Sie aus der Admin-Konsole des Panels eine Zeile pro Punkt:

• Kunden: jedes Konto, sein Abrechnungsmodus (Prepaid-Guthaben, Wallet, Postpaid), sein aktuelles Guthaben, sein Preisplan, seine Ansprechperson und ob es über die Konsole, die HTTP-API oder einen SMPP-Bind angebunden ist.
• Preispläne und Routen: jeder Preisplan, jede Zielzeile, jede Lieferantenroute mit ihren Zugangsdaten und Kosten.
• Absenderkennungen und Nummern: alphanumerische Kennungen, Langnummern, Kurzwahlnummern und auf wessen Gesellschaft jede davon bei jedem Netzbetreiber registriert ist.
• Integrationen: jeder Hostname, den Ihre Kunden aufrufen (API, Panel-URL, Webhook-Endpunkte, an denen sie Zustellberichte empfangen), und ob er auf Ihrer Domain liegt oder auf der des Anbieters.
• Datenvolumen: Kontakte, Vorlagen, Kampagnenhistorie, Zustellprotokolle, Rechnungen, nach Monat.
• Verträge: die Kündigungsfrist des Panels und jeder Kundenvertrag, der den Namen oder die URL des Panels nennt.

Diese Bestandsaufnahme ist der Migrationsplan. Alles Weitere ist dieselbe Bestandsaufnahme, versehen mit Terminen.

Phase 2: echte Exporte holen, solange Sie noch Kunde sind

Fordern Sie die Exporte jetzt an, bevor Sie kündigen, denn die Antwort fällt freundlicher aus, solange Sie zahlen. Verlangen Sie jeden Punkt der Bestandsaufnahme in einem maschinenlesbaren Format (CSV genügt) und öffnen Sie jede Datei: Gleichen Sie die Zeilenzahlen mit der Konsole ab, prüfen Sie, ob die Einwilligungsnachweise mit den Kontakten mitkommen, und prüfen Sie, ob die Zustellprotokolle die Nachrichten-ID und den endgültigen Status enthalten und nicht nur eine Summe. „Wir unterstützen CSV-Export“ und „die Datei enthält, was meine Kunden brauchen würden“ sind zwei verschiedene Sätze.

Rechnen Sie damit, dass das Kontobuch das am wenigsten portable Stück im ganzen Haus ist: Guthaben und Rechnungshistorie werden oft nur als PDF exportiert oder gar nicht. In diesem Fall rekonstruieren Sie die Guthaben aus Ihren eigenen Unterlagen (Rechnungen, die Sie ausgestellt haben, Zahlungen, die Sie erhalten haben, die aktuelle Guthabenansicht des Panels als datierter Screenshot) und vereinbaren bei der Umstellung mit jedem Kunden schriftlich den Anfangssaldo. Das ist eine einzeilige E-Mail pro Kunde, und sie verhindert jeden Streit, den Sie sonst hätten.

Phase 3: die neue Plattform unter Ihrer eigenen Domain aufsetzen

Installieren Sie die Plattform auf Ihrem eigenen Server, unter Ihrer eigenen Domain, bevor auch nur ein Kunde umzieht. Zwei Regeln aus dem Vergleichsleitfaden gelten ab diesem Tag: Panel und API liegen unter Hostnamen, die Ihnen gehören (panel.ihrefirma.de, api.ihrefirma.de), und Absenderkennungen und regulatorische Identitäten werden auf Ihre Gesellschaft registriert, wo immer der Regulierer es zulässt. Dann:

1. Binden Sie Ihre eigenen Netzbetreiberverträge an als Lieferantenrouten und testen Sie jede mit echten Endgeräten in jedem Zielland, bevor irgendein Kundenverkehr sie berührt.
2. Bauen Sie die Preispläne neu auf aus dem Export, pro Ziel und pro Kundenstufe, und legen Sie unter jede Zeile eine Margenuntergrenze (der Leitfaden zur Abrechnung erklärt die drei Abrechnungsmodelle und warum das Modell bei der Kontoanlage gewählt und danach festgeschrieben wird; entscheiden Sie es also jetzt).
3. Legen Sie die Kundenkonten an mit dem richtigen Abrechnungsmodus, Preisplan, den Absenderkennungen und Kontakten, aber mit deaktiviertem Versand und einem Guthaben von null bis zur Umstellung.
4. Importieren Sie Kontakte, Einwilligungsnachweise und Vorlagen. Einen Business-Tipp geben wir jedem Käufer: Importieren Sie die Opt-in-Nachweise zusammen mit den Kontakten, dann sind Sie ab dem ersten Tag konform, statt Einwilligungen später neu aufzubauen.
5. Importieren Sie die Historie, wenn Sie können. Kampagnenhistorie und Zustellprotokolle mitzunehmen lohnt sich, damit Kunden ihre Berichte behalten; bei Smppcube ist das der Unterschied zwischen der Option „Standard-Import“ (Kontakte, Vorlagen, Absender- und Routenkonfiguration) und der Option „Vollständige Migration“ (alles plus Sendeverlauf, Kampagnen und Abrechnungsdaten) auf der Preisseite.
6. Richten Sie den SMPP-Server ein für die Kunden, die sich per Bind verbinden, mit Zugangsdaten pro Konto, Durchsatzobergrenzen und IP-Allowlists, bereit zur Übergabe; bei Smppcube sind SMPP-Server und HTTP-API Teil der Plattform und kein Zusatzmodul.

Phase 4: die Punkte, die nicht mitwandern

Vier Dinge brauchen einen eigenen Plan, weil kein Export sie mitnimmt.

Der API-Hostname. Wenn Ihre Kunden api.anbieter.com aufrufen, muss sich entweder ihr Code ändern, oder etwas muss unter derselben Schnittstelle antworten. Die bessere Option ist eine Kompatibilitätsschicht auf Ihrer Plattform, die die alte Anfrageform annimmt und auf die neue API abbildet, sodass die Integration eines Kunden an dem Tag weiterfunktioniert, an dem sein Verkehr umzieht; auf Ihre native API kann er dann in seinem eigenen Tempo wechseln. Gehört der alte Hostname dem Anbieter, können Sie ihn nicht mitnehmen. Dann läuft die Kompatibilitätsschicht unter Ihrem Hostnamen, und jeder Kunde ändert eine Zeile: den Host.

Webhooks. Kunden, die Zustellberichte per Webhook empfangen, haben das im alten Panel konfiguriert. Sammeln Sie jetzt die Empfangs-URL jedes Kunden und hinterlegen Sie sie vor der Umstellung auf der neuen Plattform, damit die erste Nachricht, die er über Sie sendet, einen Zustellbericht dort erzeugt, wo er ihn erwartet.

Absenderkennungen, Kurzwahlnummern, regulatorische Identitäten. Registrieren Sie sie neu auf Ihre Gesellschaft, pro Netzbetreiber, pro Land. Wo der Anbieter sie hält und nicht freigibt, kann sich die Absenderkennung des Kunden ändern. Darüber sollten Sie früh und ehrlich sprechen, mit dem Datum, ab dem seine Nachrichten die neue tragen.

SMPP-Binds. Jeder Kunde mit Bind braucht neuen Host, Port, system_id, Passwort, erlaubte IPs und Durchsatzobergrenze sowie ein Testfenster auf Ihrer Testroute, bevor sein Live-Verkehr umzieht. Schicken Sie das Zugangsdatenpaket in einem einzigen Dokument und vereinbaren Sie einen 30-minütigen Test mit seinem Techniker.

Eine Migration scheitert an den Punkten, die niemand exportiert hat, nicht an denen, die alle exportiert haben. Hostnamen, Webhooks, Absenderkennungen und Binds sind der Plan; die CSV-Dateien sind der einfache Teil.

Phase 5: der Parallelbetrieb

Halten Sie das alte Panel ab dem Moment, in dem die neue Plattform bereit ist, noch 60 bis 90 Tage lang live und bezahlt. Ziehen Sie zuerst einen wohlwollenden Kunden mit geringem Volumen um, am besten einen, der Ihnen die Wahrheit sagt. Sein Verkehr läuft über Ihre Plattform, Ihre Routen, Ihr Kontobuch; das alte Panel bleibt als Rückfallebene bestehen. Gleichen Sie täglich ab: gesendete Nachrichten, zugeordnete Zustellberichte und Guthabenbewegungen, jeweils gegen das, was der Kunde sieht. Wenn eine Woche ohne Erklärungsbedarf vergangen ist, ziehen Sie den nächsten Kunden um, und dann den nächsten. Ziehen Sie den größten Kunden zuletzt um, wenn die kleinen jedes langweilige Problem gefunden haben.

Während des Parallelbetriebs gehören drei Prüfungen auf eine tägliche Liste: die Latenz der Zustellberichte pro Route (ein Netzbetreiber-Bind, der auf Ihrer Plattform langsamer ist als im Panel, liegt meist an einer Fenster- oder Drosselungseinstellung), die Marge pro Kunde gegenüber dem Mischpreis des alten Panels (hier sehen Sie die Margenabgabe verschwinden) und die Support-Tickets nach Kategorie (eine Häufung von „wo ist mein Zustellbericht“ deutet auf einen Webhook hin, nicht auf eine Route).

Phase 6: Umstellung, Kunde für Kunde

Für jeden Kunden ist die Umstellung eine datierte Checkliste: Guthaben schriftlich vereinbart, Absenderkennungen live auf Ihre Gesellschaft, Integration getestet (API-Kompatibilitätsschicht oder neue Zugangsdaten, Webhook empfängt Zustellberichte, SMPP-Bind auf der Testroute geprüft), Versand aktiviert, erste Kampagne von Anfang bis Ende beobachtet, Konto im alten Panel auf reinen Empfang gestellt oder deaktiviert. Erledigen Sie das an einem Dienstagvormittag, wenn die Ansprechperson des Kunden erreichbar ist, niemals an einem Freitag.

Kommunikation ist der größte Teil der Arbeit. Eine kurze Nachricht an jeden Kunden einen Monat vorher („wir ziehen auf unsere eigene Plattform um, das ändert sich für Sie, das bleibt gleich“), eine Erinnerung eine Woche vorher mit seinem konkreten Datum und eine Bestätigung am Tag selbst. Kunden gehen wegen Überraschungen, nicht wegen Veränderungen.

Phase 7: das alte Panel ordentlich abschalten

Wenn der letzte Kunde umgezogen ist und der Parallelbetrieb einen Monat lang ruhig war: Ziehen Sie einen letzten Export von allem und bewahren Sie ihn mit Datum in Ihrem Archiv auf, widerrufen Sie jeden API-Schlüssel und jede Integration, die das Panel innehatte, entfernen Sie die IPs des Panels aus den Allowlists Ihrer Netzbetreiber, kündigen Sie gemäß Vertrag und lassen Sie sich schriftlich bestätigen, dass Ihre Daten aus den Systemen des Anbieters gelöscht wurden. Dann schließen Sie das Konto. Hier endet die doppelte Zahlung, und von nun an ist die Plattformgebühr, die mit Ihrem Verkehr gewachsen ist, jeden Monat Marge in Ihrem eigenen Kontobuch.

Was es kostet und was es wert ist

Budgetieren Sie die Migration ehrlich: zwei bis sechs Wochen Kalenderzeit, die meiste davon im Warten auf Netzbetreiber, plus 60 bis 90 Tage doppelte Zahlung, plus das, was die neue Plattform für den Import berechnet. Bei den Volumina, bei denen sich der Abschied lohnt, ist diese Summe kleiner als ein oder zwei Monate der Plattformgebühr pro Nachricht, die Sie hinter sich lassen, und anders als diese Gebühr zahlen Sie sie nur einmal. Bei Smppcube ist die Migration von Nutzern, Routen, Preislisten und Guthaben ein fest umrissener, standardmäßiger Teil des Deployments, und die Optionen „Standard-Import“ und „Vollständige Migration“ sind auf der Preisseite ausgewiesen, statt als Überraschung nachträglich kalkuliert zu werden. Welche Plattform Sie auch wählen, die Regeln, die den Ausstieg billig machen, sind dieselben zwei, die Sie schon am ersten Tag hätten anwenden sollen: Ihre Domain, Ihre Registrierungen.