Modernização de sistema legado: por partes ou reescrever?

Segunda-feira, sete da manhã. O sistema da base demora para abrir, o relatório de embarques do fim de semana saiu com a coluna de horários vazia e a única pessoa que entende aquela parte do código saiu da empresa no ano passado. A operação já abriu duas planilhas paralelas para não parar. Na reunião, alguém diz que o certo é jogar tudo fora e fazer um sistema novo. Outra pessoa lembra que da última vez o projeto novo levou um ano e nunca entrou em produção.

Este artigo ajuda a tomar essa decisão com critério. Você vai encontrar o que caracteriza um sistema legado, por que a reescrita completa costuma dar errado, uma comparação entre os dois caminhos, uma matriz de decisão para usar na reunião e um roteiro para modernizar por partes sem parar o trabalho. Se a dúvida ainda é anterior, entre ter um sistema próprio e comprar um pronto, comece pelo artigo sistema sob medida ou software pronto.

O que é um sistema legado?

Um sistema legado é um sistema que ainda sustenta a operação, mas ficou difícil de mudar: cada ajuste demora, quebra outra coisa ou depende de uma pessoa específica. A idade conta menos do que isso. Um sistema de cinco anos sem testes, sem documentação e com versões fora de suporte já se comporta como legado.

O Microsoft Azure Architecture Center descreve o quadro assim: com o tempo, as ferramentas, a hospedagem e a arquitetura em que o sistema foi construído ficam obsoletas, e cada função nova o deixa mais complexo e mais difícil de manter. Nas empresas de operação que atendemos, o legado costuma aparecer em três formatos: um sistema web feito por um fornecedor que não existe mais, um programa instalado nas máquinas do escritório e uma planilha com macros que virou sistema sem ninguém decidir.

O sinal mais claro de legado é o comportamento da equipe. Quando a operação passa a criar controles paralelos em planilha porque o sistema não acompanha, o problema já saiu da TI e chegou ao campo.

Por que reescrever do zero costuma dar errado?

Reescrever do zero costuma dar errado porque o sistema antigo guarda anos de regras e correções que ninguém documentou, e o projeto novo leva muito mais tempo do que o previsto para alcançar o que o antigo já faz. Enquanto isso, a operação continua presa ao sistema velho, sem melhorias.

Martin Fowler, autor de referência em arquitetura de software, escreveu no texto sobre o padrão Strangler Fig que o plano de construir um sistema novo que faça exatamente o mesmo, só que em tecnologia melhor, deu errado na maior parte das vezes que ele acompanhou. Os motivos que ele aponta são três: a troca leva muito tempo, os usuários não podem esperar por funções novas e é difícil descobrir os detalhes do comportamento atual. Boa parte desse comportamento, acrescenta, nem é mais desejada, e reconstruí-la é desperdício.

Joel Spolsky, cofundador do Stack Overflow, chamou a reescrita completa de o pior erro estratégico que uma empresa de software pode cometer. O argumento dele vale para sistemas internos: aquela função feia de duas páginas carrega correções de problemas que só apareceram depois de semanas de uso real. Jogar o código fora joga junto esse conhecimento.

Nos sistemas que mantemos, vemos o mesmo padrão em escala menor. A regra de quem pode aprovar uma hora extra, o arredondamento de um cálculo de faturamento, o motivo de um campo obrigatório na portaria: nada disso está num documento. Está no código, e só aparece quando alguém tenta reconstruir a tela e o usuário reclama que "antes funcionava".

O que muda entre modernizar por partes e reescrever?

Modernizar por partes troca o sistema módulo a módulo, com a operação usando o sistema o tempo todo. Reescrever constrói um sistema inteiro em paralelo e faz a troca de uma vez. A tabela compara os dois caminhos nos pontos que mais pesam para quem opera.

A linha do custo de transição merece atenção. Fowler reconhece que a abordagem gradual exige uma arquitetura provisória, que existe só para os dois sistemas conviverem e some no fim. Parece desperdício, mas, para ele, o risco menor e o valor entregue mais cedo compensam esse custo.

Como decidir entre modernizar e reescrever?

A decisão sai de um levantamento do que existe hoje e de uma conversa honesta sobre quais sinais pesam mais na sua operação. A matriz abaixo reúne as perguntas que fazemos quando assumimos um sistema que outra empresa construiu.

Use a matriz em uma reunião curta, com alguém da operação, alguém de TI e quem aprova o investimento. O primeiro grupo vem antes de tudo: sem acesso ao código e ao banco, nenhuma das duas opções pode ser avaliada a sério, e conseguir esse acesso costuma ser a primeira tarefa.

Se a maior parte das marcas cair no segundo grupo, o caminho é modernizar por partes. Se cair no terceiro, vale estimar a reescrita, de preferência ainda em etapas. Quando as marcas se dividem, o mais comum é modernizar a base e reconstruir só o módulo que não tem conserto.

A matriz organiza a conversa, e a avaliação técnica confirma a escolha. Na nossa sustentação e modernização, essa avaliação lê o código, confere a infraestrutura e lista os riscos por prioridade. Com a lista em mãos, a empresa decide o que corrigir primeiro.

Como modernizar por partes sem parar a operação?

Modernizar por partes significa colocar um ponto de corte entre os usuários e o sistema antigo e, a partir dele, passar um módulo de cada vez para o código novo, até que o antigo possa ser desligado. A Microsoft descreve esse caminho no padrão Strangler Fig: uma fachada recebe as requisições e decide se cada uma vai para o sistema antigo ou para o novo, e o novo assume mais funções a cada etapa.

