Replatforming: o que é e quando fazer

Replatforming é mover uma aplicação existente para uma nova plataforma, como um novo runtime, framework, banco de dados, ambiente de hospedagem ou sistema de e-commerce, mantendo as funcionalidades e a maior parte da lógica de negócio. Você troca a fundação, não o produto.

Ele fica entre um simples lift-and-shift e uma reescrita completa. Liderei uma migração assim na avanzzada, em uma plataforma que se candidata automaticamente a vagas de emprego para seus usuários. A principal lição: a mudança em si raramente é a parte difícil. Difícil é manter o produto funcionando enquanto você a faz.

O que significa replatforming?

A palavra é usada de duas formas um pouco diferentes, e ajuda saber qual delas a pessoa quer dizer.

Em trabalho de nuvem e infraestrutura, ela costuma vir das estratégias de migração popularizadas pelos provedores de nuvem (muitas vezes descrita como “lift, tinker and shift”). Você move um app para um novo ambiente e faz algumas mudanças pontuais para aproveitá-lo, por exemplo trocando um banco de dados autogerenciado por um gerenciado, sem redesenhar a aplicação.

Em e-commerce e produto, muitas vezes significa mudar para outra plataforma por completo: outro motor de e-commerce, CMS ou stack de aplicação. Os dados e a experiência do usuário são levados junto; o motor por baixo muda.

Os dois sentidos compartilham uma ideia: o produto continua reconhecivelmente o mesmo para os usuários, enquanto a fundação muda. Se os usuários percebem grandes mudanças de funcionalidade, você provavelmente está fazendo algo mais próximo de um redesign ou de uma reescrita.

Qual a diferença entre replatforming, rehosting e refatoração?

Esses termos são confundidos o tempo todo. Esta é a distinção prática que eu uso. É uma regra prática, não um padrão formal.

Rehosting costuma ser o mais barato e o mais rápido, mas não resolve uma stack que ninguém quer manter. A refatoração melhora o código, mas deixa você na mesma plataforma. O replatforming é o caminho do meio: você conserta a fundação sem jogar fora a lógica que já codifica anos de decisões de negócio.

Na prática, as fronteiras se misturam. Um replatforming quase sempre inclui alguma refatoração, porque código escrito para o framework antigo raramente encaixa no novo sem mudanças. A disciplina está em limitar essa refatoração ao que a mudança exige.

Quando o replatforming é a decisão certa para um app legado?

Faça replatforming quando o que está segurando você é a plataforma, não o produto. Sinais que eu procuro:

• Dependências em fim de vida. A versão da linguagem, o framework ou o banco de dados não recebem mais patches de segurança.
• Dificuldade de contratação. Poucos engenheiros querem trabalhar com a stack, e o onboarding demora muito mais por causa disso.
• Limites de escala ou de custo. A arquitetura não aguenta a carga sem gambiarras caras.
• Integrações bloqueadas. Provedores de pagamento, sistemas de autenticação ou APIs de que você precisa não suportam mais a sua stack.
• Entrega lenta por causa da plataforma. Pequenas mudanças levam dias por causa das ferramentas, não do problema.

Saber quando não fazer é igualmente importante. Se o problema real é código bagunçado em uma plataforma que, fora isso, é saudável, refatorar costuma sair mais barato. Se o produto está fracassando no mercado, uma nova fundação não vai ajudar. E se ninguém entende o que o app realmente faz, você precisa de uma auditoria antes de se comprometer com qualquer migração. Essa auditoria é a primeira coisa que eu peço antes de recomendar mover qualquer coisa.

Um ponto sobre custo: uma reescrita completa normalmente custa mais e demora mais do que uma migração incremental, porque o sistema antigo precisa continuar rodando em paralelo o tempo todo. Esse é um dos grandes motivos pelos quais o replatforming em etapas tende a vencer em produtos no ar com usuários pagantes.

O que mais quebra durante um replatforming?

Na minha experiência, o código novo raramente é o que falha. As surpresas vêm de comportamentos que ninguém documentou.

Jobs em segundo plano e tarefas agendadas

