A resposta curta
Para modernizar um sistema legado sem parar a operação, troque por partes: avalie o código e os dados, escolha a estratégia certa para cada módulo e substitua um pedaço de cada vez, com o sistema antigo funcionando em paralelo até a parte nova ser validada. Reescrever tudo de uma vez é o caminho mais arriscado.
Nem todo sistema antigo precisa sair. Legado é o sistema de que a operação depende e que ficou difícil de mudar, não necessariamente o mais velho. Às vezes basta integrá-lo ao resto e cuidar da segurança; às vezes o certo é substituir por uma ferramenta de mercado. A decisão sai de uma avaliação técnica, não da idade do código.
Sinais de que o sistema legado virou risco
Um sistema antigo que funciona não é problema por si só. Ele vira risco quando a operação passa a depender dele mais do que ele aguenta. Os sinais mais comuns:
- Só uma pessoa sabe mexer. O conhecimento está na cabeça de quem construiu ou de quem mantém há anos, sem documentação. Se essa pessoa sai, a operação fica refém.
- Cada mudança pequena demora e quebra outra coisa. Sem testes automatizados, ninguém tem segurança para alterar, e a equipe passa a evitar mexer.
- A tecnologia saiu de suporte. Linguagem, banco de dados ou sistema operacional sem atualizações de segurança deixam falhas conhecidas abertas.
- Ele não conversa com os outros sistemas. Sem API, os dados viajam por planilha, exportação manual ou redigitação.
- Não atende às exigências atuais. Controle de acesso por perfil, registro de quem fez o quê e as regras da LGPD sobre dados pessoais ficaram de fora do desenho original.
- A equipe criou um sistema paralelo em volta dele. Planilhas e controles por fora suprem o que o legado não faz, e a fonte de verdade deixa de ser clara.
Um sinal isolado pede atenção. Vários ao mesmo tempo indicam que o custo de manter o sistema como está já supera o de modernizar, mesmo que esse custo não apareça em nenhuma fatura.
O sistema que virou gargalo nem sempre é antigo. No sistema de gestão de pacientes que desenvolvemos para uma unidade de pronto atendimento, o ponto de partida foi um sistema de mercado que não acompanhava a operação: a integração com o Cartão Nacional de Saúde falhava e os relatórios para a prefeitura viravam planilha.
As quatro estratégias de modernização, lado a lado
Modernizar não é sinônimo de reescrever. Há pelo menos quatro caminhos, e um mesmo sistema pode combinar mais de um, módulo a módulo.
| Estratégia | Quando faz sentido | O que você ganha | Principal risco |
|---|---|---|---|
| Manter e integrar | O sistema funciona e é estável, mas vive isolado. | Os dados passam a circular por API, sem redigitação. Veja como integrar sistemas. | A dívida técnica continua lá, e a integração depende do que o legado permite expor. |
| Refatorar por partes | O núcleo tem valor, mas partes estão frágeis ou desatualizadas. | Melhora contínua, sem troca brusca e com a equipe acostumada ao sistema. | Sem testes e disciplina, a refatoração vira mais uma camada de remendo. |
| Reescrever | A tecnologia não tem mais saída e o processo mudou muito desde o desenho original. | Arquitetura atual, segurança e um sistema que acompanha a operação de hoje. | O maior de todos, se for feito de uma vez: regras escondidas no código antigo se perdem. |
| Substituir por software pronto | O processo é padrão no setor e uma ferramenta de mercado já cobre a rotina. | Rapidez e manutenção por conta do fornecedor. Compare em software pronto ou sob medida. | Adaptar o processo à ferramenta e depender do roteiro e do preço do fornecedor. |
Reescrever não precisa ser tudo ou nada. A forma mais segura é reescrever por partes: um módulo novo entra, assume uma função do antigo e, depois de validado, o antigo deixa de fazer aquela parte. Na engenharia de software esse padrão é conhecido como strangler fig, em referência à figueira que cresce em volta de uma árvore até tomar o lugar dela.
Como migrar os dados sem parar a operação
Os dados são a parte mais delicada da modernização. O código pode ser refeito; o histórico de anos de operação, não. Uma migração segura costuma seguir estes passos:
- Inventariar o que existe. Tabelas, arquivos, campos usados de fato e campos que ninguém preenche. Bases antigas costumam ter duplicidades e regras implícitas.
- Mapear o antigo para o novo. Cada campo ganha destino, formato e regra de conversão, revisados com quem conhece a operação.
- Limpar antes de mover. Duplicidades e registros incompletos são resolvidos na origem ou na conversão, com critério combinado.
- Ensaiar a migração. Rodar a carga completa num ambiente de homologação quantas vezes for preciso e comparar totais e amostras com o sistema antigo.
- Migrar por módulo ou por período. Em vez de uma virada única, a carga acontece em etapas, e cada etapa tem um plano de volta.
- Conferir depois da virada. Relatórios do sistema novo são comparados com os do antigo até os números baterem.
Quando há dados pessoais, a migração também é tratamento de dados para a LGPD. Vale aproveitar para revisar o que é guardado, por quanto tempo e quem acessa, em vez de só copiar tudo para o lugar novo.
Como o sistema antigo e o novo convivem durante a troca
Na troca por partes, por um tempo os dois sistemas funcionam juntos. Essa convivência precisa de regras claras, ou a equipe passa a não saber onde registrar cada coisa.
A primeira regra é ter uma única fonte de verdade para cada dado em cada momento. Se o cadastro de clientes já migrou, ele é feito só no sistema novo, e o antigo recebe uma cópia por integração enquanto ainda precisar dela. A segunda é que a mudança chegue para a equipe com treinamento e prazo, módulo a módulo, e não como uma troca de tela numa segunda-feira.
É assim que conduzimos esse tipo de projeto: substituímos o sistema por partes, um módulo de cada vez, com o antigo funcionando em paralelo até a nova parte ser validada. Cada módulo novo passa por demonstração e teste em homologação antes de entrar em uso, como descrevemos em como trabalhamos.
Os riscos da modernização e como reduzir cada um
Todo projeto de modernização tem riscos conhecidos. O que muda o resultado é tratá-los desde o começo, e não quando aparecem.
- Perder regras de negócio escondidas. Sistemas antigos guardam exceções que ninguém lembra. Reduz-se lendo o código, conversando com quem opera e escrevendo testes que comparam o comportamento antigo com o novo.
- Parar a operação na virada. Reduz-se com troca por partes, convivência planejada e plano de volta para cada etapa.
- Escopo que não para de crescer. Modernizar dá vontade de mudar tudo. Separar o que é reproduzir o que existe do que é melhoria nova mantém o projeto sob controle.
- Resistência da equipe. Quem usa o sistema há anos precisa participar do desenho e testar antes. A participação de quem opera é o que mais reduz retrabalho.
- Trocar uma dependência por outra. Código versionado, documentação e propriedade definida em contrato evitam que o sistema novo vire o próximo legado nas mãos de uma só pessoa. Mais em de quem é o código do software sob medida.
Por onde começar: a avaliação técnica do sistema atual
O primeiro passo não é escolher a tecnologia nova, é entender a que existe. Uma avaliação técnica do código, da infraestrutura e da documentação mostra o que pode ficar como está, o que precisa de correção e quais são os riscos. Com ela, a estratégia de cada módulo deixa de ser palpite.
Também assumimos a manutenção de sistemas que não foram feitos por nós, sempre depois dessa avaliação. Às vezes a conclusão é estabilizar e integrar; às vezes é planejar a troca por partes. Em desenvolvimento de software sob medida você encontra como esse trabalho se organiza, do estudo ao suporte em produção.