Migrare un pannello SMS da SaaS a self-hosted, passo per passo

Lasciare un pannello SMS in affitto è un progetto dalla forma nota. Le parti che vanno storte sono sempre le stesse: un sender ID registrato a nome del fornitore, un hostname dell’API che i Suoi clienti hanno scritto nel codice, una contabilità che non si esporta, un passaggio fatto di venerdì. Questa è la checklist di migrazione del pannello SMS che usiamo quando spostiamo un rivenditore sulla sua piattaforma, scritta in modo che Lei possa seguirla con qualsiasi piattaforma self-hosted. Copre il passaggio da un pannello SaaS al self-hosted in sette fasi: inventario, esportazioni, la nuova piattaforma, le voci che non viaggiano, la convivenza in parallelo, il passaggio e la chiusura del vecchio pannello. Il confronto con i pannelli SaaS affronta la questione se andarsene; questa guida spiega come.

Fase 0: il calendario lo decide la voce più lenta

Prima di toccare i dati, elenchi le cose che girano sull’orologio di qualcun altro. Le nuove registrazioni di sender ID e numeri brevi a nome della Sua società, le identità regolatorie (DLT in India, 10DLC negli Stati Uniti e i loro equivalenti), le approvazioni degli operatori per i Suoi bind SMPP e, se aggiunge WhatsApp, la verifica aziendale di Meta. Ognuna richiede settimane, non giorni, e nessuna si può avviare troppo presto. Le avvii tutte nella prima settimana, in parallelo con tutto ciò che segue, e sarà il resto della migrazione, una volta concluso, ad aspettare loro, e non il contrario.

Fase 1: l’inventario per la migrazione del pannello SMS

Annoti, dalla console di amministrazione del pannello, una riga per ogni voce:

• Clienti: ogni account, il suo modello di fatturazione (credito prepagato, wallet, postpagato), il saldo attuale, il piano tariffario, la persona di riferimento e se si integra tramite console, API HTTP o bind SMPP.
• Piani tariffari e rotte: ogni piano di prezzo, ogni riga di destinazione, ogni rotta di fornitore con le sue credenziali e il suo costo.
• Sender ID e numeri: ID alfanumerici, numeri lunghi, numeri brevi, e a nome di quale società ciascuno è registrato presso ciascun operatore.
• Integrazioni: ogni hostname che i Suoi clienti chiamano (API, URL del pannello, endpoint webhook su cui ricevono le ricevute) e se si trova sul Suo dominio o su quello del fornitore.
• Volumi di dati: contatti, modelli, storico delle campagne, log di consegna, fatture, mese per mese.
• Contratti: il periodo di preavviso del pannello e ogni contratto cliente che menziona il nome o l’URL del pannello.

Questo inventario è il piano di migrazione. Tutto ciò che segue è l’inventario con le date accanto.

Fase 2: ottenga esportazioni vere finché è ancora cliente

Chieda le esportazioni adesso, prima di dare disdetta, perché la risposta è più cordiale finché sta pagando. Chieda ogni voce dell’inventario in un formato leggibile da una macchina (il CSV va bene) e apra ogni file: confronti il numero di righe con la console, verifichi che i registri di consenso viaggino insieme ai contatti, controlli che i log di consegna riportino l’ID del messaggio e lo stato finale, e non solo un conteggio. “Supportiamo l’esportazione CSV” e “il file contiene ciò di cui i miei clienti avrebbero bisogno” sono frasi diverse.

Si aspetti che la contabilità sia la cosa meno portabile dell’edificio: saldi e storico delle fatture spesso si esportano in PDF, oppure non si esportano affatto. In quel caso ricostruisca i saldi dai Suoi registri (le fatture che ha emesso, i pagamenti che ha ricevuto, la schermata del saldo attuale del pannello in uno screenshot datato) e, al momento del passaggio, concordi per iscritto il saldo di apertura con ciascun cliente. È un’e-mail di una riga per cliente, e previene ogni contestazione che altrimenti dovrebbe affrontare.

