Trocar a plataforma de um provedor que já tem clientes é diferente de montar uma operação nova. Você não está construindo: está movendo uma casa habitada. E existe uma armadilha específica nesse projeto que quase todo mundo descobre tarde: a migração técnica — mover VMs, DNS, dados — é a parte previsível. A parte que faz perder cliente é a migração da relação de cobrança, e ela raramente aparece no plano inicial.

São duas migrações, não uma

A migração técnica move a carga: máquinas virtuais, zonas de DNS, caixas de e-mail, backups, certificados, regras de firewall. É trabalhosa, tem risco conhecido e se resolve com método.

A migração comercial move a relação: cadastro, contrato, ciclo de faturamento, forma de pagamento, histórico de faturas, credenciais de acesso ao painel. É aqui que a perda acontece, e o motivo é um detalhe técnico com efeito comercial enorme.

O problema do meio de pagamento

Este é o ponto que decide quantos clientes você perde, então vale começar por ele.

Cobrança recorrente em cartão funciona por um identificador guardado no adquirente — o cartão em si não está no seu sistema. Esse identificador normalmente não é transferível entre adquirentes ou plataformas. Consequência: se você troca de gateway, os seus clientes precisam cadastrar o cartão de novo.

Pedir a centenas de clientes que reinsiram dado de pagamento é o momento de maior risco de todo o projeto. Cada cliente que não responde ao e-mail se torna inadimplente involuntário. Cada um que responde tem a oportunidade de reavaliar se quer continuar.

Formas de reduzir o dano, na ordem de preferência:

1. Verifique a portabilidade dos identificadores. Alguns adquirentes fazem migração de cofre entre si, sob solicitação e com requisitos. Se isso for possível no seu caso, é de longe a melhor saída — pergunte antes de assumir que não dá.
2. Mantenha o mesmo adquirente, trocando apenas a plataforma que o aciona. Muitas vezes o gateway não precisa mudar junto com o painel.
3. Ofereça Pix como caminho imediato no pedido de recadastramento. Reduz o atrito de quem não tem o cartão à mão naquele momento.
4. Faça em ondas, com prazo generoso, acompanhando individualmente quem não recadastrou. Uma ligação para um cliente maior custa menos que perdê-lo.
5. Nunca suspenda por falha de recadastramento sem contato humano prévio. Esse é o caso em que a suspensão automática destrói uma relação por um motivo puramente administrativo.

Inventário: o que você tem, por cliente

Nada se planeja sem inventário, e ele precisa ser por cliente, não agregado:

• Recursos técnicos: VMs com especificação, discos, IPs, snapshots, regras de firewall, certificados e onde estão as chaves.
• DNS: quais zonas você gerencia, onde estão os registradores, e o TTL atual de cada registro.
• Serviços auxiliares: e-mail, armazenamento de objetos, balanceadores, bancos gerenciados.
• Backups: o que existe, com qual retenção, e o que precisa ser preservado historicamente.
• Comercial: ciclo de faturamento, dia de vencimento, valor, forma de pagamento, descontos concedidos, contrato e prazo, saldo em aberto.
• Contatos: técnico e financeiro separados, porque o aviso de recadastramento vai para o financeiro e o de janela de manutenção vai para o técnico.
• Particularidades: aquele cliente com regra especial que só uma pessoa da equipe conhece. Todo provedor tem alguns, e eles são a fonte mais comum de surpresa.

Esse levantamento sempre revela recursos que não estão sendo cobrados e clientes com condições que ninguém lembrava. Corrigir isso é ganho colateral do projeto.

Ondas, nunca de uma vez

Migrar tudo num fim de semana é o desenho que produz as piores histórias. O caminho é por ondas, com aprendizado entre elas:

A onda 0 é a que mais economiza tempo e a que mais gente pula. Migrar o seu próprio ambiente primeiro revela os problemas do processo em um lugar onde eles não custam reputação.

O roteiro por cliente

Cada migração deve seguir a mesma sequência, com verificação em cada etapa:

