Migração de painel SMS: do SaaS para o self-hosted, passo a passo

Deixar um painel SMS alugado é um projeto de formato conhecido. As partes que dão errado são sempre as mesmas: um ID de remetente registrado em nome do fornecedor, um hostname de API que os seus clientes fixaram no código, um livro-razão que não pode ser exportado, uma virada feita em uma sexta-feira. Esta é a lista de verificação de migração de painel SMS que usamos quando transferimos um revendedor para a própria plataforma, escrita para que você possa aplicá-la com qualquer plataforma self-hosted. Ela cobre a mudança de um painel SaaS para uma solução self-hosted em sete etapas: inventário, exportações, a nova plataforma, os itens que não são transferidos, a operação em paralelo, a virada e o desligamento do painel antigo. A comparação com painéis SaaS trata da decisão de sair; este guia trata de como sair.

Etapa 0: defina o cronograma pelo item mais lento

Antes de mexer nos dados, liste tudo o que depende do prazo de terceiros. Os novos registros de IDs de remetente e de short codes em nome da sua própria empresa, as identidades regulatórias (DLT na Índia, 10DLC nos Estados Unidos e os equivalentes em outros países), as aprovações das operadoras para os seus próprios binds SMPP e, se você incluir o WhatsApp, a verificação da empresa pela Meta. Cada um leva semanas, não dias, e nenhum pode ser iniciado cedo demais. Inicie todos na primeira semana, em paralelo com tudo o que vem a seguir, e o restante da migração terminará esperando por eles, e não o contrário.

Etapa 1: o inventário da migração do painel SMS

Anote, a partir do console de administração do painel, uma linha por item:

• Clientes: cada conta, o modelo de cobrança (crédito pré-pago, carteira, pós-pago), o saldo atual, o plano de tarifas, a pessoa de contato e se a integração é feita pelo console, pela API HTTP ou por bind SMPP.
• Planos de tarifas e rotas: cada plano de preços, cada linha de destino, cada rota de fornecedor com as respectivas credenciais e o custo.
• IDs de remetente e números: IDs alfanuméricos, números longos, short codes e em nome de qual empresa cada um está registrado em cada operadora.
• Integrações: cada hostname que os seus clientes chamam (API, URL do painel, endpoints de webhook em que recebem as confirmações de entrega) e se ele está no seu domínio ou no do fornecedor.
• Volumes de dados: contatos, modelos de mensagem, histórico de campanhas, logs de entrega e faturas, por mês.
• Contratos: o prazo de aviso prévio do painel e cada contrato de cliente que mencione o nome ou a URL do painel.

Esse inventário é o plano de migração. Tudo o que vem a seguir é o mesmo inventário, com datas.

Etapa 2: obtenha exportações reais enquanto você ainda é cliente

Peça as exportações agora, antes de dar o aviso prévio, porque a resposta é mais cordial enquanto você está pagando. Solicite cada item do inventário em um formato legível por máquina (CSV serve) e abra cada arquivo: compare a quantidade de linhas com o console, verifique se os registros de consentimento acompanham os contatos e confira se os logs de entrega trazem o ID da mensagem e o status final, e não apenas uma contagem. “Oferecemos exportação em CSV” e “o arquivo contém o que os meus clientes precisariam” são frases diferentes.

Conte com o livro-razão como o item menos portável de todos: os saldos e o histórico de faturas muitas vezes são exportados em PDF ou simplesmente não são exportados. Nesse caso, reconstrua os saldos a partir dos seus próprios registros (as faturas que você emitiu, os pagamentos que recebeu e a tela de saldo atual do painel em uma captura de tela datada) e acerte o saldo inicial com cada cliente, por escrito, na virada. Isso significa um e-mail de uma linha por cliente e evita todas as disputas que você teria de outra forma.

Etapa 3: coloque a nova plataforma no ar no seu próprio domínio

Instale a plataforma no seu próprio servidor, no seu próprio domínio, antes que qualquer cliente seja transferido. Duas regras do guia comparativo valem a partir deste dia: o painel e a API ficam em hostnames que são seus (painel.suaempresa.com, api.suaempresa.com), e os IDs de remetente e as identidades regulatórias são registrados em nome da sua empresa sempre que o órgão regulador permitir. Em seguida:

1. Conecte os seus próprios contratos com operadoras como rotas de fornecedor e teste cada uma com aparelhos reais em cada destino antes que qualquer tráfego de cliente passe por ela.
2. Reconstrua os planos de tarifas a partir da exportação, por destino e por nível de cliente, e defina um piso de margem em cada linha (o guia de faturamento explica os três modelos de cobrança e por que o modelo é escolhido na criação da conta e fica bloqueado depois, então decida isso agora).
3. Crie as contas dos clientes com o modelo de cobrança, o plano de tarifas, os IDs de remetente e os contatos corretos, mas com o envio desativado e os saldos zerados até a virada.
4. Importe contatos, registros de consentimento e modelos de mensagem. Uma dica de negócio que damos a todo comprador: importe os registros de opt-in junto com os contatos, para estar em conformidade desde o primeiro dia, em vez de reconstruir o consentimento mais tarde.
5. Importe o histórico, se possível. Vale a pena transferir o histórico de campanhas e os logs de entrega para que os clientes mantenham os seus relatórios; no Smppcube, essa é a diferença entre a Importação padrão (contatos, modelos de mensagem e configuração de remetentes e rotas) e a Migração completa (tudo isso, mais o histórico de envios, as campanhas e os registros de faturamento) na página de preços.
6. Configure o servidor SMPP para os clientes que usam bind, com credenciais por conta, limites de vazão e listas de IPs permitidos prontos para entregar; no Smppcube, o servidor SMPP e a API HTTP fazem parte da plataforma, e não são um complemento.

