Modernização de sistemas legados: quando, como e quanto custa

Sistema legado não é sistema velho. É sistema do qual o negócio depende e que ninguém consegue mais mudar com segurança: a tecnologia saiu de suporte, as regras de negócio estão na cabeça de uma ou duas pessoas, cada alteração quebra algo em outro lugar e integrar um canal novo leva meses. A empresa não para por causa dele; ela deixa de crescer. Este guia trata das perguntas que quem decide precisa responder: quando agir, modernizar ou reescrever, como fazer sem parar a operação e o que define o custo.

Sinais de que chegou a hora

O momento certo raramente é um incidente; é o acúmulo de sintomas que cada área vê de um jeito.

• A tecnologia saiu de suporte ou o fornecedor original não existe mais; cada atualização de segurança é um risco
• O sistema depende de poucas pessoas, e a saída de uma delas viraria crise
• Integrar um canal novo, um parceiro ou um meio de pagamento leva meses em vez de semanas
• O custo de infraestrutura é desproporcional ao valor entregue, porque a arquitetura não permite escalar só o que precisa
• Auditoria, certificação ou LGPD exigem controles que o sistema não consegue oferecer
• Uma fusão, aquisição ou nova linha de negócio exige unificar operações que rodam em sistemas diferentes

Quando três ou mais desses sinais aparecem ao mesmo tempo, adiar custa mais do que agir. Não por uma estatística de mercado, mas porque cada mês adiciona regras não documentadas, integrações improvisadas e pessoas que aprendem a contornar o sistema em vez de usá-lo.

O custo de adiar, com dados

A McKinsey, em pesquisa com 50 CIOs de empresas com receita acima de US$ 1 bilhão, encontrou que a dívida técnica equivale a 20% a 40% do valor de todo o parque tecnológico antes da depreciação, e que 10% a 20% do orçamento destinado a novos produtos é desviado para resolver problemas dessa dívida. Seis em cada dez CIOs viram a dívida crescer de forma perceptível nos três anos anteriores. Não é um problema de grandes empresas: é mais visível nelas porque há quem meça.

No nível do time, a Stripe, com a Harris Poll, mediu que desenvolvedores gastam 13,5 de 41,1 horas semanais com dívida técnica e código ruim, cerca de um terço da capacidade de engenharia. Em uma equipe de dez pessoas, é o equivalente a três salários pagos para manter o que existe em vez de construir o que o negócio precisa.

Sobre o método, a orientação prescritiva da AWS lista sete estratégias de migração (retire, retain, rehost, relocate, replatform, repurchase, refactor) e é explícita: refatorar durante uma migração grande não é recomendado, porque combina dois riscos no mesmo projeto. A leitura para quem decide é a que este guia defende: separar a mudança de plataforma da mudança de arquitetura, e fazer as duas em etapas.

Modernizar ou reescrever

É a decisão mais cara do projeto e a que mais se erra por impulso. Reescrever do zero parece limpo: um sistema novo, sem dívida técnica. Na prática, costuma significar um ou dois anos em que o legado continua recebendo mudanças enquanto o novo tenta alcançá-lo, e um dia de virada em que tudo precisa funcionar. Modernizar por etapas preserva mais valor na maioria dos casos: atualizar a plataforma, mover a hospedagem, extrair um serviço por vez, manter URLs e integrações, e reescrever apenas o que realmente não serve mais.

A decisão depende de perguntas objetivas. As regras de negócio embutidas no sistema ainda descrevem como a empresa opera, ou já estão erradas? A base de código pode ser lida e testada, ou é uma caixa preta? Os dados estão íntegros, ou há anos de gambiarra acumulada? Quantos sistemas dependem deste? Existe alguém que entenda o todo? Um mapa do legado, feito em três semanas com leitura de código, banco, infraestrutura e entrevistas com quem opera, responde a isso e coloca as duas opções lado a lado com custo, prazo e risco. A empresa decide com número, não com opinião.

O método que não para a operação

O erro mais comum em modernização é tratar como projeto de tecnologia o que é projeto de operação. A sequência que funciona começa pelo negócio.

Primeiro, mapear a operação como ela é hoje: fluxos reais, com quem opera, área por área. Não o que o manual diz; o que acontece. É aqui que aparecem as regras de negócio que ninguém escreveu e as exceções que sustentam o faturamento.

Segundo, revisar e redesenhar: com o mapa em mãos, propor fluxos mais eficientes com base no que já funcionou em outras operações. A empresa decide o que muda e o que se preserva; cada decisão fica registrada com data, custo e ganho esperado. Modernizar sem revisar o processo é gastar para automatizar a ineficiência.

Terceiro, canário antes do lote: um registro, uma rota, um serviço migrado e validado antes de qualquer massa. Migração idempotente, que pode ser rerodada sem duplicar, com tabela de controle. Legado mantido somente leitura durante a transição, URLs preservadas ou redirecionadas, integrações mantidas.

Quarto, ondas com cutover planejado: lotes com delta incremental, validação de paridade e virada de DNS ou de fluxo só quando o novo já está em paridade com o antigo. Cada onda tem rollback. Em um portal de conteúdo com 100 mil publicações, a migração de um data center Oracle para a AWS preservou o SEO, mitigou 100% dos riscos mapeados antes do cutover e não teve downtime do legado ao novo.

