Os 7 Rs em uma frase cada
A taxonomia vem da documentação de estratégias de migração da AWS, e a Microsoft e o Google usam classificações quase idênticas. Rehost: mover a aplicação como está para uma máquina virtual na nuvem. Replatform: mover com ajustes pontuais, como trocar o banco por um serviço gerenciado. Refactor ou re-architect: mudar a arquitetura da aplicação para aproveitar a nuvem. Repurchase: trocar por um produto pronto, em geral SaaS. Retire: desligar o que ninguém usa mais. Retain: manter onde está, por decisão. Relocate: mover a camada de virtualização inteira sem tocar nas aplicações.
Vale fixar o vocabulário em português uma vez e usar os termos em inglês depois, porque é assim que o leitor vai encontrá-los no material dos provedores e nas propostas. E vale notar o que a lista diz nas entrelinhas: duas das sete estratégias — retire e retain — não migram nada. Isso é intencional.
Qual R serve para cada sistema que uma PME realmente tem
PHP em cPanel ou servidor dedicado: rehost para uma máquina virtual, ou replatform para PHP gerenciado com banco gerenciado. A atualização de versão do PHP é uma decisão separada da migração, e o artigo sobre a falha PHP2Shell explica por que ela não pode mais esperar. Java em Tomcat num dedicado: rehost, como na migração que a JBKR fez para a Jelastic — sem reescrita, com o custo do servidor dedicado eliminado e quatro projetos seguidos avaliados em 5/5 pelo cliente. .NET Framework preso ao Windows: rehost para uma VM Windows primeiro, replatform para .NET atual depois, módulo a módulo.
Delphi de balcão com banco local: quase sempre retain do cliente desktop, com relocate ou rehost do banco e da camada de integração — o padrão do caso Legate, em que a integração mudou e o desktop ficou. E há os casos honestos de repurchase e retire: e-mail, folha de pagamento e agenda raramente justificam sistema próprio; e todo sistema antigo tem um módulo que ninguém abre há três anos e que pode simplesmente ser desligado.
Rehost não é "só copiar": o que muda mesmo
A lista do que quebra numa migração "simples" é previsível e sempre surpreende: endereços IP fixos em integrações de terceiros, DNS, certificados, tarefas agendadas, caminhos de arquivo, servidor de e-mail de saída, fuso horário do servidor e listas de permissão de parceiros que apontam para o IP antigo. Nenhum item é difícil; o problema é descobri-los em produção.
Por isso o método é o mesmo de qualquer virada: inventário do ambiente, ambiente de testes na nuvem, equivalência funcional validada e virada controlada com plano de retorno, como a página de cloud da JBKR descreve. A parte que merece mais ensaio é a migração dos dados: ela pode ser repetida em cópia quantas vezes for preciso, e deve ser. E o backup, que no servidor dedicado era uma esperança, passa a ser uma configuração — o artigo sobre backup e ransomware trata de como testá-lo.
Custos que aparecem depois da migração
A fatura de nuvem surpreende por itens que a proposta não mostra: tráfego de saída de dados, instâncias ociosas que ninguém desligou, bancos superdimensionados, snapshots que se acumulam, níveis de suporte e cobrança por requisição em serviços gerenciados. Nenhum deles é escondido — todos estão nas páginas de preço dos provedores — mas nenhum aparece quando se compara "servidor dedicado por mês" com "máquina virtual por mês".
A regra que evita o susto: alerta de orçamento e revisão mensal desde o primeiro dia, dimensionamento pela carga real e não pela apresentação de vendas, e desligar o que não é usado. Há ainda um custo que não aparece em fatura: dependência do provedor. Replatform e refactor amarram a aplicação a serviços específicos; rehost preserva a porta de saída. Isso é um argumento a favor de começar pelo rehost, não contra a nuvem.
Quando não migrar (retain) é a resposta certa
Sistema estável, sem crescimento previsto, com exigência de ficar na empresa (ambiente industrial, requisito regulatório, latência para equipamento local) ou com uma equipe que não tem familiaridade com nuvem e não terá contrato de sustentação. Nesses casos, um servidor dedicado com backup testado, monitoramento e versão atualizada não é um problema a resolver. Uma versão sem suporte, por outro lado, é — e isso vale dentro ou fora da nuvem, como o artigo sobre manter ou modernizar detalha.
Migração não corrige código. "Levar o problema para a nuvem" é o resultado mais comum de uma migração feita sem diagnóstico: o mesmo sistema, com os mesmos defeitos, agora numa fatura mensal diferente. Se a motivação é um defeito do sistema, a resposta está nos caminhos de modernização, não na mudança de endereço.
Refactor e o padrão Strangler Fig, só quando houver motivo
Refactor é a estratégia mais cara e mais arriscada, e por isso deve ser reservada ao módulo que de fato trava o crescimento — o faturamento, uma integração, o cadastro — e não ao sistema inteiro. O padrão de referência é o Strangler Fig descrito por Martin Fowler: módulos novos assumem rotas e funções uma de cada vez, enquanto o sistema antigo continua servindo o resto, até que o antigo possa ser desligado.
Os riscos dessa estratégia — regras implícitas, equivalência de dados, integrações não documentadas — estão detalhados no artigo sobre riscos de modernizar; as definições de cada caminho, no artigo sobre o que é modernização. O ponto aqui é só um: refactor é uma ferramenta de precisão, não o plano padrão.
Como a JBKR faz uma migração e próximo passo
Quatro passos, os mesmos da página de cloud e infraestrutura: inventário de servidores, sistemas e bancos; escolha da estratégia para cada peça (rehost, ajustes pontuais ou modernização); execução com ambiente de testes; e virada controlada com plano de retorno. O resultado por escrito diz qual R se aplica a cada componente e, tão importante quanto, quanto vai custar para rodar — não só para mover.
Na JBKR o diagnóstico inicial de 30 minutos é gratuito. A primeira pergunta não é "qual provedor", mas "o que você espera que melhore depois da migração" — porque se a resposta for "o sistema", a conversa certa é outra.