1. Reduza o TTL do DNS com antecedência — dias antes, não horas. Sem isso, o redirecionamento demora e a janela se estende sem que você possa fazer nada.
2. Copie os dados para o destino com antecedência, deixando apenas o incremento final para a janela.
3. Suba no destino sem tráfego e valide: a aplicação responde, o banco está íntegro, os serviços iniciam na ordem certa.
4. Sincronize o incremento final com o serviço parado ou em modo somente leitura, conforme o caso.
5. Redirecione o tráfego.
6. Valide com o cliente, não só internamente. Ele conhece o comportamento normal do sistema dele.
7. Mantenha a origem intacta por alguns dias, desligada mas não apagada. É o seu caminho de volta.
8. Só então desative e libere os recursos antigos.

A etapa 7 é a que dá coragem para executar as anteriores. Migração sem caminho de volta transforma qualquer imprevisto em crise.

Comunicação: o que o cliente precisa ouvir

Migração mal comunicada é percebida como instabilidade do provedor, mesmo quando tecnicamente impecável. O que funciona:

• Avise cedo, com o motivo em termos de benefício para ele: portal melhor, backup mais robusto, autoatendimento, dado em infraestrutura própria.
• Dê data e janela específicas, com estimativa honesta de indisponibilidade. Prometer zero parada e ter dez minutos é pior que prever trinta e usar dez.
• Explique o que ele precisa fazer, separando claramente o que é ação dele — recadastrar pagamento, atualizar uma configuração — do que é trabalho seu.
• Esteja disponível durante a janela, com canal direto. Cliente que não consegue falar com ninguém durante a migração dele lembra disso por anos.
• Confirme a conclusão com um resumo do que foi feito e do que mudou no acesso.
• Não migre em período crítico do cliente. Fechamento de mês, campanha de vendas, folha de pagamento. Perguntar antes evita o pior tipo de atrito.

O que quebra a confiança

Sendo explícito sobre os erros que custam cliente, mesmo com a parte técnica correta:

• Indisponibilidade não avisada, ou muito maior que a estimada.
• Perda de dado, ainda que pequena — um arquivo, uma configuração, o histórico de faturas.
• Pedido de recadastramento de pagamento sem contexto, que muitos clientes tratam como tentativa de golpe. E estão certos em desconfiar: aviso pedindo dado de cartão precisa ser inequivocamente legítimo, idealmente confirmado por outro canal.
• Suporte indisponível durante a janela.
• Fatura errada no primeiro ciclo após a migração. É frequente — rateio mal calculado, cobrança duplicada, desconto perdido — e ocorre justamente quando a confiança está mais frágil. Confira manualmente o primeiro faturamento de cada cliente migrado.
• Perda do histórico, quando o cliente precisa de faturas antigas e elas não existem mais.

Erros comuns

• Descobrir tarde que os identificadores de cartão não são transferíveis.
• Migrar toda a base em uma única janela.
• Não migrar o próprio ambiente primeiro.
• Não reduzir o TTL do DNS com antecedência.
• Apagar a origem imediatamente após a virada.
• Inventário agregado, sem detalhe por cliente.
• Contato financeiro e técnico não separados.
• Validar apenas internamente, sem o cliente.
• Migrar em período crítico do cliente.
• Suspender quem não recadastrou pagamento, sem contato humano.
• Não conferir a primeira fatura pós-migração.
• Perder o histórico de faturas.

Onde a Solvefy/Cloud entra

Conduzimos esse tipo de projeto com frequência, e é justamente o cenário do onboarding da plataforma E-CLOUD: levantamos o inventário por cliente, resolvemos a questão do meio de pagamento antes de qualquer coisa — porque é ela que define o risco comercial —, montamos o roteiro por cliente com caminho de volta e executamos em ondas, começando pelo seu ambiente interno. A parte técnica é a que sabemos fazer; a parte que mais protegemos é a relação com a sua base.

Quer migrar de plataforma sem perder clientes no caminho? Fazemos um diagnóstico gratuito, sem compromisso, em solvefy.cloud.

Solvefy/Cloud — Infraestrutura que cresce com você.