1. Descreva o problema em termos observáveis
“O sistema está velho” não define uma prioridade. Uma venda demora a concluir? Uma alteração simples afeta várias telas? A publicação exige intervenção manual? Escolha um fluxo e registre o comportamento atual: tempo de resposta, falhas, esforço de mudança ou tempo de recuperação. Essa referência permite saber se a intervenção melhorou algo.
2. Mapeie o que não pode parar
Liste consumidores da API, tarefas agendadas, integrações externas e regras que só aparecem em situações excepcionais. Observe logs sem registrar dados sensíveis desnecessários. Converse com quem opera o sistema. O banco de dados pode ser compartilhado por mais aplicações do que a documentação indica; mudar uma coluna pode afetar um processo que ninguém lembrou na primeira reunião.
3. Crie uma proteção antes de mudar
Testes de caracterização registram o comportamento atual de um trecho, mesmo quando sua implementação não é ideal. Priorize regras financeiras, permissões e fluxos difíceis de recuperar. Diferencie comportamento necessário de bugs conhecidos para não cristalizar um erro como requisito. Uma cópia representativa e protegida do ambiente ajuda a ensaiar a mudança.
4. Escolha uma fronteira pequena
Uma integração isolada, uma tela com responsabilidade clara ou um processamento assíncrono pode ser um primeiro passo melhor do que trocar toda a arquitetura. Defina um contrato entre a parte antiga e a nova. Se as duas versões coexistirem, determine quem escreve cada dado e como a consistência será mantida. Dupla escrita sem uma estratégia de reconciliação cria um problema adicional.
5. Planeje a volta antes da ida
Publicação gradual e feature flags podem reduzir exposição, mas precisam de critérios para interromper o rollout. Migrações de dados merecem cuidado próprio: voltar o código não desfaz necessariamente uma alteração no banco. Prefira mudanças compatíveis, como adicionar um campo antes de remover o anterior, e ensaie restauração quando ela fizer parte do plano.
6. Compare, documente e remova o que sobrou
Depois da publicação, compare o fluxo com a referência inicial. Acompanhe erros, latência e efeitos na operação durante uma janela adequada ao uso real. Só retire o caminho antigo quando a transição estiver estável. Atualize documentação, remova flags temporárias e registre o que a próxima etapa ainda depende de resolver.
Quando uma reescrita pode fazer sentido
Pode existir uma restrição estrutural: dependência sem suporte, impossibilidade de atender um requisito essencial ou custo de adaptação maior que uma substituição delimitada. Mesmo nesses casos, uma prova técnica pequena e um plano de migração de dados ajudam a estimar o risco. A decisão deve comparar o custo total de manter, adaptar e substituir, incluindo treinamento, operação paralela e manutenção futura.
O que levar para a primeira conversa
Traga um exemplo concreto do problema, quem depende do sistema, como ele é publicado e quais integrações conhece. Não é preciso ter uma arquitetura nova pronta. O primeiro resultado útil pode ser um diagnóstico com prioridades, riscos e uma mudança inicial pequena o suficiente para ser validada.