Modernização de sistemas legados: guia prático para fundadores

Na prática, modernização de sistemas legados é o trabalho de levar um sistema antigo, mas valioso, para uma stack, arquitetura ou infraestrutura mais nova sem perder o que o torna valioso: os usuários, os dados e a receita. Bem feita, ela acontece peça por peça enquanto o produto continua rodando, não como uma reescrita big-bang que congela o negócio por um ano.

Sou o Filipe, engenheiro full-stack sênior no Brasil. Este guia vem de sete anos construindo produtos web e mobile, incluindo liderar a migração de uma plataforma em produção enquanto as pessoas continuavam usando todos os dias. Ele foi escrito para fundadores e CTOs que herdaram uma base de código, estão saindo de uma agência ou estão presos a uma stack que deixa o time lento.

O que é modernização de sistemas legados, e quando um sistema conta como legado?

Um sistema é legado quando ainda faz um trabalho importante, mas é difícil de mudar com segurança. Idade é um sinal fraco. Já vi apps relativamente novos que eram, na prática, legados porque ninguém os entendia, e sistemas bem mais antigos que estavam saudáveis porque tinham testes, documentação e fronteiras claras.

Estes são os sinais que eu procuro:

• Medo de fazer deploy. Os releases são raros, manuais ou feitos tarde da noite porque algo pode quebrar.
• O conhecimento está na cabeça de uma pessoa. O desenvolvedor original ou a agência saiu, e ninguém consegue explicar por que certo código existe.
• Dependências sem suporte. A versão da linguagem, o framework ou as bibliotecas não recebem mais correções de segurança.
• Nenhuma rede de proteção. Há poucos ou nenhum teste automatizado, então cada mudança é uma aposta.
• Dificuldade para contratar. Engenheiros não querem trabalhar com a stack, ou os poucos que a conhecem são caros e difíceis de encontrar.
• Entrega lenta de funcionalidades. Uma mudança pequena leva semanas porque está tudo emaranhado.

Modernização é o termo guarda-chuva para as opções que você tem: refatorar o código, levá-lo para uma nova infraestrutura, substituir partes dele ou reconstruí-lo. São estratégias diferentes, com riscos diferentes, e eu as comparo mais abaixo.

Legado não é a mesma coisa que dívida técnica

Dívida técnica é o acúmulo de atalhos em uma base de código. Legado é a situação em que essa dívida, somada a tecnologia desatualizada e conhecimento perdido, torna o sistema difícil de evoluir. Você pode ter dívida sem ser legado, e pode pagar dívida sem modernizar a plataforma inteira.

Como saber que chegou a hora de modernizar em vez de remendar?

Remendar é o certo quando os problemas são locais e a base é sólida. Modernizar é o certo quando a própria base é o problema. O teste que uso é simples: o custo de cada mudança está subindo com o tempo, e a causa é estrutural?

Sinais que apontam para modernizar

• Correções de segurança não podem ser aplicadas porque o runtime ou o framework chegou ao fim da vida.
• Cada funcionalidade nova quebra algo sem relação nenhuma.
• Você não consegue contratar nem integrar engenheiros num ritmo razoável.
• O produto precisa de capacidades que a arquitetura não suporta, como funcionalidades em tempo real, um app mobile na mesma API ou múltiplos tenants.
• Os custos de infraestrutura ou as quedas crescem mais rápido que o uso.
• Um comprador, investidor ou cliente enterprise está fazendo perguntas difíceis sobre segurança ou manutenibilidade.

Sinais que apontam para remendar

• Um módulo é o problema, e o resto está estável.
• A dor é uma funcionalidade que falta, não uma estrutura quebrada.
• O time é produtivo e a stack ainda tem suporte.
• Você não tem um resultado de negócio claro que a modernização destravaria.

Um alerta: engenheiros adoram stacks novas, eu incluído. Não modernize porque uma tecnologia está na moda. Escreva primeiro o motivo de negócio, como releases mais rápidos, menos incidentes, capacidade de contratar ou uma exigência de cliente. Se você não conseguir, provavelmente está diante de um problema de refatoração, não de um projeto de modernização.

Quando for modernizar, ajuda ter uma linha de base. Anote quanto tempo uma mudança típica leva da ideia até a produção, com que frequência os deploys falham e quantos incidentes você tem por mês. Sem esses números, você não consegue dizer depois se o trabalho valeu a pena.

