Migrar sistemas legados no setor público: o que ninguém avisa antes de começar

Em projetos de transformação digital, quando se olha para um sistema com 15 ou 20 anos, a reação quase automática é tratá-lo como um problema a resolver. Tecnologia obsoleta, código difícil de manter, interfaces que ninguém desenhou a pensar no utilizador, integrações feitas "à mão", documentação inexistente ou desatualizada. A tentação é olhar para aquilo e concluir que o caminho é substituir - desenhar de raiz, com arquitetura moderna, boas práticas, metodologias ágeis e tudo o que o projeto anterior não teve.

Só que essa leitura ignora uma coisa: o sistema antigo funciona. Funciona todos os dias, com milhares de utilizadores, em cenários que ninguém previu quando foi desenhado. Funciona com remendos, com exceções, com lógica que parece estranha até se perceber o contexto. E funciona porque alguém, muitas vezes uma equipa pequena com poucos recursos e sem o reconhecimento que merecia, foi resolvendo problemas reais ao longo de anos, mesmo sem seguir o fluxo "normal" de desenvolvimento.

Esta reflexão é sobre isso: sobre o risco de menosprezar o que o legado contém, sobre a diferença entre substituir e compreender, e sobre uma tensão que ainda não sei resolver completamente - a fronteira entre respeitar o que existe e saber quando é preciso cortar.

O reflexo de olhar para o legado como o problema

Quando se fala de sistemas legados no setor público, há um vocabulário que se instala rapidamente: dívida técnica, obsolescência, risco, dependência. Tudo verdade, em graus variáveis. Mas estes sistemas são também o repositório mais completo de regras de negócio que a organização tem.

Não estão documentadas em wikis, não estão em manuais de procedimentos, não estão em especificações funcionais - estão no código, nos dados, nas validações, nos fluxos de exceção. Cada if/else que parece arbitrário, cada campo que não faz sentido à primeira vista, cada regra de validação que contradiz o que está escrito no caderno de encargos original, tudo isso existe porque, a certa altura, alguém enfrentou um problema concreto e encontrou uma solução. Pode não ter sido a solução mais elegante. Pode não ter seguido as boas práticas. Mas resolveu o problema e o serviço continuou a funcionar.

Tratar isto como "lixo técnico" é perder informação. E perder informação no início de uma migração é o tipo de erro que só se descobre meses depois, quando o sistema novo já está em testes e alguém pergunta "mas porque é que este caso não funciona como antes?"

O sistema antigo sabe mais do que qualquer documento

Há um momento, em qualquer migração, que se repete sempre. A equipa nova analisa o sistema antigo, identifica os fluxos principais, mapeia os casos de uso mais comuns e avança para o desenho da solução. Semanas ou meses depois, durante os testes, começam a aparecer situações que ninguém previu, não porque sejam raras mas porque estavam codificadas em camadas do sistema que ninguém analisou com profundidade suficiente.

Isto não é negligência. É consequência de uma premissa errada: a ideia de que a documentação existente, somada a algumas sessões de levantamento de requisitos, é suficiente para capturar o que o sistema faz. Na prática, a documentação de um sistema com 15 ou 20 anos é ficção - ou, sendo mais justo, é uma fotografia desfocada de um momento que já não existe. O sistema evoluiu, a documentação não acompanhou e a distância entre o que está escrito e o que está em produção é maior do que alguém quer admitir.

A única documentação fiável é o código e os dados. E mesmo esses precisam de ser lidos com contexto, porque o código diz "o quê" mas raramente diz "o porquê". O porquê está na cabeça de quem escreveu aquele patch às três da manhã para resolver um problema que apareceu em produção e que precisava de estar resolvido antes do dia seguinte.

Isto cruza com algo que já escrevi na reflexão sobre exceções nos serviços públicos: muitas das regras mais importantes de um sistema não estão formalizadas, estão diluídas em registos pouco normalizados, em notas, em decisões pontuais, em conhecimento tácito. Foram mantidas por pessoas, não por documentação.

As pessoas que mantiveram o legado não são o obstáculo

Este é o ponto que mais me incomoda. Em muitos projetos de migração, as pessoas que mantiveram o sistema legado durante anos são tratadas como parte do problema. São vistas como resistentes à mudança, apegadas a processos antigos, incapazes de pensar "fora da caixa". A equipa nova chega com orçamento, com metodologia, com ferramentas modernas e, implicitamente, com a mensagem de que tudo o que foi feito antes não serve.

Isto é, no mínimo, ingrato. Mas é também um erro estratégico.

As pessoas que mantiveram o sistema são as únicas que sabem como ele realmente funciona - não como está documentado, não como devia funcionar segundo as especificações mas como funciona de facto. São elas que sabem que "aquele campo não se pode apagar porque há um relatório mensal que depende dele", que "aquela validação foi desligada em 2019 porque criava bloqueios num caso específico que aparecia duas vezes por ano mas que, quando aparecia, parava tudo", que "aquele fluxo tem um passo a mais porque a lei mudou em 2017 e nunca se refez o processo de raiz."