O que uma operação de 2.000 pessoas ensina

Em um dos maiores e-commerces da América Latina, a fusão de marcas exigiu integrar operações inteiras em um novo sistema: financeiro, comercial, logística, fiscal, site e marketplace. A operação de mais de 2.000 pessoas foi mapeada de ponta a ponta antes de qualquer decisão de tecnologia. As regras de negócio de cada marca foram revisadas junto a quem operava, e o legado de cada uma foi migrado para um sistema que unificou todos os processos. O ganho de eficiência na operação integrada passou de 40%, em uma empresa com faturamento anual acima de R$ 5 bilhões.

As lições valem para qualquer porte. O mapeamento com quem opera não é etapa preliminar; é onde o projeto se decide. A integração de sistemas é consequência da integração de processos, e não o contrário. E o ganho mede-se no negócio, em eficiência da operação, não em linhas de código migradas.

O que define o custo

O custo de uma modernização depende menos da tecnologia escolhida e mais de quatro fatores. O tamanho do inventário: quantos componentes, integrações e bases de dados existem de fato, não quantos constam no diagrama antigo. A qualidade dos dados: anos de exceções não tratadas viram semanas de higienização. O número de pessoas e áreas envolvidas: cada área tem regras que precisam ser ouvidas e decididas. E o nível de compliance exigido: auditoria, LGPD e certificações pedem evidências que precisam ser produzidas durante o trabalho, não reconstruídas no fim.

Por isso o mapa do legado vem antes do orçamento. Ele transforma uma estimativa em um plano com fases, e cada fase tem escopo, marco, critério de aceite e preço. A empresa paga por fase entregue, e pode parar entre uma e outra sem perder o que já foi feito. Isso também expõe o custo de não fazer: o que se gasta hoje para manter o que existe, em infraestrutura, em pessoas dedicadas e em oportunidades que não acontecem porque o sistema não permite.

Segurança, dados e conformidade durante a transição

Modernizar é o momento em que dados sensíveis trocam de lugar e controles antigos deixam de valer. Cargas de dados precisam ser auditadas, com execução a seco antes da real, em ambientes separados de desenvolvimento, homologação e produção. Dados pessoais ficam fora de repositórios e de logs. Acessos são mínimos e revogados ao fim de cada fase. Quando a empresa precisa de certificação, os controles nascem junto com o sistema novo: em uma empresa de serviços com mais de 60 anos de tradição, o mapeamento de processos e a implantação de mais de 100 controles levaram à certificação ISO 27001 em 12 meses, sem ressalva técnica.

Os erros que mais custam

• Começar pela tecnologia e não pelo processo: escolher a plataforma nova antes de mapear como a operação funciona hoje
• Reescrever tudo de uma vez, com um dia de virada em que tudo precisa funcionar
• Migrar os dados sem higienizar: anos de exceções não tratadas viram bugs no sistema novo
• Não manter o legado somente leitura durante a transição, perdendo a referência para validar paridade
• Mudar URLs, integrações e relatórios que clientes e parceiros dependem, sem plano de redirecionamento
• Não envolver quem opera na revisão das regras: o sistema novo nasce correto no papel e errado na prática
• Tratar documentação e treinamento como etapa final opcional; sem eles, o sistema novo vira o próximo legado

Cada um desses erros tem o mesmo antídoto: mapear antes, decidir com quem opera, migrar em ondas com canário e rollback, e medir no negócio. É menos glamoroso do que uma reescrita completa e é o que mantém a operação de pé enquanto ela muda.

Ágil no ritmo, com o compliance que o setor exige

Grandes fornecedores costumam entregar modernização com camadas de gestão, passagem de bastão entre áreas e responsabilidade diluída; o prazo do contrato e o prazo real raramente coincidem. O outro extremo, o time informal que entrega rápido sem evidência, não serve para operações que passam por auditoria, LGPD ou certificação. O meio termo que funciona é um time sênior e enxuto, em que quem mapeia é quem desenha e quem implanta, trabalhando em ritmo ágil, com decisões registradas com data, custo e ganho, e evidências produzidas durante o trabalho. O compliance entra na medida que o negócio exige, não como burocracia padrão.

Depois da virada

O sistema novo em produção é o começo da segunda metade do trabalho: documentação funcional, treinamento das equipes, transferência de conhecimento e a decisão de quem sustenta. A empresa pode contratar manutenção com SLA ou assumir com o time interno; nos dois casos, a dependência de um fornecedor ou de uma pessoa precisa acabar com a virada. Um legado modernizado que só o fornecedor entende é o próximo legado.

Por onde começar

Por um mapa do legado com escopo e prazo fechados. Três semanas de leitura de código, banco, infraestrutura e entrevistas com quem opera, sem alterar nada, e ao final a decisão entre modernizar e reescrever com custo, prazo e risco de cada caminho. É a menor aposta possível para a maior decisão de tecnologia que a empresa vai tomar nos próximos anos.