O que fazer primeiro quando você herda uma base de código legada?

Não comece mudando código. Comece assumindo o controle. A ordem que sigo nos primeiros 30 dias é: acessos primeiro, depois o build, depois os fluxos de dinheiro, depois os riscos. A ordem importa porque cada passo depende do anterior.

1. Acessos

Quando assumo uma base de código, a primeira coisa que faço é inventariar tudo o que o sistema toca e garantir que a empresa seja dona disso. Isso inclui repositórios de código, contas de hospedagem e de nuvem, o domínio e o DNS, o banco de dados, serviços de terceiros (pagamentos, email, analytics, autenticação), contas nas lojas de apps e segredos. Se a agência ou o desenvolvedor anterior for o único dono de qualquer um desses itens, transfira a titularidade agora, enquanto a relação ainda é cooperativa.

Depois, troque as credenciais que ex-prestadores ainda possam conhecer. É rotina, não acusação.

2. O build

Você consegue fazer o build e o deploy do sistema do zero numa máquina limpa? Muitas bases de código herdadas só funcionam no notebook do desenvolvedor original. Tenha um build reproduzível, documente os passos e faça você mesmo um deploy antes de mudar qualquer coisa. Se você não consegue fazer deploy, não consegue corrigir nada com segurança.

3. Os fluxos de dinheiro

Identifique os fluxos em que o negócio ganha ou perde dinheiro: checkout, assinaturas, cobrança, cadastro, a ação principal pela qual os usuários pagam. Rastreie cada um de ponta a ponta, adicione monitoramento e alertas e escreva pelo menos um teste automatizado básico ou um checklist para ele. Essas são as partes que você nunca pode quebrar. Aprendi a tratar esses fluxos com cuidado redobrado no time de carrinho e checkout da Total Wine & More, uma varejista americana com 190 milhões de visitas por ano no site, onde o checkout é justamente o lugar em que um erro pequeno fica caro rápido.

4. Os riscos

Só agora faça uma revisão de riscos mais ampla: dependências desatualizadas, segredos expostos, backups ausentes, restaurações nunca testadas, tratamento de dados pouco claro, pontos únicos de falha. Classifique-os por probabilidade e impacto, e corrija primeiro os baratos e graves. Uma auditoria de código é uma versão mais profunda deste passo, e vale a pena fazê-la por si só.

Ao fim dos 30 dias, você deve ter um mapa do sistema, um deploy repetível, fluxos de dinheiro monitorados e uma lista curta e priorizada de riscos. Esse é o ponto de partida real para qualquer decisão de modernização.

Reescrever, refatorar, replatforming ou strangler: qual abordagem serve?

Essas quatro palavras costumam se misturar, então aqui estão lado a lado.

Por que meu padrão é o incremental

Meu padrão é a migração incremental, normalmente a abordagem strangler: colocar um chaveamento na frente de tudo antes de escrever código novo. As requisições passam por uma camada de roteamento, e essa camada decide se o sistema antigo ou o novo atende cada uma. Aí você move uma fatia de cada vez, valida em produção e mantém a possibilidade de voltar. Foi esse padrão que nos permitiu migrar uma plataforma em produção na avanzzada sem pedir que os usuários parassem de usá-la.

Reescritas big-bang falham por motivos previsíveis. O sistema antigo continua mudando enquanto você o reconstrói, então o alvo se move. Comportamentos não documentados, como casos de borda dos quais os clientes dependem, somem na versão nova. E você não entrega valor nenhum até o final, que é exatamente quando a pressão está no máximo.

Uma reescrita ainda pode ser a decisão certa. Se o sistema é pequeno, se a regra de negócio é bem entendida, ou se o código antigo está tão quebrado que envolvê-lo é mais difícil do que substituí-lo, reconstruir tudo pode ser mais rápido. Só tome essa decisão com base em evidências, não em frustração.

Como migrar uma plataforma em produção sem parar o produto?

Na avanzzada, liderei a migração completa de uma plataforma que se candidata automaticamente a vagas de emprego para seus usuários. Movemos toda a arquitetura de uma stack legada para uma nova enquanto as pessoas continuavam usando todos os dias. As lições abaixo vêm desse trabalho e de situações parecidas.