Na prática, o roteiro que seguimos tem sete passos:

1. Garanta acesso e backup. Código, banco, servidor e domínio ficam em nome da empresa, e um backup é restaurado num ambiente de teste para provar que funciona.
2. Coloque o sistema em observação. Monitoramento de erros e de disponibilidade mostra o que quebra de verdade, antes de qualquer mudança.
3. Atualize a base. Versões da linguagem, do framework e do banco que estão fora de suporte sobem primeiro, em passos pequenos e testados.
4. Escolha o primeiro módulo. Prefira um que dói na operação e que tenha fronteira clara, como agendamento, portaria ou relatórios.
5. Reconstrua o módulo ao lado do antigo. O módulo novo lê e grava nos mesmos dados, ou numa base própria sincronizada, enquanto a equipe confere os resultados.
6. Vire o módulo com caminho de volta. Os usuários passam para o módulo novo, e o antigo fica disponível por um período combinado.
7. Desligue o antigo e siga para o próximo. Só remova tabelas e telas antigas depois que o módulo novo foi validado em uso real.

Quando o sistema novo precisa conversar com partes do antigo que ainda não foram trocadas, entra uma camada de tradução. A Microsoft chama isso de camada anticorrupção: um adaptador que traduz os dados e as chamadas entre os dois sistemas, para que o código novo não herde os vícios do modelo antigo.

O caso de transporte marítimo de passageiros mostra um exemplo desse tipo de evolução. O sistema de agendamento de embarques começou atendendo um único operador de lanchas. Com a operação consolidada, começamos a redesenhá-lo como plataforma para vários operadores, com dados isolados por operador, bilhete com QR code e trilha de auditoria. O conceito central do sistema mudou: deixou de ser o usuário que cadastrou e passou a ser o operador, o fornecedor e a viagem.

E se ninguém tem o código, a documentação ou quem fez o sistema?

Sem código nem documentação, a modernização começa pelos dados e pelo uso real: o que está no banco, quais telas a equipe usa e quais relatórios saem do sistema. É mais lento, mas é o caso mais comum quando o fornecedor original saiu de cena.

Algumas situações mudam o roteiro:

1. O código existe, mas ninguém sabe onde está. Procure no servidor de hospedagem, nos contratos antigos e com o antigo fornecedor. Muitas vezes o código está no próprio servidor em produção.
2. Só existe o banco de dados. O banco revela as entidades e boa parte das regras. Com ele lido e documentado, o sistema novo pode ser construído por módulos, consumindo os mesmos dados.
3. O sistema é um programa fechado de terceiros. A Microsoft aponta que o padrão de fachada não serve quando não há acesso ao código nem outro ponto de integração. Nesse caso, a saída costuma ser construir em volta, lendo os dados que o programa exporta, e trocar por etapas de processo.
4. O sistema é uma planilha com macros. Trate cada aba como um módulo. As fórmulas são as regras de negócio e precisam ser escritas em linguagem comum antes de qualquer código.
5. A equipe resiste à troca. Comece pelo módulo de que ela mais reclama. Quando a primeira troca resolve um incômodo real, a resistência às próximas cai.

Uma revisão de segurança ajuda nessas situações, porque obriga a ler o sistema rota por rota. Na plataforma de operação portuária que mantemos, montamos uma matriz de rota, ação e perfil e corrigimos ações que a tela escondia mas o servidor aceitava. Esse tipo de leitura também mostra onde estão as regras que ninguém documentou.

Quando reescrever é a melhor saída?

Reescrever é a melhor saída quando o sistema é pequeno, quando não há código nem dados aproveitáveis ou quando a operação mudou tanto que o sistema atual responde a perguntas que ninguém faz mais. Nesses casos, modernizar por partes gasta esforço preservando o que vai ser descartado.

Mesmo assim, a reescrita pode ser feita em etapas. Em vez de construir tudo e virar num dia, o sistema novo entra em produção com um processo completo, e os outros processos migram depois. A plataforma de operação portuária cresceu assim: começou pelos processos de segurança e foi ganhando módulos conforme a operação pedia, todos usando o mesmo cadastro de pessoas, empresas e locais. Hoje o banco tem mais de 160 tabelas, e o sistema segue em evolução contínua desde 2019.

Há também o que nenhuma das duas opções resolve sozinha. Se o processo é confuso no papel, ele vai continuar confuso no sistema novo. Fowler lembra que, sem mudança na forma de trabalhar, o sistema novo tende a acabar na mesma bagunça do antigo. Por isso, antes de discutir tecnologia, vale escrever o processo como ele deveria funcionar.

Se você quer entender como é um projeto desse tipo do começo ao fim, o artigo sobre projeto de software sob medida descreve cada etapa e o que o cliente decide em cada uma.

Quando isso não basta?

Este artigo ajuda a escolher o caminho, mas não substitui a leitura do código, dos dados e da infraestrutura. Duas empresas com o mesmo sintoma podem precisar de respostas opostas. Envolva alguém de fora quando a equipe interna não tem tempo para a avaliação, quando ninguém na empresa conhece a tecnologia do sistema ou quando o sistema guarda dados pessoais e a troca precisa respeitar a LGPD.

A boosting.tech é uma empresa de software customizado que assume sistemas existentes, inclusive os feitos por outras empresas, e moderniza por etapas sem parar a operação. Podemos olhar o seu sistema numa conversa de diagnóstico, sem custo, pela página de contato ou pelo e-mail jcm@boosting.tech. Os detalhes estão em sustentação e modernização, e, quando a saída é reconstruir, o trabalho segue como um projeto de sistema web sob medida.