Quanto custa e quanto tempo leva migrar um sistema legado

Por que "depende" não é desculpa

Na migração de sistemas legados, duas empresas podem ter sistemas parecidos por fora — um ERP em Delphi com umas duzentas telas, digamos — e custos de migração muito diferentes. Uma tem o código organizado, um banco limpo, poucas integrações e um programador que conhece cada rotina. A outra tem regra de negócio dentro dos eventos de botão, um banco com quinze anos de sujeira, integração com banco, transportadora e prefeitura, e ninguém que saiba explicar o cálculo de comissão.

Por isso não publicamos tabela de preços, e desconfiamos de quem publica. O que dá para fazer — e é mais útil — é mostrar o que move o custo de migração de sistema para cima ou para baixo, para que você saiba avaliar o seu caso e as propostas que receber.

Os fatores que definem custo e prazo

1. Tamanho — e, mais ainda, acoplamento

Número de telas, relatórios, rotinas e tabelas dá uma primeira ordem de grandeza. Mas o que realmente pesa é o acoplamento: o quanto a regra de negócio está misturada com a tela e com o acesso ao banco. Um sistema com regras centralizadas em poucas unidades se migra por partes com facilidade. Um sistema em que cada formulário faz tudo sozinho exige que cada regra seja descoberta e extraída antes de ser reescrita.

2. Qualidade dos dados

Dados limpos, com relacionamentos consistentes, se migram com scripts e conferência. Dados com duplicidades, registros órfãos, encoding quebrado e códigos mágicos exigem regras de limpeza acordadas com o negócio e vários ensaios de carga. É comum este ser o fator mais subestimado — detalhamos o porquê em migração de banco de dados legado sem perder dado.

3. Quantas integrações

Cada integração — com banco, fisco, transportadora, balança, e-commerce, outro sistema da casa — é um contrato que o sistema novo precisa respeitar e testar, muitas vezes com um terceiro do outro lado que tem a própria agenda. Integração por troca de arquivo em pasta compartilhada, comum em legado, costuma ter regras que só aparecem quando quebram.

4. Quem conhece o sistema

Se o programador original ainda está na empresa, ou se há usuários-chave que sabem por que cada coisa funciona como funciona, o entendimento é mais rápido. Se esse conhecimento saiu com as pessoas, ele precisa ser reconstruído lendo código, banco e comportamento — o que é possível, mas leva mais tempo.

5. Documentação existente

Documentação atualizada é rara, mas qualquer coisa ajuda: manuais de usuário, especificações antigas, chamados de suporte, planilhas de regras. Sem nada, o projeto começa por documentar o sistema legado — uma etapa que existe de qualquer forma no nosso método, mas cujo tamanho varia muito.

6. O destino escolhido

Levar um WinForms em .NET Framework para o .NET moderno, mantendo a interface desktop, é um esforço muito diferente de transformar um sistema Delphi desktop numa aplicação web com aplicativo móvel. Mudar o banco de dados ao mesmo tempo soma outro trabalho. E aproveitar a migração para mudar processos é legítimo, mas transforma parte dela em desenvolvimento novo, com o custo correspondente.

7. O nível de risco aceitável

Quanto o negócio tolera de parada, de diferença temporária, de convivência entre dois sistemas? Migrar sem parar a operação, com cada etapa reversível, exige trabalho de convivência — sincronização, roteamento, testes comparativos. Esse trabalho custa, e é o que compra segurança. Um sistema periférico aceita mais risco que o faturamento.

Por que orçamento fechado sem diagnóstico é chute

Repare que quase nenhum dos fatores acima aparece numa conversa de uma hora ou numa lista de telas. Acoplamento, qualidade dos dados e regras escondidas só aparecem quando alguém abre o código e o banco. Quem fecha um preço para o projeto inteiro antes disso está fazendo uma de três coisas:

• Cobrando o pior caso de todos, com uma margem que você paga mesmo que o seu sistema seja simples.
• Apostando no melhor caso e, quando a realidade aparecer, renegociando, cortando testes ou entregando menos do que o combinado.
• Planejando usar um conversor automático, que deixa o preço previsível porque não tenta entender o sistema — e devolve um legado novo numa linguagem nova. Explicamos isso em conversor automático de código legado funciona?

Nenhuma das três é boa para quem paga. Um orçamento de modernização de sistema só é útil quando se apoia no conhecimento do sistema real.

A estrutura que reduz o risco financeiro

O formato que usamos — e que recomendamos mesmo a quem for contratar outra empresa — tem duas fases.