Passo 1: coloque o chaveamento primeiro

Antes de qualquer código novo, adicione uma camada de roteamento ou feature flags para poder mandar tráfego para as implementações antiga ou nova, por rota, por grupo de usuários ou por porcentagem. Essa é a decisão mais importante do projeto, porque torna reversível cada passo seguinte.

Passo 2: escolha a primeira fatia com cuidado

Comece com algo real, mas de baixo risco: uma página somente leitura, uma ferramenta interna, uma funcionalidade pequena com entradas e saídas claras. O objetivo é provar o pipeline, o deploy, o monitoramento e o rollback, não mover a parte mais difícil primeiro.

Passo 3: registre o comportamento atual

Antes de substituir uma funcionalidade, registre o que ela faz hoje, incluindo os casos estranhos. Testes que rodam contra o sistema antigo e depois contra o novo são a forma mais barata de encontrar comportamentos faltando. Quando os dois discordarem, decida qual está certo.

Passo 4: libere primeiro para poucos usuários

Mande uma pequena parte do tráfego para o caminho novo, observe os erros e as métricas de negócio e depois amplie. Se algo quebrar, volte o chaveamento. Essa é a ideia por trás dos releases canário, e funciona porque os erros ficam pequenos.

Passo 5: trate os dados de forma deliberada

Os dados costumam ser a parte mais difícil. As opções incluem compartilhar o banco antigo durante a transição, sincronizar dois bancos de dados ou migrar em fases. Seja qual for a escolha, defina qual sistema é a fonte da verdade em cada etapa e ensaie a migração numa cópia dos dados de produção antes de rodá-la para valer.

Passo 6: aposente o código antigo

Termine cada fatia apagando a implementação antiga. Uma migração que nunca remove nada deixa você mantendo dois sistemas indefinidamente, que é o pior resultado possível.

Espere que o meio do projeto pareça lento. Você está rodando dois sistemas, e esse é o preço de não parar o negócio.

Quanto custa a modernização de sistemas legados, e por que reescritas custam mais?

Não vou dar um número, porque qualquer valor sem conhecer o seu sistema seria inventado. O que posso dar é o que puxa o custo e como comparar as opções.

O que puxa o custo

• Tamanho e complexidade do sistema. Quantidade de funcionalidades, integrações e perfis de usuário.
• Qualidade do que já existe. Testes, documentação e fronteiras limpas deixam tudo mais barato.
• Volume e formato dos dados. Dados bagunçados ou inconsistentes aumentam o trabalho de migração.
• Exigências de disponibilidade. Quanto menos indisponibilidade você tolera, mais cuidadosa e mais lenta é a virada.
• Senioridade do time. Engenheiros sêniores custam mais por hora, mas tendem a evitar desvios caros.
• Disciplina de escopo. Adicionar funcionalidades durante uma migração é o clássico destruidor de orçamento.

Por que uma reescrita normalmente custa mais

Uma reescrita normalmente custa mais e demora mais do que uma migração incremental, porque o sistema antigo precisa continuar rodando em paralelo. Você paga para manter o produto antigo, paga para construir o novo e paga de novo para chegar à paridade de funcionalidades antes de poder virar a chave. Com uma abordagem incremental, cada fatia entrega valor assim que vai ao ar, e você pode parar a qualquer momento com um produto funcionando.

Isso não torna a migração incremental barata. A camada de roteamento, o período com os dois sistemas rodando e a sincronização de dados exigem esforço. Mas o gasto fica distribuído, o risco é menor e você pode corrigir o rumo.

Como manter as estimativas honestas

• Faça uma descoberta com prazo fechado (os 30 dias de transição são uma boa) antes de se comprometer com um orçamento completo.
• Estime fatia por fatia, não o programa inteiro.
• Inclua testes, migração de dados, monitoramento e o custo de rodar os dois sistemas.
• Reserve uma margem para surpresas. Em bases de código herdadas, elas sempre aparecem.

Desconfie de orçamentos de preço fechado feitos sem ver o código. As incógnitas são grandes demais para precificar com honestidade.

Como manter os usuários seguros e a receita entrando durante a mudança?

Os usuários deveriam mal perceber a migração. Estas práticas tornam isso realista.

