"Vamos reescrever do zero" é uma das frases mais caras da tecnologia corporativa. Às vezes é a decisão certa; na maioria das vezes, é um projeto de dois anos para chegar onde já se estava. Parte da confusão vem de tratar o envelhecimento do software como defeito de projeto, quando ele é condição de qualquer sistema que continua sendo usado. Lehman já havia formulado isso nas suas leis da evolução de software: todo programa em uso real sofre mudança contínua e, na ausência de trabalho deliberado de manutenção estrutural, tem sua qualidade percebida reduzida ao longo do tempo. A pergunta útil, portanto, não é "esse sistema é legado?", e sim "qual tipo de intervenção esse sistema pede?". O Gartner descreve sete opções de modernização, do encapsulamento à substituição completa, mas na operação de uma empresa real elas se resolvem em três decisões práticas: manter, envelopar ou substituir. Estes são os quatro critérios objetivos que usamos para chegar a uma delas.
Critério 1: risco de plataforma
O sistema roda em tecnologia sem suporte, sem gente disponível no mercado ou sem compatibilidade com a infraestrutura atual? Enquanto a resposta for "ainda não", o risco é administrável. Quando o banco de dados não recebe mais correção de segurança ou o único desenvolvedor que conhece o código está para se aposentar, o relógio começou a contar.
O que transforma essa pergunta em critério objetivo é o inventário. Vale levantar, item a item, cada componente da pilha, sistema operacional, runtime, banco de dados, servidor de aplicação, bibliotecas de terceiros, hipervisor e integrações externas, com a versão em produção, a data de fim de suporte do fabricante e a existência ou não de caminho de atualização. A distinção decisiva não é entre "com suporte" e "sem suporte", é entre "sem suporte, mas com caminho de atualização conhecido" e "sem suporte e sem caminho", porque só o segundo caso caracteriza risco de plataforma de verdade.
Há ainda um componente de conformidade que costuma ser subestimado. Software sem correção de segurança conflita com a obrigação de adotar medidas técnicas aptas a proteger dados pessoais, prevista no art. 46 da LGPD, e com exigências contratuais de clientes, auditorias e certificações. Nesses casos, o risco deixa de ser apenas operacional e passa a ser jurídico e comercial: um sistema que impede a empresa de responder um questionário de segurança já está custando contratos, ainda que continue funcionando perfeitamente.
Um sintoma mensurável de risco de plataforma avançado é a composição do esforço de manutenção. A ISO/IEC/IEEE 14764 separa manutenção corretiva, adaptativa, evolutiva e preventiva. Quando a manutenção adaptativa, aquela que existe apenas para o sistema continuar rodando em um ambiente que mudou, passa a consumir mais esforço que a evolutiva, a equipe deixou de desenvolver o produto e passou a sustentar a plataforma.
Critério 2: custo de mudança
Não é o custo de manter, é o custo de mudar qualquer coisa. Meça quanto tempo leva entre pedir uma alteração simples e vê-la em produção. Se uma mudança de regra de negócio leva meses porque ninguém tem coragem de tocar no código, o legado está cobrando um imposto invisível sobre toda a operação.
Esse imposto pode ser medido com indicadores que já são padrão de mercado. As quatro métricas de entrega consolidadas pela pesquisa DORA, tempo de lead time de uma alteração, frequência de implantação, taxa de falha em mudanças e tempo de restabelecimento após incidente, funcionam igualmente bem em sistemas antigos e servem exatamente para separar percepção de fato. Um sistema em que uma alteração de campo leva seis semanas e uma em cada três implantações precisa de correção emergencial não é caro por opinião do time de tecnologia, é caro por número.
Vale acrescentar um indicador que raramente aparece em relatório mas explica boa parte da lentidão: quanto do backlog está bloqueado por medo. É o conjunto de demandas tecnicamente simples que ninguém prioriza porque exigiriam mexer em um trecho de código sem testes, sem documentação e sem autor disponível. Michael Feathers propõe uma definição de trabalho útil justamente aí: código legado é código sem testes, porque é a ausência de rede de proteção, e não a idade da tecnologia, que impede a mudança segura.
Do lado financeiro, o custo de mudança tem duas faces. A visível é o esforço gasto por alteração. A invisível, quase sempre maior, é o custo de oportunidade das decisões de negócio que não foram tomadas porque o sistema não acompanharia: a promoção que não foi lançada, o canal de venda que não foi aberto, o relatório regulatório entregue à mão. É essa segunda face que costuma justificar economicamente uma modernização, e não a redução do custo de manutenção.
Critério 3: aderência ao processo
O sistema ainda descreve o negócio de hoje? Legados costumam nascer colados ao processo, essa é a força deles. Mas quando a operação muda, com novo canal de venda, nova regra fiscal ou novo modelo logístico, e o sistema não acompanha, o time passa a operar apesar dele, com planilhas e controles paralelos.
A ISO/IEC 25010 chama isso de adequação funcional, desdobrada em completude, correção e pertinência: o sistema cobre todas as tarefas necessárias, produz resultados corretos e faz isso do modo apropriado para o objetivo do usuário. Aderência ruim raramente aparece como erro. Aparece como esforço extra que a operação absorve em silêncio.
Os sinais são contáveis, e recomendamos literalmente contá-los antes de qualquer discussão de arquitetura: quantas planilhas sustentam decisões que deveriam sair do sistema; quantas vezes o mesmo dado é digitado em dois lugares; quantos campos foram desviados da finalidade original, como o campo de observação que virou repositório de regra de negócio; quantas horas por mês são gastas conciliando o que o sistema diz com o que aconteceu de fato. Esse levantamento tem uma vantagem adicional: ele produz, de graça, o mapa dos processos que qualquer modernização terá de cobrir.
Aderência baixa também muda a natureza do projeto. Se o sistema não descreve mais o negócio, o trabalho não é de tecnologia, é de redesenho de processo com apoio de tecnologia. Confundir os dois é a origem mais comum de reescritas que entregam, dois anos depois, uma versão moderna do processo errado.
Critério 4: capacidade de integração
Este é o critério que mais pesa nos nossos projetos. Um legado estável, aderente e barato de manter, mas que não consegue expor dados nem consumir serviços, isola-se do resto da empresa. Antes de condená-lo, vale testar o envelopamento: uma camada de integração na frente, seja API, fila de mensagens ou até leitura direta da base com contrato claro, que deixa o legado participar da arquitetura sem mexer no seu núcleo.
Essa é a primeira das sete opções do Gartner, o encapsulamento, e tem o melhor perfil de risco entre todas: o núcleo permanece intacto, o investimento é baixo, e o resultado aparece em semanas. Nos casos em que não existe interface programável alguma, ainda há caminho. Uma réplica de leitura com visões estáveis publicadas como contrato, ou captura de mudanças no banco de dados alimentando eventos, resolve a maior parte das necessidades de consumo de dados sem alterar uma linha do sistema antigo.
Três cuidados definem se o envelope vai ajudar ou virar um segundo problema. O primeiro é o contrato: o consumidor precisa depender de um contrato versionado, nunca do esquema físico do banco, sob pena de acoplar toda a empresa às tabelas do legado. O segundo é a fronteira de responsabilidade, que Eric Evans descreve como camada de anticorrupção: o envelope traduz modelos e protege o resto da arquitetura das idiossincrasias do legado, mas não pode assumir regra de negócio, ou a empresa passa a ter duas fontes de verdade divergentes. O terceiro é operacional: idempotência, tratamento de reprocessamento e monitoração próprios, porque um envelope sem observabilidade transfere para a integração a fama de instabilidade que era do sistema antigo.
Como pontuar e o que a pontuação decide
Os quatro critérios funcionam melhor com avaliação simples, em três níveis, e sem média ponderada elaborada: cada critério fica verde, amarelo ou vermelho, com a evidência que sustenta a classificação anotada ao lado. Plataforma e custo de mudança pesam mais, porque são os únicos que pioram sozinhos com o tempo. Aderência e integração podem ser endereçadas sem trocar o sistema; risco de plataforma e custo de mudança, não.
- Manter: risco de plataforma baixo, custo de mudança aceitável, processo aderente. Não gaste energia aqui. Cabe apenas manutenção preventiva e vigilância sobre as datas de fim de suporte.
- Envelopar: núcleo saudável, mas isolado. A camada de integração entrega valor em semanas, devolve os dados do legado para o resto da empresa e adia a discussão de troca por tempo suficiente para que ela seja tomada com dados, não com urgência.
- Substituir: dois ou mais critérios no vermelho, especialmente plataforma e custo de mudança. Aí sim, com migração planejada, por fases, e nunca "big bang".
Quem trabalha com portfólios maiores encontrará a mesma lógica no modelo TIME do Gartner, que classifica aplicações em tolerar, investir, migrar ou eliminar. A diferença é de escala, não de método: os quatro critérios acima são o que produz a evidência para classificar cada sistema.
O envelopamento na prática
Quando a decisão é envelopar, o trabalho tem uma sequência que se repete com pouca variação. Primeiro, mapear a fronteira: quais dados e quais operações o resto da empresa realmente precisa do legado, o que quase nunca corresponde a tudo o que ele faz. Depois, publicar esses dados e operações como contrato explícito, versionado e documentado, com autenticação e limites de uso próprios. Em seguida, redirecionar os consumidores existentes, inclusive as planilhas e as extrações manuais, para o contrato novo, porque enquanto houver acesso paralelo ao banco a fronteira não existe de fato. Por último, instrumentar: volume, latência, erros e uso por consumidor.
Essa última etapa é a que muda a conversa. Um envelope instrumentado mostra, em poucos meses, quais partes do legado são realmente críticas, com que frequência são usadas e por quem. É a melhor base de estimativa que se pode ter para uma eventual substituição, e não existe forma de obtê-la antes de encapsular. Mais da metade dos legados que chegam a nós já "condenados" à reescrita não passa desta etapa: com a fronteira de integração pronta, o problema que motivava a troca desaparece.
Quando substituir é a decisão certa
Quando plataforma e custo de mudança estão no vermelho, substituir deixa de ser preferência e passa a ser a única saída, mas a forma de substituir determina o resultado. O padrão que usamos é o do estrangulamento gradual, descrito por Martin Fowler como strangler fig: o sistema novo nasce ao lado do antigo, atrás da mesma fronteira de integração, e assume um domínio funcional por vez, até que o legado possa ser desligado. Cada fase entrega valor isolado e é reversível, o que é a diferença central em relação à troca única.
Quatro pontos merecem tratamento explícito no plano. As regras de negócio vigentes precisam ser extraídas e documentadas antes de serem reimplementadas, porque em sistemas antigos o código é a única especificação existente; é o trabalho que Chikofsky e Cross classificam como recuperação de projeto, e ele é a maior fonte de surpresa em cronogramas de reescrita. Os dados exigem plano próprio, com período de operação em paralelo, conciliação automatizada entre antigo e novo e critério de aceite numérico; como migração de dados pessoais é tratamento para efeito da LGPD, vale aproveitar para aplicar minimização e descarte do que não tem mais finalidade, em vez de replicar trinta anos de histórico por inércia. O escopo deve ficar congelado no comportamento atual: redesenhar o processo e trocar a tecnologia ao mesmo tempo é o que transforma projetos de nove meses em projetos de três anos. E o desligamento precisa ter data, responsável e política de retenção definidos desde o início, ou a empresa termina pagando por dois sistemas indefinidamente.
O que quase sempre dá errado
Os modos de falha da reescrita são conhecidos e repetidos. O primeiro é o "big bang", a virada única em data marcada, que concentra todo o risco no pior momento possível e não oferece caminho de volta. O segundo é o que Fred Brooks batizou de efeito do segundo sistema: a tendência de sobrecarregar a segunda versão com tudo o que se queria ter feito na primeira, o que produz um sistema mais complexo que o legado que ele veio substituir, e frequentemente mais frágil.
O terceiro é estimar o esforço pelo tamanho aparente do sistema, telas e relatórios, quando o custo real está nas regras não escritas, nas exceções acumuladas por décadas e nas integrações que ninguém documentou. O quarto é dividir a mesma equipe entre sustentar o antigo e construir o novo sem separar capacidade de forma explícita: na prática, a operação sempre ganha a disputa por prioridade, e o projeto novo avança em ritmo que ninguém planejou. Brooks já alertava, em "No Silver Bullet", que a complexidade essencial de um domínio não desaparece com a troca de tecnologia. Ela só muda de lugar.
O denominador comum
Reescrever é uma ferramenta, não um objetivo. O objetivo é a operação andar. Os quatro critérios existem para que essa decisão seja tomada com evidência disponível, datas de fim de suporte, lead time de alteração, contagem de controles paralelos e inventário de integrações, em vez de com a intuição de quem convive com o sistema há mais tempo. E, na nossa experiência, mais da metade dos legados "condenados" só precisava de uma boa fronteira de integração.
Referências
- ABNT NBR ISO/IEC 14764 / ISO/IEC/IEEE 14764:2022 (Engenharia de sistemas e software - Processos de ciclo de vida de software - Manutenção)
- ISO/IEC 25010:2023 (SQuaRE - Modelo de qualidade de produto de software)
- ISO/IEC/IEEE 12207:2017 (Processos de ciclo de vida de software)
- LEHMAN, M. M. "Programs, Life Cycles, and Laws of Software Evolution". Proceedings of the IEEE, v. 68, n. 9, 1980
- CHIKOFSKY, E.; CROSS, J. "Reverse Engineering and Design Recovery: A Taxonomy". IEEE Software, v. 7, n. 1, 1990
- SEACORD, R.; PLAKOSH, D.; LEWIS, G. "Modernizing Legacy Systems: Software Technologies, Engineering Processes, and Business Practices". SEI Series, Addison-Wesley, 2003
- FEATHERS, M. "Working Effectively with Legacy Code". Prentice Hall, 2004
- FOWLER, M. "Strangler Fig Application". martinfowler.com, 2004
- EVANS, E. "Domain-Driven Design: Tackling Complexity in the Heart of Software". Addison-Wesley, 2003 (camada de anticorrupção)
- BROOKS, F. "The Mythical Man-Month: Essays on Software Engineering". Edição comemorativa, Addison-Wesley, 1995 (efeito do segundo sistema e "No Silver Bullet")
- FORSGREN, N.; HUMBLE, J.; KIM, G. "Accelerate: The Science of Lean Software and DevOps". IT Revolution, 2018 (métricas DORA)
- Gartner. "7 Options to Modernize Legacy Systems" e modelo TIME de gestão de portfólio de aplicações
- Lei nº 13.709, de 14 de agosto de 2018 (LGPD), arts. 6º e 46