Fase 3: avvii la nuova piattaforma sul Suo dominio

Installi la piattaforma sul Suo server, sul Suo dominio, prima che qualsiasi cliente si sposti. Da questo giorno in avanti valgono due regole della guida di confronto: il pannello e l’API vivono su hostname di Sua proprietà (pannello.suaazienda.com, api.suaazienda.com), e i sender ID e le identità regolatorie sono registrati a nome della Sua società ovunque il regolatore lo consenta. Poi:

1. Colleghi i Suoi contratti con gli operatori come rotte di fornitore, e provi ciascuna con telefoni reali in ogni destinazione prima che vi passi il traffico di qualsiasi cliente.
2. Ricostruisca i piani tariffari a partire dall’esportazione, per destinazione e per fascia di clientela, e metta un pavimento di margine sotto ogni riga (la guida alla fatturazione spiega i tre modelli di fatturazione e perché il modello si sceglie alla creazione dell’account e poi resta bloccato, quindi lo decida adesso).
3. Crei gli account cliente con il modello di fatturazione, il piano tariffario, i sender ID e i contatti corretti, ma con l’invio disattivato e i saldi a zero fino al passaggio.
4. Importi contatti, registri di consenso e modelli. Un consiglio pratico che diamo a ogni acquirente: importi le prove di opt-in insieme ai contatti, così è conforme dal primo giorno invece di dover ricostruire i consensi in seguito.
5. Importi lo storico, se può. Lo storico delle campagne e i log di consegna meritano di essere trasferiti, così i clienti conservano i loro report; su Smppcube è la differenza tra l’Import standard (contatti, modelli, configurazione di mittenti e rotte) e la Migrazione completa (tutto questo più storico degli invii, campagne e registri di fatturazione) indicati nella pagina dei prezzi.
6. Configuri il server SMPP per i clienti che si collegano in bind, con credenziali per account, limiti di throughput e allowlist di IP pronti da consegnare; su Smppcube il server SMPP e l’API HTTP fanno parte della piattaforma, non sono un componente aggiuntivo.

Fase 4: le voci che non viaggiano

Quattro cose richiedono un piano a sé, perché nessuna esportazione le trasporta.

L’hostname dell’API. Se i Suoi clienti chiamano api.fornitore.com, il loro codice deve cambiare, oppure qualcosa deve rispondere con la stessa interfaccia. L’opzione migliore è uno strato di compatibilità sulla Sua piattaforma che accetti la vecchia forma delle richieste e la converta verso la nuova API, così l’integrazione di un cliente continua a funzionare il giorno in cui il suo traffico si sposta; il cliente potrà poi passare alla Sua API nativa con i propri tempi. Se il vecchio hostname appartiene al fornitore, non può portarlo con sé, quindi lo strato di compatibilità vive sul Suo hostname e ogni cliente cambia una sola riga: l’host.

I webhook. I clienti che ricevono le ricevute di consegna tramite webhook lo hanno configurato sul vecchio pannello. Raccolga adesso l’URL di ricezione di ogni cliente e lo configuri sulla nuova piattaforma prima del passaggio, così il primo messaggio che inviano attraverso di Lei produce una ricevuta nel punto in cui se l’aspettano.

Sender ID, numeri brevi, identità regolatorie. Li registri di nuovo a nome della Sua società, per operatore e per Paese. Dove il fornitore li detiene e non intende rilasciarli, il sender ID del cliente potrebbe cambiare: è una conversazione da affrontare presto e con onestà, indicando la data dalla quale i suoi messaggi porteranno quello nuovo.

I bind SMPP. Ogni cliente che si collega in bind ha bisogno di nuovi host, porta, system_id, password, IP consentiti e limite di throughput, oltre a una finestra di prova sulla Sua rotta di test prima che il suo traffico reale si sposti. Invii il pacchetto delle credenziali in un unico documento e fissi un test di 30 minuti con il suo tecnico.

