Quando trocar o sistema legado (e quando não)

Trocar um sistema legado é a decisão mais cara que uma operação toma sem conta nenhuma na mão. Ela costuma nascer de irritação acumulada, não de análise, e por isso os dois erros opostos são igualmente comuns: trocar o que ainda servia por mais cinco anos, e sustentar por mais cinco anos o que já custa mais parado do que custaria substituir.

Este texto oferece um critério. Ele separa os sinais que de fato justificam a substituição dos que apenas incomodam, mostra as quatro saídas possíveis além de trocar tudo, e descreve a conta que torna a decisão defensável na frente de quem aprova o orçamento.

O que torna um sistema legado

Legado não é sinônimo de velho. Sistema antigo que atende bem, tem quem o mantenha e não impede nada é apenas sistema estável, e trocá-lo é destruir valor. O que caracteriza legado é outra coisa: o sistema virou um limite ao que a empresa quer fazer, e não apenas uma ferramenta menos moderna que as novas. O recorte conceitual está em sistemas legados.

Essa distinção é prática. Ela move a conversa de estética para consequência, e é o que permite responder a pergunta seguinte: o que exatamente esta empresa não consegue fazer por causa deste sistema. Se a resposta demora a aparecer, provavelmente ainda não é hora.

Os cinco sinais que justificam a troca

1. O sistema impede uma decisão de negócio. Abrir um canal de venda, atender outro segmento, cobrar de outra forma. Quando a limitação técnica vira limitação comercial, a conta muda de natureza: o custo não é o da manutenção, é o da oportunidade que não acontece.
2. Não há mais quem o mantenha. Uma pessoa só entende, o fornecedor encerrou o suporte, a tecnologia não forma gente nova. Risco de continuidade é o sinal mais subestimado, porque só cobra na hora errada.
3. Ele não se integra. Sem API, sem exportação confiável, sem forma de conversar com o resto. Isso condena a empresa a digitar duas vezes e a decidir com dado defasado. Antes de concluir pela troca, vale checar o que se resolve com integração de sistemas, que custa uma fração.
4. Cada mudança pequena custa caro e demora. Quando alterar um campo leva semanas, a empresa para de pedir mudanças, e o processo se molda ao sistema em vez do contrário. Esse é o custo mais silencioso de todos.
5. Existe risco regulatório ou de segurança sem correção possível. Versão sem atualização de segurança, dado sensível sem controle de acesso, exigência legal que o sistema não atende. Aqui a decisão deixa de ser econômica.

Um sinal isolado raramente basta. Dois ou mais aparecendo juntos, e pelo menos um deles ligado a negócio e não a conforto, é o ponto em que a análise se paga.

Quando não trocar

Vale dizer com clareza, porque quase nenhum material sobre o assunto diz: manter costuma ser a decisão certa com mais frequência do que se imagina.

• Quando a queixa é de interface. Tela feia com processo correto é problema de treinamento e de atalho, não de arquitetura.
• Quando o processo por trás está quebrado. Trocar o sistema sem arrumar o processo entrega o mesmo caos em tela nova, e agora com custo de migração. O trabalho anterior está em automação de processos empresariais.
• Quando não existe gente para conduzir a migração. Substituição exige alguém de dentro decidindo regra de negócio em tempo integral por meses. Sem essa pessoa, o projeto atrasa por motivo que nenhum fornecedor resolve.
• Quando a empresa vai mudar de forma nos próximos doze meses. Fusão, novo sócio, mudança de modelo. Migrar antes de saber o formato final é migrar duas vezes.

As quatro saídas além da substituição

Trocar tudo é a opção mais cara e mais arriscada, e costuma ser a primeira considerada. Há quatro caminhos intermediários, em ordem crescente de investimento:

