Modernização de sistema legado sem parar a operação

Modernizar sistema legado é substituir as partes que travam a operação sem derrubar o que ainda funciona. O caminho com menos risco é ir por fora, tirando uma função de cada vez do sistema antigo e colocando no novo, em vez de reescrever tudo e trocar num fim de semana. Reescrita completa é o formato que mais falha, porque o sistema antigo carrega anos de regra que ninguém documentou.

O problema não é o sistema ser velho

Sistema legado costuma ser chamado assim como ofensa, e isso atrapalha a decisão. Ele é velho porque funcionou por muito tempo, e continua rodando a operação todo dia.

O que dói é outra coisa, e vale nomear direito antes de propor qualquer reforma.

• As pessoas que sabiam como ele funciona saíram, e a regra de negócio vive no código sem estar escrita em lugar nenhum
• Não dá para integrar com nada, então cada dado novo vira exportação manual
• Uma mudança simples leva semanas, porque ninguém tem confiança de mexer
• O fornecedor encerrou o suporte, ou a versão não recebe mais correção de segurança
• A auditoria começou a pedir controle que o sistema não tem como dar

Por que a reescrita completa costuma falhar

É o caminho que parece mais limpo e é o que mais dá errado. O motivo é quase sempre o mesmo: o sistema antigo acumulou anos de exceção, e boa parte dessas exceções não está escrita em lugar nenhum.

Enquanto a reescrita acontece, a operação continua precisando de mudança no sistema velho, e aí existem dois sistemas para manter com o mesmo time. O prazo escorrega, o novo nasce sem as exceções que ninguém lembrou, e a virada é adiada até alguém desistir.

Quando a reescrita completa é mesmo o caminho, ela precisa ser uma decisão consciente, com o custo do período de dois sistemas orçado desde o começo.

Ir por fora, uma função de cada vez

A alternativa com menos risco é cercar o sistema antigo em vez de atacá-lo de frente. Coloca-se uma camada na frente dele, e cada função nova passa a ser atendida pelo sistema novo, enquanto o resto continua indo para o antigo.

Com o tempo o sistema velho vai ficando com menos responsabilidade, até sobrar pouco o suficiente para desligar sem susto. Nenhum fim de semana de virada, nenhum ponto em que tudo depende de dar certo de primeira.

• Uma camada de entrada decide o que vai para o sistema novo e o que continua no antigo
• A primeira função a sair é a que dói mais e depende menos das outras
• Cada função migrada roda em paralelo por um tempo, com os dois resultados comparados
• O dado continua único, para não existir duas verdades sobre o mesmo cliente
• O sistema antigo só é desligado quando não sobrou nada essencial nele

Quando envolver o sistema antigo numa API resolve

Em parte dos casos o sistema velho não precisa ser substituído. Precisa só parar de ser uma ilha.

Colocar uma interface de integração na frente dele resolve o sintoma mais comum, que é a exportação manual, e custa uma fração de qualquer reescrita. O sistema continua onde está, e o dado dele passa a alimentar o resto da operação.

Vale medir isso antes de qualquer projeto maior. Várias vezes o incômodo que motivou a conversa some aqui.

Como escolher o que fazer primeiro

A ordem certa quase nunca é a ordem técnica. É a ordem do que custa mais para a operação hoje.

A gente começa lendo o código e a infraestrutura que existem, e essa leitura termina com um documento dizendo o que dá para manter, o que precisa ser substituído e quanto custa cada caminho. Assumir sistema legado sem essa etapa é combinar preço para um trabalho que ninguém mediu.

Quando isto não é para você

Esta página não serve para quem quer um orçamento de modernização sem que alguém olhe o código e a infraestrutura antes. Também não serve para quem precisa que o sistema novo entre no ar numa data fechada sem período de convivência com o antigo: esse formato existe, mas o risco é grande e precisa ser uma decisão tomada com os olhos abertos.

Perguntas frequentes