Etapa 4: os itens que não são transferidos

Quatro itens precisam de um plano próprio, porque nenhuma exportação os inclui.

O hostname da API. Se os seus clientes chamam api.fornecedor.com, o código deles precisa mudar, ou algo precisa responder na mesma interface. A melhor opção é uma camada de compatibilidade na sua plataforma que aceite o formato de requisição antigo e o converta para a nova API, para que a integração do cliente continue funcionando no dia em que o tráfego dele for transferido; depois, ele pode migrar para a sua API nativa no próprio ritmo. Se o hostname antigo pertence ao fornecedor, você não pode levá-lo, então a camada de compatibilidade fica no seu hostname e cada cliente altera uma única linha: o host.

Webhooks. Os clientes que recebem confirmações de entrega por webhook configuraram isso no painel antigo. Colete agora a URL de recebimento de cada cliente e configure-a na nova plataforma antes da virada, para que a primeira mensagem que ele enviar por você gere uma confirmação no lugar esperado.

IDs de remetente, short codes e identidades regulatórias. Registre tudo novamente em nome da sua empresa, por operadora e por país. Quando o fornecedor detém esses registros e não os libera, o ID de remetente do cliente pode mudar, e essa é uma conversa a ter cedo e com honestidade, informando a data a partir da qual as mensagens dele passarão a exibir o novo ID.

Binds SMPP. Cada cliente que usa bind precisa de host, porta, system_id, senha, IPs permitidos e limite de vazão novos, além de uma janela de testes na sua rota de teste antes que o tráfego real dele seja transferido. Envie o pacote de credenciais em um único documento e agende um teste de 30 minutos com o engenheiro do cliente.

A migração falha nos itens que ninguém exportou, não nos que todos exportaram. Hostnames, webhooks, IDs de remetente e binds são o plano; os arquivos CSV são a parte fácil.

Etapa 5: a operação em paralelo

Mantenha o painel antigo ativo e pago por 60 a 90 dias depois que a nova plataforma estiver pronta. Transfira primeiro um cliente de confiança e de baixo volume, de preferência um que diga a verdade a você. O tráfego dele passa pela sua plataforma, pelas suas rotas e pelo seu livro-razão; o painel antigo fica como alternativa de segurança. Concilie diariamente as mensagens enviadas, as confirmações associadas e as movimentações de saldo com o que o cliente vê. Quando uma semana passar sem nada a explicar, transfira o próximo cliente, e depois o seguinte. Transfira o maior cliente por último, quando todos os problemas rotineiros já tiverem sido encontrados pelos clientes menores.

Durante a operação em paralelo, três verificações entram na lista diária: a latência das confirmações por rota (um bind com uma operadora que fica mais lento na sua plataforma do que no painel normalmente indica uma configuração de janela ou de limitação de vazão), a margem por cliente em comparação com o preço médio do painel antigo (é aqui que você vê a taxa sobre a margem desaparecer) e os chamados de suporte por categoria (um aumento de “onde está a minha confirmação” aponta para um webhook, não para uma rota).

Etapa 6: a virada, cliente por cliente

Para cada cliente, a virada é uma lista de verificação com data: saldo acordado por escrito, IDs de remetente ativos em nome da sua empresa, integração testada (camada de compatibilidade da API ou novas credenciais, webhook recebendo confirmações, bind SMPP testado na rota de teste), envio ativado, primeira campanha acompanhada do início ao fim e conta no painel antigo configurada apenas para recebimento ou desativada. Faça isso em uma terça-feira de manhã, com o contato do cliente disponível, nunca em uma sexta-feira.

A comunicação é a maior parte do trabalho. Um aviso curto a cada cliente com um mês de antecedência (“estamos migrando para a nossa própria plataforma; veja o que muda para você e o que não muda”), um lembrete uma semana antes com a data específica dele e uma confirmação no próprio dia. Os clientes vão embora por causa de surpresas, não por causa de mudanças.

Etapa 7: desative o painel antigo da forma correta

Quando o último cliente tiver sido transferido e a operação em paralelo tiver passado um mês sem ocorrências: faça uma exportação final de tudo, guarde-a no seu arquivo com a data, revogue todas as chaves de API e integrações que o painel tinha, remova os IPs do painel das listas de IPs permitidos das suas operadoras, dê o aviso prévio conforme o contrato e obtenha a confirmação por escrito de que os seus dados foram excluídos dos sistemas do fornecedor. Depois, encerre a conta. O pagamento em dobro termina aqui e, a partir de agora, todos os meses, a taxa de plataforma que crescia com o seu tráfego passa a ser margem no seu próprio livro-razão.

Quanto custa e quanto vale

Planeje os custos da migração com honestidade: de duas a seis semanas de prazo corrido, a maior parte esperando pelas operadoras, mais 60 a 90 dias pagando em dobro, mais o valor que a nova plataforma cobrar pela importação. Nos volumes em que sair faz sentido, esse total é menor do que um ou dois meses da taxa de plataforma por mensagem que você está deixando para trás e, ao contrário dessa taxa, é pago uma única vez. No Smppcube, a migração de usuários, rotas, tabelas de preços e saldos é uma etapa padrão, com escopo definido, da implantação, e as opções de Importação padrão e Migração completa têm preço publicado na página de preços, em vez de serem orçadas de surpresa. Seja qual for a plataforma escolhida, as regras que tornam a saída barata são as mesmas duas que você deveria ter aplicado no primeiro dia: o seu domínio, os seus registros.