• Encapsular. Deixar o sistema como está e construir uma camada de integração em volta dele, para que o resto da empresa converse com essa camada. Resolve o problema de isolamento sem tocar no miolo.
• Extrair um pedaço. Tirar do legado apenas o módulo que dói, um de cada vez, e ligar de volta. Reduz o risco de parada total e permite parar no meio se o valor já tiver aparecido.
• Automatizar em volta. Quando o sistema é intocável, robôs de interface e rotinas de exportação resolvem a digitação dupla por um custo baixo. É paliativo declarado, com prazo de validade, e o recorte está em RPA e automação de processos.
• Substituir por pronto. Quando o processo não é diferencial competitivo, comprar software de mercado costuma ganhar de construir. A pergunta de quando cada caminho compensa está em software sob medida.

A conta que sustenta a decisão

A comparação honesta não é entre o preço do sistema novo e zero. É entre dois cenários completos em três anos.

Cenário manter: licença e suporte atuais, horas de manutenção por ano, horas gastas em retrabalho e digitação dupla, custo do risco de indisponibilidade e o que a empresa deixa de fazer por limitação do sistema. As duas últimas linhas são as que quase nunca entram, e são as maiores.

Cenário trocar: licença ou construção, implantação, migração de dados, integração com o que fica, treinamento, queda de produtividade nos primeiros meses e manutenção do novo. A queda de produtividade é real e dura mais do que a estimativa do fornecedor.

Colocar as duas colunas lado a lado costuma resolver a discussão sem retórica. O método para levantar a primeira coluna, que é a mais difícil, está em o custo dos processos manuais.

O risco que ninguém coloca na planilha

O sistema legado guarda regra de negócio que não está escrita em lugar nenhum. Vinte anos de exceção, ajuste e caso particular viraram código, e boa parte disso ninguém lembra que existe.

Esse é o motivo pelo qual migrações estouram prazo com tanta regularidade: a descoberta das regras acontece durante o projeto, não antes, e cada uma delas é uma decisão que precisa de alguém do negócio para ser tomada. A mitigação é conhecida e pouco praticada, que é mapear o processo real antes de escrever qualquer especificação, e tratar o sistema atual como documentação a ser lida, não como caixa a ser substituída.

Por onde começar

1. Nomeie a limitação de negócio. Uma frase: o que a empresa não consegue fazer por causa deste sistema. Se não houver, pare aqui.
2. Meça o custo de manter por um trimestre. Horas de manutenção, de retrabalho e de indisponibilidade, contadas e não estimadas.
3. Teste as saídas intermediárias primeiro. Encapsular ou extrair um módulo resolve parte dos casos por uma fração do custo.
4. Se for trocar, comece pelo pedaço de menor risco. Substituição de uma vez só é a forma de garantir que todos os problemas apareçam no mesmo dia.

O que decide a migração de dados

Quando a troca é mesmo o caminho, a migração de dados é a etapa que mais frequentemente derruba o cronograma, e ela é subestimada por um motivo específico: parece transporte e é tradução.

O dado do sistema antigo carrega o formato das decisões antigas. Campos usados para uma coisa e reaproveitados para outra, cadastro duplicado que a operação aprendeu a conviver, status que significa coisas diferentes conforme a época. Nada disso aparece na contagem de registros, e cada caso é uma decisão de negócio a ser tomada por alguém de dentro.

Três medidas reduzem o estrago. Migre menos: histórico completo raramente é necessário, e manter o sistema antigo em modo consulta por um ano costuma custar menos que migrar dez anos de dado sujo. Migre cedo: um ensaio com dado real no terceiro mês revela os problemas enquanto ainda há prazo. Defina quem decide: cada regra ambígua precisa de uma pessoa com autoridade para escolher, disponível na semana, e não de um comitê.

Por onde seguir

Se a conclusão foi manter e melhorar em volta, o caminho passa por o que é automação de processos e por integração de sistemas, que costumam resolver o sintoma pelo qual a troca foi cogitada. Se a conclusão foi construir, o recorte é software sob medida, e o trabalho de definir o que entra na primeira versão está em definir o escopo de um produto digital. E se a decisão precisa de um parecer de fora antes de virar orçamento, é o serviço descrito em consultoria de tecnologia.

Perguntas frequentes