Fase 1: diagnóstico curto, com escopo definido

Algumas semanas para entender o sistema: leitura do código e do banco, conversas com quem opera, inventário de integrações e de dependências. A IA ajuda a ler mais rápido — mapear dependências, descrever rotinas, rascunhar documentação —, mas a validação é feita por pessoas, com quem conhece o processo. O resultado fica com o cliente:

• Mapa do sistema: módulos, regras de negócio principais, integrações, dados.
• Riscos identificados e o que fazer com cada um.
• Opções de destino, com prós e contras.
• Plano de migração por etapas, com a estimativa de cada uma.

Fase 2: entregas incrementais

A migração acontece em etapas, cada uma entregando uma parte do sistema funcionando em produção, ao lado do legado. Cada etapa tem escopo e estimativa próprios, refinados com o que se aprendeu na anterior.

Por que isso protege o seu dinheiro:

• O compromisso inicial é pequeno. Se o diagnóstico mostrar que a migração não compensa agora, você gastou o diagnóstico, não o projeto.
• O erro de estimativa é limitado ao tamanho da etapa, não ao do projeto inteiro.
• O valor aparece cedo. A primeira parte migrada já entra em uso, em vez de tudo depender de uma virada no fim.
• Dá para parar, pausar ou repriorizar entre etapas, sem perder o que já foi feito — inclusive a documentação, que vale mesmo se a tecnologia mudar.

E o prazo?

Sem prometer números, as faixas qualitativas costumam ser estas: o diagnóstico leva de poucas semanas a um mês. Um sistema pequeno, bem conhecido e com dados limpos migra em alguns meses. Um sistema central, integrado e sem documentação leva de muitos meses a mais de um ano. O prazo de migração de software legado depende dos mesmos fatores do custo — e, na migração incremental, a pergunta mais útil nem é "quando acaba", mas "quando a primeira parte entra em produção".

Desconfie de prazo curto para sistema grande sem explicação de como: em geral, ele vem de uma das três hipóteses do item anterior.

O custo de não migrar

Ficar no sistema atual parece custo zero, porque ele já está pago. Não é. O custo de não migrar só não aparece numa única linha do orçamento:

• Dependência de pessoas-chave. Se uma ou duas pessoas são as únicas que conseguem mexer no sistema, a empresa tem um risco concentrado — de saída, de aposentadoria, de doença.
• Segurança. Plataformas sem evolução, sistemas operacionais antigos mantidos só para rodar o sistema, bancos sem atualização e acesso remoto improvisado acumulam vulnerabilidades.
• Contratação. Encontrar quem queira trabalhar com Delphi 7, VB6 ou WebForms fica mais difícil e mais caro a cada ano.
• Oportunidades. Integrar com um marketplace, oferecer um portal para o cliente, ter um aplicativo para a equipe de campo, usar IA sobre os próprios dados: cada um vira um projeto difícil, ou impossível, sobre a base antiga.
• Mudanças obrigatórias. Exigências fiscais e de integração continuam chegando, e implementá-las num sistema frágil é lento e arriscado.

Nada disso obriga a migrar amanhã. Mas a comparação justa não é "migrar contra não gastar": é "migrar de forma planejada contra migrar às pressas quando um desses custos estourar".

Como pedir um orçamento útil: o que levar para a primeira conversa

Não precisa ter tudo. Quanto mais destes itens estiverem à mão, mais útil será a primeira conversa:

1. O que o sistema faz e quais áreas da empresa dependem dele.
2. A tecnologia: linguagem e versão (Delphi 7, VB6, .NET Framework 4.x…), banco de dados e versão, onde roda.
3. Uma noção de tamanho: quantidade aproximada de telas, relatórios e usuários, tamanho do banco.
4. As integrações conhecidas, com quem e de que forma (API, arquivo, banco compartilhado).
5. Quem conhece o sistema hoje e se essas pessoas estarão disponíveis.
6. Qualquer documentação, mesmo antiga ou parcial.
7. O motivo da migração agora: risco de pessoa-chave, segurança, nova necessidade, exigência externa.
8. Restrições: datas importantes, tolerância a parada, orçamento disponível ou limite de investimento.
9. O destino desejado, se já houver preferência — ou a abertura para discutir opções.

Com isso, dá para dizer na primeira conversa qual é a ordem de grandeza do problema e propor um diagnóstico com escopo claro. Se for um sistema em .NET, vale ler antes o que muda ao migrar do .NET Framework para o .NET moderno.

Perguntas frequentes