Migrar sistema legado sem parar a empresa: como fazer

O sistema foi feito há dez, quinze anos. Em PHP antigo, em Delphi, numa base do Access que alguém montou e foi crescendo. Ele ainda roda a empresa: faturamento, estoque, cadastro de clientes. Mas só uma pessoa sabe mexer nele, não abre no celular, não conversa com o WhatsApp nem com o gateway de pagamento. E cada mudança pequena vira um projeto.

Você não está sozinho. Em outubro de 2025, a Pega publicou uma pesquisa com mais de 500 gestores de TI de empresas de vários países. 78% concordam que o tempo e o dinheiro gastos mantendo sistemas antigos teriam uso melhor em outra coisa. E só 9% disseram ter chegado ao ponto de aposentar todos eles. Migrar é difícil para todo mundo. A diferença está em como a troca é feita.

Quando o sistema legado vira risco

Sistema antigo não é problema por ser antigo. É problema quando começa a custar caro ou a ameaçar a operação. Os sinais mais comuns:

• Só uma pessoa sabe mexer. Se ela sai, adoece ou some, a empresa para.
• A tecnologia não recebe mais correção de segurança. Falha descoberta amanhã não vai ter conserto oficial.
• Toda integração é gambiarra. Planilha exportada à mão, robô copiando tela, digitação dupla.
• Não roda fora do escritório. Sem acesso pelo celular nem pelo navegador.
• Cada mudança demora semanas. E sempre quebra alguma coisa em outro canto.

O segundo item tem data marcada para muita gente. Segundo a tabela oficial do PHP, a versão 8.2 deixa de receber correções de segurança em 31 de dezembro de 2026. As versões 8.1 e anteriores já nem aparecem na lista de versões com suporte. Se o seu sistema roda numa delas, ele já está exposto ou vai estar em menos de três meses.

O custo de esperar também é medido. O relatório de 2022 do CISQ, consórcio de qualidade de software, estimou em US$ 1,52 trilhão a dívida técnica acumulada nos Estados Unidos, e a chamou de maior obstáculo para mudar sistemas que já existem. Na sua empresa, ela aparece como o pedido simples que nunca sai.

Por que reescrever tudo de uma vez costuma dar errado

A tentação é óbvia: contratar um sistema novo do zero, desenvolver por meses e, num fim de semana, desligar o velho e ligar o novo. Parece limpo. Na prática, é o caminho que mais falha.

O motivo é que o sistema antigo guarda regras que ninguém escreveu em lugar nenhum. O desconto que vale só para um tipo de cliente. O cálculo de imposto ajustado depois de uma autuação. A exceção criada para um fornecedor em 2017. Tudo isso está no código, não na cabeça de quem pede o sistema novo. Na reescrita, essas regras somem, e a empresa só descobre quando a nota sai errada.

Em 2000, Joel Spolsky, um dos fundadores do Stack Overflow, escreveu um texto que ainda é referência sobre isso. Ele contou o caso do Netscape, que decidiu reescrever o navegador do zero e ficou quase três anos sem lançar versão nova enquanto perdia mercado. Martin Fowler, autor de livros clássicos sobre arquitetura de software, diz que já viu o plano de trocar tudo de uma vez “dar errado na maioria das vezes”.

A pesquisa da Pega aponta na mesma direção. A maior fatia do custo da dívida técnica não estava em manter o sistema velho. Estava no tempo que os projetos de modernização levavam para terminar, e outra parte relevante vinha de projetos que fracassaram por causa dos sistemas antigos.

Como migrar por partes

A alternativa tem nome no mercado: estrangulamento, inspirado na figueira-mata-pau, que cresce em volta de uma árvore até ficar de pé sozinha. Fowler descreve o método assim: o sistema novo nasce ao lado do antigo e vai assumindo uma função de cada vez. Quando a última parte passa, o antigo é desligado sem drama.

Na prática, a migração segue uma ordem:

1. Inventário. Listar o que o sistema faz, quem usa cada parte, com o que ele conversa e onde estão os dados. Inclui as regras escondidas no código.
2. Dados primeiro. Decidir o que vai para a base nova, em que formato, e como conferir. Dado sujo migrado continua sujo.
3. Escolher o primeiro módulo. De preferência um que doa no dia a dia e tenha poucas dependências. Pedido de venda, agenda ou cadastro costumam ser bons candidatos.
4. Rodar em paralelo. O módulo novo funciona ao lado do antigo por um período. Os números dos dois são comparados até baterem.
5. Virar a chave daquele módulo. Só dele. O resto da empresa segue no sistema antigo.
6. Repetir. Módulo por módulo, até o antigo não ter mais função. Aí ele é desligado.

O ganho é que cada etapa entrega valor sozinha. Se o orçamento apertar no meio do caminho, o que já foi migrado está no ar e funcionando. Ninguém fica meses pagando por algo que ainda não existe.

Os cuidados que evitam surpresa

Alguns pontos decidem se a migração termina bem:

• Acessos em nome da empresa. Servidor, banco de dados, domínio e código precisam estar sob controle da empresa antes de começar. É o mesmo primeiro passo de quem tenta retomar um projeto de software atrasado.
• Backup testado. Não basta existir. Alguém precisa restaurar uma cópia e ver se ela abre.
• Quem usa participa. A pessoa do financeiro sabe qual relatório não pode faltar no fechamento do mês. Ela precisa testar antes da virada.
• Critério de pronto escrito. Cada módulo tem uma lista do que precisa funcionar e de quais números precisam bater.
• Custo de manter os dois. Durante a migração, a empresa paga o sistema velho e o novo. Isso entra no planejamento desde o início, junto com o que vai custar manter o sistema novo no ar depois.

Como fazemos no Studio

Nosso trabalho de resgate começa pelo diagnóstico. Lemos o código e os dados do sistema antigo, listamos as regras que ele guarda e desenhamos a ordem da troca. Só depois disso sai o preço fechado, com prazo escrito no contrato. Código, arquivos e acessos do sistema novo ficam em nome do cliente, e a equipe de devs é do próprio Studio.

Juntar e trocar sistemas que já rodam a operação é um trabalho que já fizemos. Na LCX, empresa de turismo com operação em mais de 10 países da América do Sul, havia um sistema por país. Eles viraram um sistema só, no ar em 29 dias.

Todo sistema que entregamos sai com um agente de IA que roda todo dia, aponta falhas, sugere melhorias e confere se os dados fazem sentido. Numa migração, isso pesa: é ele que avisa quando um número do sistema novo não bate com o esperado.

Se a sua empresa depende de um sistema que ninguém mais consegue manter, o resgate de projeto do Studio começa pelo diagnóstico do que existe e entrega a migração por partes, sem parar a operação.