# Modernização gradual de sistemas legados: troca por partes

> Modernização gradual de sistemas legados na prática: como trocar módulo a módulo, manter antigo e novo convivendo e saber quando desligar cada parte.

Fonte: https://pervian.tech/blog/modernizacao-gradual-de-sistemas · Pervian Tech · publicado em 2026-10-01

A decisão já foi tomada: o sistema que sustenta a empresa há anos precisa ser substituído. Ele roda numa plataforma sem suporte, [só uma pessoa entende](https://pervian.tech/blog/sistema-dependente-de-um-programador) o fechamento mensal e cada mudança pedida pelo comercial vira semanas de espera. O problema é o "como". [Parar a operação para trocar tudo de uma vez](https://pervian.tech/blog/troca-de-erp-sem-parar-a-operacao) não é opção, e ninguém quer apostar a emissão de notas e o faturamento num único fim de semana de virada.

É aqui que muitos projetos de modernização travam. A empresa contrata uma reconstrução completa, o time passa meses construindo em paralelo, o sistema antigo continua recebendo ajustes que o novo não acompanha e, quando chega a data, o novo ainda não faz tudo o que o antigo fazia. A virada é adiada, depois adiada de novo.

Existe um caminho com menos risco, a **modernização gradual de sistemas legados**: trocar o sistema por partes, colocando cada módulo novo em produção assim que ele estiver pronto, com o antigo e o novo funcionando juntos até que o legado possa ser desligado. Este texto mostra como executar isso na prática, do primeiro módulo ao último desligamento.

## Resposta curta: como fazer uma modernização gradual

Se você precisa da versão resumida, é esta:

1. **Mapeie o sistema atual por capacidades de negócio** (cadastro, pedidos, estoque, faturamento, financeiro), não por telas.
2. **Escolha um primeiro módulo** com valor visível e pouca dependência das partes mais frágeis.
3. **Coloque uma camada de entrada na frente** (uma tela, um roteador de chamadas ou uma integração) que decide se cada operação vai para o antigo ou para o novo.
4. **Defina quem é dono de cada dado** em cada momento e sincronize o resto.
5. **Coloque o módulo novo em produção**, primeiro para um grupo pequeno de usuários, depois para todos.
6. **Desligue a parte correspondente do legado** só quando os critérios de desligamento forem cumpridos.
7. **Repita** até o sistema antigo não ter mais função.

O resto do texto detalha cada passo, os pontos em que esse tipo de projeto costuma escorregar e como medir se ele está andando.

## O risco do big bang na troca de sistemas

A virada única, conhecida como big bang (tudo de uma vez), parece mais simples no papel: um projeto, uma data, um sistema novo. Na prática, concentra quase todo o risco num só dia.

- **O alvo se move.** Enquanto o sistema novo é construído, o antigo continua mudando: nova regra fiscal, nova tabela de comissão, novo cliente com condição especial. Cada mudança precisa ser feita duas vezes ou vira diferença na virada.
- **Nada é validado de verdade antes do fim.** Homologação ajuda, mas o uso real, com volume real e usuários com pressa, só começa no dia da troca. Os problemas aparecem todos juntos.
- **Não existe meio-termo.** Se algo grave dá errado, a escolha é entre voltar tudo para o antigo, com os dados lançados no novo nesse meio-tempo, ou seguir com o problema.
- **O negócio fica meses sem receber nada.** O investimento só começa a gerar valor no último dia, e a paciência da diretoria costuma acabar antes disso.

A discussão sobre reconstruir ou melhorar o que existe é anterior a esta e está em [reescrever ou refatorar um sistema legado](https://pervian.tech/blog/reescrever-ou-refatorar-sistema-legado), e a de trocar por produto pronto, em [sistema legado ou SaaS pronto](https://pervian.tech/blog/sistema-legado-ou-saas-pronto). Aqui partimos do ponto em que a decisão de substituir foi tomada e a pergunta é como executar com segurança.

## O padrão estrangulador em linguagem simples

O nome técnico da abordagem gradual é **padrão estrangulador** (strangler fig, em inglês). A imagem vem de uma figueira que nasce sobre outra árvore, cresce em volta dela e, com o tempo, ocupa o lugar dela. A árvore original não é derrubada num dia: vai perdendo função até não fazer mais falta.

No software, funciona assim:

- **Uma porta de entrada única.** Os usuários e as integrações passam a acessar o sistema por um ponto que você controla. Pode ser um portal web novo, um roteador de chamadas ou uma camada de integração.
- **Cada funcionalidade tem um endereço.** Essa porta sabe que "emitir pedido" ainda vai para o sistema antigo, mas "consultar estoque" já vai para o módulo novo.
- **A troca é feita funcionalidade por funcionalidade.** Quando um módulo novo fica pronto, a porta passa a mandar aquela operação para ele. O usuário pode nem perceber que mudou de sistema.
- **O legado encolhe.** Cada parte transferida é uma parte do sistema antigo que pode ser desligada.

A diferença em relação ao big bang é que o risco é dividido em várias viradas pequenas, cada uma com volta possível. Se o módulo novo de estoque apresentar um problema sério, a porta volta a mandar as consultas para o antigo enquanto o problema é corrigido.

## Escolhendo o primeiro módulo

O primeiro módulo define o tom do projeto inteiro. Ele precisa provar que a abordagem funciona, sem expor a empresa ao maior risco logo de saída.

### Critérios para escolher

| Critério | O que procurar | O que evitar |
|---|---|---|
| Valor para o negócio | Algo que os usuários reclamam e vão notar a melhoria | Módulo que ninguém usa |
| Dependências | Poucas ligações com o resto do sistema | O coração do sistema, por onde tudo passa |
| Dono dos dados | Dados que podem ficar sob responsabilidade do novo módulo | Dados gravados por dez telas diferentes do legado |
| Risco operacional | Falha incômoda, mas contornável | Falha que para faturamento ou expedição |
| Tamanho | Algo que chega à produção em semanas ou poucos meses | Módulo que leva um ano para ficar pronto |

### Bons candidatos de primeiro módulo

- **Consultas e relatórios.** Ler dados é mais seguro que gravar. Um painel novo de pedidos ou de estoque, alimentado pelo banco do sistema antigo, entrega valor rápido e testa a infraestrutura nova.
- **Um processo periférico com dor clara.** Portal do cliente, aprovação de despesas, agendamento de entregas ou cadastro de fornecedores costumam ter poucas dependências.
- **Uma funcionalidade nova que o legado não tem.** Em vez de construí-la no sistema antigo, ela já nasce no novo, aproveitando o momento.

O que quase nunca deve ser o primeiro: faturamento, cálculo de impostos, fechamento financeiro. Esses vêm depois, quando a equipe já domina o caminho e a convivência entre os dois sistemas está estável.

## Convivência: antigo e novo lendo os mesmos dados

A parte mais delicada da modernização gradual não é o código novo; são os dados. Durante meses, dois sistemas vão precisar enxergar o mesmo cliente, o mesmo pedido e o mesmo saldo de estoque.

### Defina o dono de cada dado

Para cada entidade (cliente, produto, pedido, título financeiro), escreva quem é a **[fonte da verdade](https://pervian.tech/blog/sincronizacao-de-cadastros-entre-sistemas)** naquela fase. Só um sistema grava; o outro lê ou recebe cópia. Dois sistemas gravando o mesmo cadastro sem regra clara é a forma mais rápida de gerar divergência.

Um exemplo de evolução:

- **Fase 1:** o legado é dono de clientes e pedidos. O módulo novo de consulta só lê.
- **Fase 2:** o cadastro de clientes passa para o sistema novo. O legado recebe uma cópia sincronizada para continuar emitindo pedidos.
- **Fase 3:** pedidos passam para o novo. O legado só recebe o que precisa para o faturamento, que ainda está lá.

### Formas de sincronizar

- **Banco compartilhado, por um tempo.** O módulo novo lê direto o banco do legado. É rápido de começar, mas amarra o novo à estrutura antiga. Use como ponte, não como destino.
- **[Sincronização por eventos](https://pervian.tech/blog/filas-e-mensageria-quando-usar) ou rotinas.** Quando um dado muda num lado, uma rotina envia a mudança para o outro. Exige tratamento de falha, reprocessamento e conciliação.
- **Camada de integração.** Quando o legado não oferece nenhuma interface, é preciso criar uma por fora. As opções (leitura de banco, arquivos, automação de tela) estão em [integrar um sistema legado sem API](https://pervian.tech/blog/integrar-sistema-legado-sem-api).

Seja qual for o caminho, inclua desde o primeiro dia uma **conciliação**: uma rotina que compara os dois lados e aponta diferenças. Ela é o que permite confiar na convivência.

## Usuários em dois sistemas: como minimizar

Para quem opera, trabalhar em dois sistemas ao mesmo tempo é o custo mais visível da modernização gradual. Dá para reduzir bastante esse incômodo.

- **Corte por processo completo, não por tela.** Se o vendedor cadastra o cliente no sistema novo e precisa voltar ao antigo para ver o limite de crédito, a experiência piora. Mova o fluxo inteiro de uma pessoa sempre que possível.
- **Uma porta só.** Um portal único com menu que leva às telas novas e às antigas, [com o mesmo login](https://pervian.tech/blog/sso-e-autenticacao-em-dois-fatores), evita que o usuário precise lembrar onde está cada coisa.
- **Comece por um grupo.** Uma filial, um time ou um tipo de pedido usa o novo primeiro. Os problemas aparecem em escala pequena.
- **Treinamento curto e perto da troca.** Explicar a tela nova meses antes não funciona. Faça na semana da mudança, com material de consulta rápida.
- **Canal direto para dúvidas.** Nas primeiras semanas, alguém da equipe acompanha de perto e registra o que está confuso.

Quando o legado é um sistema desktop instalado em cada máquina, a porta única costuma ser justamente o novo sistema web, que vai absorvendo as telas antigas. Os detalhes dessa transição estão em [como migrar um sistema desktop para a web](https://pervian.tech/blog/migrar-sistema-desktop-para-web).

## Critérios para desligar cada parte do legado

Aqui mora o erro mais caro da modernização gradual: **nunca desligar nada**. O módulo novo vai para produção, mas o antigo continua ligado "por segurança", e a empresa passa a manter dois sistemas para sempre.

Cada parte do legado só deve ser desligada quando cumprir critérios definidos antes, por escrito. Uma lista de verificação que usamos como ponto de partida:

- **Todo o tráfego daquela funcionalidade já passa pelo módulo novo**, inclusive integrações, rotinas noturnas e relatórios esquecidos.
- **A conciliação bate de forma consistente** por um período combinado, cobrindo pelo menos um fechamento mensal.
- **Os usuários-chave validaram** os casos difíceis da operação, não só o fluxo comum.
- **Nenhuma rotina do legado depende daquela parte.** Procure tarefas agendadas, exportações e planilhas que leem o banco antigo.
- **Os dados históricos foram migrados ou têm acesso garantido** para consulta, auditoria e obrigações legais. Prazos de guarda de documentos fiscais e trabalhistas devem ser confirmados com o contador e o jurídico.
- **Existe plano de volta documentado** para as primeiras semanas após o desligamento.
- **Alguém com autoridade assinou o desligamento.** Não é decisão só da equipe técnica.

O desligamento pode ser feito em etapas: primeiro bloquear a gravação na parte antiga, deixando só consulta; depois remover o acesso; por fim, desativar o código e o banco correspondente.

## Medindo o avanço da modernização

Projeto gradual sem medida vira projeto eterno. Algumas métricas simples mostram se ele está andando:

- **Funcionalidades transferidas**, comparando o total mapeado no início com o que já roda no novo.
- **Partes do legado efetivamente desligadas.** Transferir sem desligar não reduz custo nem risco.
- **Usuários e volume operando no novo**, por módulo.
- **Divergências na conciliação**, que devem cair com o tempo.
- **Incidentes por módulo**, para comparar a estabilidade do novo com a do antigo.
- **Tempo de entrega de mudanças pedidas pelo negócio** nas partes já modernizadas, que é a razão de existir do projeto.

Um quadro com essas métricas, revisado em todo ciclo com a diretoria, evita que o projeto perca prioridade quando surgem urgências.

## Erros comuns na modernização por partes

- **Copiar o sistema antigo tela por tela.** A modernização é a chance de rever o processo. Replicar campos que ninguém usa e fluxos que existem por limitação do sistema antigo desperdiça a oportunidade.
- **Deixar a camada de entrada para depois.** Sem ela, cada troca de módulo vira uma mudança de hábito para o usuário e de configuração para as integrações.
- **Dados sem dono.** Dois sistemas gravando o mesmo cadastro geram divergência que só aparece no fechamento.
- **Continuar evoluindo o legado em paralelo.** Funcionalidade nova deve nascer no novo, salvo exigência legal com prazo.
- **Começar pelo módulo mais crítico** para "resolver logo o que dói mais". O risco é alto demais para um time que ainda está aprendendo o caminho.
- **Não planejar o fim.** Sem critérios de desligamento, a convivência temporária vira permanente.

Prazos variam muito com o tamanho do sistema e a qualidade dos dados. Como referência genérica, e com a ressalva de que só o diagnóstico permite estimar, cada módulo costuma levar de algumas semanas a poucos meses, e o projeto inteiro se mede em ciclos, não numa data única.

## Perguntas frequentes

### Quanto tempo leva uma modernização gradual de sistema legado?

Depende do tamanho do sistema e da qualidade dos dados. Como referência genérica, e sujeita a diagnóstico, cada módulo costuma levar de algumas semanas a poucos meses, e a modernização gradual inteira se mede em ciclos, não numa data única. A vantagem é que cada módulo entregue já gera valor antes do fim do projeto.

### Modernização gradual dá mais trabalho que trocar o sistema de uma vez?

Dá um esforço extra com a convivência entre os sistemas, como sincronização de dados, conciliação e camada de entrada. Em troca, a modernização gradual divide o risco em viradas pequenas com volta possível e entrega valor desde o primeiro módulo, enquanto a troca de uma vez concentra o risco e só gera retorno no último dia.

### Dá para continuar alterando o sistema legado durante a modernização?

Só o necessário. Durante a modernização gradual, funcionalidades novas devem nascer no sistema novo, salvo exigência legal com prazo que obrigue a mexer no legado. Continuar evoluindo o sistema antigo em paralelo cria um alvo móvel, duplica trabalho e aumenta as diferenças que precisam ser resolvidas a cada módulo transferido.

### Qual a diferença entre modernização gradual e refatoração?

Refatoração melhora o código de um sistema existente sem mudar o comportamento dele, mantendo a mesma base. A modernização gradual substitui o sistema por partes, colocando módulos novos em produção enquanto o legado continua funcionando, até ser desligado. As duas podem se combinar: refatorar o legado para isolar módulos facilita a troca.

### Quando a modernização gradual não é indicada?

Quando o sistema é pequeno, com poucas telas e escopo simples, uma troca única pode ser mais simples que manter dois sistemas convivendo. A modernização gradual faz mais sentido em sistemas grandes e críticos, em que parar a operação não é opção e uma virada de uma vez concentraria risco demais num só dia.

## Como a Pervian Tech trabalha modernização incremental

Na Pervian Tech, a modernização gradual começa pelo diagnóstico: entender o que o sistema atual faz, quem depende de cada parte, onde estão os dados e quais regras só existem no código. A partir daí desenhamos o mapa de módulos, a camada de entrada e a ordem de troca, com critérios de desligamento definidos junto com a diretoria. Esse trabalho faz parte do nosso serviço de [arquitetura de software](https://pervian.tech/servicos/arquitetura-de-software) e da nossa abordagem de [modernização de sistemas legados](https://pervian.tech/solucoes/modernizacao-de-sistemas-legados).

O plano é sempre sob medida, porque cada legado tem dependências e riscos em lugares diferentes. O investimento é definido sob consulta, depois de um diagnóstico inicial gratuito que mostra por onde começar com segurança. Mais textos sobre o tema estão na categoria [modernização](https://pervian.tech/blog/categoria/modernizacao). Se o seu sistema precisa ser trocado e parar a operação não é opção, [conte como ele funciona hoje](https://pervian.tech/#contato).