Proteja primeiro os fluxos de dinheiro

Checkout, cobrança e cadastro recebem as proteções mais fortes: monitoramento, alertas, testes e um rollback documentado. Se for migrar um deles, faça isso mais para o fim, com uma pequena parte do tráfego, num período em que o time esteja totalmente disponível para acompanhar.

Tenha sempre um caminho de volta

Todo release deve poder ser revertido rapidamente. Com uma camada de roteamento, o rollback é uma mudança de configuração, não um redeploy de emergência. Setups blue-green, em que o ambiente antigo continua no ar até o novo se provar, cumprem o mesmo papel em mudanças de infraestrutura.

Monitore métricas de negócio, não só erros

Um fluxo migrado pode não retornar erro nenhum e ainda assim perder dinheiro, por exemplo descartando um campo em silêncio ou mudando um redirecionamento. Acompanhe conversão, pedidos concluídos ou candidaturas enviadas com sucesso, seja qual for a ação principal do seu produto, e compare os caminhos antigo e novo enquanto os dois rodam.

Proteja os dados

• Faça backups verificados antes de cada etapa de dados e teste se consegue restaurá-los.
• Limite quem pode mexer nos dados de produção durante a migração.
• Mantenha um registro claro do que foi movido, quando e como.
• Se você lida com dados pessoais ou regulados, envolva um advogado ou consultor de compliance. Este artigo não é aconselhamento jurídico.

Comunique

Avise o suporte e quem atende clientes sobre o que está mudando e quando. A maior parte da dor dos clientes durante migrações não é técnica, é surpresa. Uma nota interna curta antes de cada release evita muita confusão.

Congele o que puder

Limite o trabalho em funcionalidades novas nas áreas que estão sendo migradas. Mudanças entrando no código antigo enquanto você o substitui geram retrabalho e divergências sutis. Um congelamento curto por fatia costuma ser mais fácil do que um longo para o sistema inteiro.

Modernizar com o time interno, com um contractor ou com uma agência?

Não existe resposta universal. Depende da capacidade do seu time, do seu prazo e de quanto conhecimento institucional você precisa preservar.

Time interno

Melhor para ownership de longo prazo e conhecimento do domínio. A desvantagem é que seus engenheiros provavelmente também estão tocando o produto, então a modernização disputa espaço com o trabalho do dia a dia, e talvez eles nunca tenham feito uma migração assim.

Contractor sênior ou time pequeno

Bom quando você precisa de liderança experiente por um período definido, para montar o plano, construir as primeiras fatias e deixar o time com um padrão que funciona. Funciona melhor quando o seu pessoal continua envolvido, para que o conhecimento não vá embora quando o contrato acabar. Transparência total: eu mesmo sou um engenheiro brasileiro, então tenho um viés a favor do modelo nearshore. Ele tem vantagens reais, como a sobreposição de fuso horário com os EUA, mas pese isso no seu próprio contexto.

Agência

Útil quando você precisa de volume, de um mix de habilidades e de gestão de projeto num pacote só. O risco é aquele que você talvez já conheça: se a agência for dona do conhecimento e das contas, você pode acabar herdando uma base de código de novo. Se for por esse caminho, exija documentação, repositórios e contas de nuvem no seu nome, e passagens de conhecimento regulares.

O que verificar, seja qual for a escolha

• Eles começam com uma descoberta ou pulam direto para uma estimativa de reescrita?
• Eles propõem um plano incremental e reversível?
• Você será dono de todo o código, das contas e da documentação desde o primeiro dia?
• Quem é responsável pelos fluxos de dinheiro durante a migração?
• Eles conseguem mostrar uma migração anterior de um sistema em produção e explicar o que deu errado nela?

Entregar um sistema legado a um novo fornecedor sem um plano é o jeito mais comum de uma transição dar errado. Os primeiros 30 dias de acessos, build e fluxos de dinheiro decidem muita coisa, então garanta que alguém os faça direito, seja quem for.

Quer uma segunda opinião sobre o seu caso?

Se você herdou uma base de código ou está planejando uma migração, mande um email para me@filipeeduardo.dev com uma descrição curta da sua stack e do problema. Fico feliz em trocar ideias e dizer o que eu verificaria primeiro.