Migração de sistemas legados, sem parar a operação.

Você reconhece o sistema pelos sintomas

Ele funciona. É esse o problema. Ele funciona bem o suficiente para ninguém poder desligar, e mal o suficiente para atrapalhar tudo que a empresa quer fazer daqui pra frente.

• Uma mudança simples leva semanas, e ninguém consegue estimar com confiança.
• Só uma ou duas pessoas entendem partes críticas — e uma delas está de saída.
• Não existe ambiente de teste confiável, então todo ajuste é feito com medo.
• Integrar com qualquer coisa nova exige gambiarra, exportação de arquivo ou acesso direto ao banco.
• A tecnologia saiu de suporte, e contratar quem sabe mexer virou caro ou impossível.
• Falar em IA sobre esses dados é conversa fora de alcance, porque nada é acessível por API.

O custo de manter esse sistema não aparece na planilha como uma linha. Ele aparece como lentidão em tudo — nas oportunidades que a empresa não persegue porque "o sistema não deixa".

Por que reescrever do zero quase sempre dá errado

O impulso natural é começar de novo. Sistema novo, tecnologia atual, sem o peso do passado. É o projeto que mais falha em software corporativo, e as razões são estruturais, não de execução.

Uma reescrita total exige que o time reproduza anos de regras não documentadas antes de entregar qualquer valor. Enquanto isso, o sistema antigo continua vivo e continua mudando — então o alvo se move. O projeto passa meses sem nada visível, a confiança da diretoria cai, o escopo cresce para justificar o tempo já gasto, e tudo termina em uma virada única que concentra todo o risco numa madrugada.

A abordagem: estrangulamento incremental

O sistema novo cresce em volta do antigo, assumindo uma responsabilidade por vez. Uma camada de roteamento decide, para cada operação, se ela vai para o legado ou para o novo. Quando uma funcionalidade migra, o roteamento passa a direcioná-la para o novo — e pode voltar atrás em minutos se algo der errado.

Repetindo isso, o legado vai perdendo responsabilidades até ficar vazio e poder ser desligado sem cerimônia. Não existe grande virada. Existe uma sequência de mudanças pequenas e reversíveis.

1. Auditoria e mapeamento. Levantamos o que o sistema faz de fato: telas em uso, fluxos críticos, integrações, estrutura e qualidade dos dados, e o que já está morto.
2. Resgate das regras de negócio. Extraímos e documentamos as regras que estão enterradas no código e no banco — o entregável mais valioso do projeto, e o único que continua valendo mesmo se a tecnologia escolhida mudar depois.
3. Fronteira e roteamento. Colocamos uma camada na frente do legado. A partir daqui, cada migração é uma troca de rota, não um transplante.
4. Migração por fatia. Escolhemos a fatia com melhor relação entre valor e risco, reconstruímos e rodamos em paralelo, comparando resultados antes de virar a rota.
5. Dados. Migração e saneamento com verificação de integridade, e período de escrita dupla quando o risco justifica.
6. Desligamento. Só depois que nada mais depende dele — com dados históricos preservados e acessíveis.

Os legados que mais aparecem — e a saída de cada um

"Sistema legado" é um rótulo largo demais para ser útil. Na prática, quase todo caso que chega até nós cai em uma destas famílias, e cada uma tem um caminho de saída diferente.

Delphi, Visual Basic 6 e Clipper

A dupla mais comum no mercado brasileiro. São sistemas desktop que funcionam há quinze ou vinte anos, costumam falar direto com o banco de dados e concentram a regra de negócio dentro dos eventos de tela — o cálculo do imposto mora no clique do botão.

O primeiro passo aqui nunca é a tela: é extrair a regra da interface para um serviço com API. Feito isso, o sistema antigo passa a chamar esse serviço e continua rodando, enquanto a nova interface — web ou aplicativo — nasce sobre a mesma regra. Duas frentes, uma só verdade, e a virada deixa de ser um evento de risco.

Access, planilhas e sistemas que viraram sistema sem querer

Começaram como controle de uma pessoa e acabaram sustentando um setor. Não têm controle de acesso real, quebram quando duas pessoas usam ao mesmo tempo e vivem em um arquivo que alguém precisa lembrar de copiar.

São, ao mesmo tempo, os casos mais frágeis e os mais rápidos de resolver. O trabalho é entender o que a planilha realmente decide, migrar os dados para um banco de verdade e reconstruir a operação como sistema web multiusuário. Costuma caber em semanas, não em trimestres.

ASP clássico, PHP antigo e web da geração passada

Sistemas web que já foram modernos e hoje rodam em versões sem suporte — o que deixou de ser só incômodo técnico e virou exposição de segurança, porque correção de vulnerabilidade não sai mais.

Aqui o estrangulamento funciona quase sem atrito: como a interação já é por URL, dá para colocar um roteador na frente e mover uma tela por vez para a aplicação nova, sem que o usuário perceba a fronteira. É o cenário em que a migração incremental rende mais rápido.

Mainframe, AS/400 e COBOL

O caso mais delicado, e aquele em que reescrever é a pior ideia possível. São sistemas estáveis, com décadas de regra fiscal e contábil dentro, cujo problema real não é o desempenho: é que quase ninguém novo aprende a mantê-los, e o custo de licenciamento não para de subir.

A estratégia que funciona é abrir o legado por API antes de tocar nele. Expostas as operações principais, tudo que é novo — portal, aplicativo, integração, análise — passa a ser construído fora, e o núcleo antigo vai sendo reduzido no ritmo que o risco permite.

Banco de dados e a migração que ninguém vê

Boa parte do risco de uma modernização não está na aplicação: está nos dados. Chaves duplicadas, campo de texto guardando três informações, data em formato inconsistente, registro órfão, o cliente cadastrado quatro vezes com grafias diferentes.

Por isso a migração de dados entra cedo no projeto e roda em ensaio quantas vezes for preciso, com conferência automática entre origem e destino. Descobrir sujeira na véspera da virada é o que transforma um plano bom em uma madrugada ruim.

IA como ferramenta de modernização

Ler dezenas de milhares de linhas de código antigo, em uma linguagem que poucos dominam, era o gargalo caro dessa etapa. Modelos de linguagem mudaram essa conta: hoje é viável mapear dependências, descrever o que cada rotina faz, encontrar regras duplicadas e gerar uma primeira documentação em uma fração do tempo.

Isso não substitui o julgamento. A saída da IA é uma hipótese que precisa ser validada contra o comportamento real do sistema e contra quem opera o processo. Mas transforma uma arqueologia de meses em semanas — e é uma das razões pelas quais a NasteSoft consegue tratar legado com prazo realista.

Terminada a migração, o mesmo trabalho abre a porta do outro lado: com o sistema exposto por APIs e dados acessíveis, o que era impossível vira projeto normal. É aqui que a frente de software com IA continua.

O que fica com você no final

• Sistema modernizado, entregue por partes e validado em produção a cada etapa.
• Regras de negócio documentadas — o ativo que a empresa não tinha antes.
• APIs que permitem integrar com o que vier depois, sem acesso direto ao banco.
• Testes automatizados sobre os fluxos críticos, para que a próxima mudança não dê medo.
• Dados migrados e sanados, com histórico preservado.
• Time capacitado para manter e evoluir sem depender de nós.

Perguntas frequentes