Se essas pessoas não forem ouvidas no início do processo, o sistema novo vai nascer sem capacidade de lidar com os casos que mais importam. E o pior é que, na maioria das vezes, ninguém se vai aperceber até ser tarde demais - até o sistema estar em produção e começarem a aparecer situações que "deviam funcionar" e não funcionam.

A equipa que constrói o sistema novo muitas vezes comete os mesmos erros que a equipa original cometeu. Não por incompetência, mas porque não percebeu por que é que certas decisões foram tomadas. Olha para uma regra de negócio no sistema antigo, decide que é desnecessária, remove-a. Meses depois aparece o caso de exceção que aquela regra cobria. Reimplementa-se, agora com mais pressa e menos contexto, e o resultado é uma solução pior do que a original.

Quando respeitar e quando cortar

Só que reconhecer o valor do legado não pode significar preservar tudo. Há coisas no sistema antigo que estão genuinamente mal - decisões tomadas sob pressão que nunca foram revistas, workarounds que resolveram o problema do momento mas que introduziram problemas piores a prazo, regras que já não fazem sentido porque a legislação mudou ou o contexto desapareceu.

A questão é: como é que se distingue? Como é que se olha para uma regra no sistema antigo e se decide "isto é conhecimento acumulado que devemos respeitar" versus "isto é peso morto que devemos cortar"?

Gostava de poder dizer que há sinais claros, que existe um método, uma checklist, uma forma sistemática de separar o que preservar do que eliminar. Não tenho essa resposta, o que tenho é uma intuição construída na tentativa e erro: quando alguém consegue explicar o porquê de uma regra, "isto existe porque em 2018 houve um caso em que...", normalmente vale a pena preservar, mesmo que a implementação precise de ser refeita. Quando ninguém sabe porquê mas "sempre foi assim", é sinal de que precisa de ser investigado antes de ser mantido ou cortado. E quando a justificação é "a lei obriga" mas ninguém consegue apontar o artigo, normalmente o que existe é uma interpretação defensiva que pode ou não estar correta.

Nada disto é linear. Há regras que parecem arbitrárias e que, quando se vai ao fundo, protegem casos críticos. E há regras que parecem fundamentais e que, quando se investiga, são heranças de um contexto que já não existe. A única coisa que sei com alguma confiança é que decidir sem investigar - seja para manter, seja para cortar - é quase sempre o caminho mais caro.

Já escrevi sobre isto a propósito da IA e do dilema de construir ou comprar: a velocidade sem compreensão não é eficiência. Se o que se está a construir parte de uma compreensão incompleta do que existia, a aceleração só produz erros mais depressa.

O "Big Bang" é quase sempre uma ilusão

Há uma ideia que persiste em muitos programas de migração: o "Big Bang". Define-se uma data, desliga-se o antigo, liga-se o novo.

No setor público, isto é quase sempre uma ilusão. Não só porque o serviço não pode parar - um registo comercial, o portal das finanças, uma plataforma de licenciamento não fecham para obras - mas porque a própria migração de dados revela problemas que ninguém antecipou. Dados inconsistentes, registos duplicados, campos que mudaram de significado ao longo do tempo, relações entre entidades que não estão documentadas. E cada uma dessas inconsistências é, na verdade, mais uma peça de informação sobre como o sistema foi usado na prática versus como foi desenhado na teoria.

A migração progressiva é mais difícil de gerir, mais difícil de explicar a quem financia e mais difícil de contratar mas permite aprender com os erros antes de estes afetarem todo o sistema. Cada módulo migrado é um teste real, com utilizadores reais e em condições reais. Isto exige paciência mas paciência é um recurso escasso em projetos/programas com prazos rígidos.

Respeitar não é preservar tudo

O que estou a dizer de forma simples é que antes de substituir um sistema, convém perceber o que ele resolveu. Não apenas o que ele faz atualmente nem para o manter como está mas para não reconstruir às cegas ou perder regras que custaram anos a descobrir. Para não tratar como incompetência aquilo que foi, muitas vezes, a melhor decisão possível dentro de constrangimentos que a equipa nova nunca vai sentir.

A fronteira entre respeitar e cortar provavelmente não tem uma fórmula - depende do contexto, das pessoas, da capacidade de investigar, do tempo disponível. O que sei é que errar para o lado de investigar demais custa semanas. Errar para o lado de ignorar custa meses e, mais importante, custa confiança, que no setor público é o recurso mais difícil de recuperar.

O sistema antigo pode ser lento, pode ser feio, pode estar numa tecnologia que ninguém quer manter. Mas antes de o substituir convém perceber o que ele resolveu. Porque o maior risco numa migração não é o sistema novo falhar, é perder o que o antigo sabia.