La migrazione fallisce sulle voci che nessuno ha esportato, non su quelle che tutti hanno esportato. Hostname, webhook, sender ID e bind sono il piano; i file CSV sono la parte facile.

Fase 5: la convivenza in parallelo

Tenga il vecchio pannello attivo e pagato per un periodo da 60 a 90 giorni dopo che la nuova piattaforma è pronta. Sposti per primo un cliente amichevole e a basso volume, possibilmente uno che Le dica la verità. Il suo traffico gira sulla Sua piattaforma, sulle Sue rotte, sul Suo registro; il vecchio pannello resta come riserva. Riconcili ogni giorno: messaggi inviati, ricevute abbinate, movimenti del saldo, confrontati con ciò che vede il cliente. Quando passa una settimana senza nulla da spiegare, sposti il cliente successivo, e poi quello dopo ancora. Sposti per ultimo il cliente più grande, quando ogni problema noioso è già stato trovato da quelli piccoli.

Durante la convivenza, tre controlli vanno in una lista quotidiana: la latenza delle ricevute per rotta (un bind con un operatore più lento sulla Sua piattaforma che sul pannello dipende di solito da un’impostazione della finestra o del throttling), il margine per cliente rispetto al prezzo complessivo del vecchio pannello (è qui che vede sparire la tassa sul margine) e i ticket di assistenza per categoria (un picco di “dov’è la mia ricevuta” indica un webhook, non una rotta).

Fase 6: il passaggio, cliente per cliente

Per ogni cliente, il passaggio è una checklist con una data: saldo concordato per iscritto, sender ID attivi a nome della Sua società, integrazione provata (strato di compatibilità dell’API o nuove credenziali, webhook che riceve le ricevute, bind SMPP provato sulla rotta di test), invio attivato, prima campagna seguita dall’inizio alla fine, account sul vecchio pannello impostato in sola ricezione o disattivato. Lo faccia di martedì mattina, con la persona di riferimento del cliente raggiungibile, mai di venerdì.

La comunicazione è la parte più grossa del lavoro. Una breve nota a ogni cliente un mese prima (“passiamo alla nostra piattaforma, ecco cosa cambia per Lei, ecco cosa resta uguale”), un promemoria una settimana prima con la sua data specifica e una conferma il giorno stesso. I clienti se ne vanno per le sorprese, non per i cambiamenti.

Fase 7: chiuda il vecchio pannello nel modo giusto

Quando l’ultimo cliente si è spostato e la convivenza è rimasta tranquilla per un mese: faccia un’ultima esportazione completa, la conservi nel Suo archivio con la data, revochi ogni chiave API e integrazione che il pannello deteneva, rimuova gli IP del pannello dalle allowlist dei Suoi operatori, dia disdetta secondo il contratto e si faccia confermare per iscritto che i Suoi dati sono stati cancellati dai loro sistemi. Poi chiuda l’account. Il doppio pagamento finisce qui, e da questo momento in poi, ogni mese, la tariffa di piattaforma che cresceva con il Suo traffico diventa margine sul Suo registro.

Quanto costa, e quanto vale

Metta a budget la migrazione con onestà: da due a sei settimane di calendario, per lo più in attesa degli operatori, più da 60 a 90 giorni di doppio pagamento, più quanto la nuova piattaforma chiede per l’importazione. Ai volumi in cui andarsene ha senso, quel totale è inferiore a uno o due mesi della tariffa di piattaforma per messaggio che si lascia alle spalle e, a differenza di quella tariffa, si paga una volta sola. Su Smppcube, la migrazione di utenti, rotte, listini e saldi è una parte standard e definita del deployment, e le opzioni Import standard e Migrazione completa hanno un prezzo indicato sulla pagina dei prezzi invece di essere quotate a sorpresa. Qualunque piattaforma scelga, le regole che rendono l’uscita economica sono le stesse due che avrebbe dovuto applicare il primo giorno: il Suo dominio, le Sue registrazioni.