Cron jobs, workers de fila e scripts noturnos muitas vezes vivem fora da base de código principal, ou dentro dela sem documentação. Eles enviam emails, expiram sessões, conciliam pagamentos. Se você não os encontrar, eles simplesmente param de rodar na nova plataforma, e ninguém percebe até um cliente reclamar.

Fluxos de dinheiro

Checkout, cobrança, reembolsos e faturamento têm casos de borda acumulados ao longo de anos: descontos que se combinam de formas estranhas, regras de arredondamento, novas tentativas depois de timeouts do provedor. É aqui que eu gasto mais tempo de teste e aceito o rollout mais lento.

Peculiaridades dos dados

Bancos antigos guardam nulls onde o código assume valores, registros duplicados, encodings inconsistentes e linhas criadas por funcionalidades removidas há muito tempo. O novo schema é mais limpo do que a realidade, e a primeira importação de dados reais mostra isso.

Integrações e webhooks

Terceiros costumam ter suas URLs antigas, allowlists de IP ou credenciais fixas no código. Um webhook apontado para o sistema antigo continua entregando eventos para ele depois da virada.

Sessões, autenticação e URLs

Usuários deslogados de surpresa, hashes de senha quebrados, URLs alteradas que derrubam o posicionamento em buscadores ou links salvos. Tecnicamente são coisas pequenas, mas custam caro em confiança.

Diferenças de desempenho

Uma query que era rápida no motor de banco antigo pode ser lenta no novo. O comportamento sob carga muda com a plataforma, então teste com volumes de dados realistas.

Como fazer replatforming sem tirar o produto do ar?

Evite a virada big-bang, em que você constrói tudo e troca em um fim de semana. Ela concentra todo o risco em um único momento, sem um caminho fácil de volta. A abordagem em que eu confio é incremental: o sistema antigo continua atendendo os usuários enquanto o novo assume peça por peça.

Na avanzzada, eu liderei a migração completa de toda a arquitetura da plataforma de uma stack legada para uma nova enquanto as pessoas continuavam usando todos os dias. A ordem do trabalho importou mais do que a tecnologia. A sequência abaixo começa com a mesma ordem que eu uso sempre que assumo uma base de código: primeiro os acessos, depois o build, depois os fluxos de dinheiro, depois os riscos.

1. Consiga acesso e um build funcionando. Repositórios, hospedagem, bancos de dados, contas de terceiros, segredos e a capacidade de fazer build e deploy do sistema atual. Você não consegue migrar o que não consegue rodar.
2. Mapeie os fluxos de dinheiro e o comportamento escondido. Liste jobs, integrações, pagamentos e tudo o que toca receita ou dados de usuários. Isso vira o seu checklist.
3. Coloque um ponto de desvio na frente de tudo. Antes de escrever código novo, adicione uma camada de roteamento ou feature flags para poder mandar o tráfego para o antigo ou para o novo, por rota ou por grupo de usuários.
4. Mova uma fatia de cada vez. Comece pelas partes de baixo risco e baixo tráfego. Cada fatia ganha seus próprios testes de comparação com o comportamento antigo.
5. Libere aos poucos. Mande uma pequena parcela dos usuários para o novo caminho, acompanhe erros e métricas de negócio, e então amplie. Se algo parecer errado, volte o desvio.
6. Migre os dados com cuidado. Mantenha os dois bancos sincronizados durante a transição e decida qual é a fonte da verdade de cada tabela em cada etapa.
7. Aposente a peça antiga. Só remova uma fatia depois que ela rodar sem problemas por um tempo. Deixar código antigo rodando para sempre anula o propósito.

Isso começa mais devagar do que uma reescrita, porque você gasta tempo primeiro com o ponto de desvio e os testes. Compensa porque cada passo é reversível e os usuários não ficam expostos a um único dia de lançamento de alto risco. Não posso prometer que nenhuma migração terá incidentes, mas essa estrutura tende a manter os incidentes pequenos e recuperáveis.

Quer uma segunda opinião sobre a sua migração?

Se você está avaliando um replatforming do seu app, mande um email para me@filipeeduardo.dev com uma breve descrição da stack e do que está doendo. Fico feliz em trocar ideias e dizer o que eu verificaria primeiro. Se quiser ajuda externa, veja antes como avaliar serviços de modernização de sistemas legados.