Substituição de sistemas legados passo a passo: Strangler Pattern, operação paralela e consistência de dados na implantação

Uma substituição de sistemas legados raramente fracassa por causa de „construir“ a nova solução, mas sim na transição: os dados têm de permanecer corretos, as interfaces não podem romper, e a operação deve continuar durante a migração. Em muitas empresas, um Big-Bang-Cutover por isso não é uma opção – as dependências são demasiado grandes, os custos de indisponibilidade demasiado elevados, a reversão demasiado difícil.

Na prática, um procedimento gradual com Strangler Pattern (partes funcionais são „transferidas“ progressivamente), Parallelbetrieb (sistema antigo e novo funcionam temporariamente lado a lado) e regras claras para consistência de dados mostra-se eficaz. Este artigo demonstra como combinar esses blocos de forma que sejam sustentáveis no dia a dia da direção de TI, administração e responsabilidade de projeto – incluindo padrões típicos de erro, consequências operacionais e pontos de decisão no rollout.

Por que a abordagem passo a passo costuma ser a substituição de sistemas legados mais realista

Sistemas legados raramente são „apenas uma aplicação“. Normalmente estão ligados: execuções batch, interfaces de ficheiros (pastas SFTP, unidades de rede), processos de impressão e digitalização, ferramentas locais, extratos de BI, relés de e‑mail, hardware especializado, desvios de Shadow‑IT e workarounds manuais. Numa abordagem Big Bang, todos esses caminhos têm de funcionar no mesmo fim de semana – e isso incluindo permissões, dados mestres, históricos e casos especiais.

A abordagem passo a passo reduz o risco, mas não o desloca automaticamente para baixo. Ela torna os riscos mais visíveis e manejáveis, exigindo porém decisões claras de arquitetura e operação: onde será feito o roteamento? Quem é o responsável pelos dados (Datenführer)? Que nível de consistência é funcionalmente obrigatório, e onde um atraso temporal é aceitável? E como evitar que o funcionamento em paralelo se torne uma obra permanente?

Strangler Pattern na realidade empresarial: não „Microservices“, mas interfaces claras

O Strangler Pattern significa: constrói‑se novas funcionalidades ao lado do sistema legado e o tráfego é redirecionado gradualmente até a parte antiga se tornar desnecessária. Importante: isto não é uma guerra de religiões arquitetural („Monolith vs. Microservices“), mas um padrão de migração. Funciona também quando a arquitetura alvo continua a ser um monólito – só que mais moderna, mais manutenível e melhor integrável.

A decisão mais importante: corte por processos, não por tabelas

Em muitas substituições faz‑se um corte orientado por dados („Começamos pelas tabelas de clientes e pedidos“). Isso frequentemente leva a um funcionamento paralelo doloroso, porque os processos atravessam esses dados. Melhor é um corte orientado por processos, por exemplo „criação de proposta“, „recepção de mercadorias“, „tratamento de reclamações“ ou „ticket de serviço até fatura“.

Regra prática: Uma etapa Strangler deve cobrir um fluxo funcionalmente fechado, que no novo sistema possa ser operado e monitorado de ponta a ponta. Isso inclui entradas (UI, API, importação), processamento (regras de negócio) e saídas (impressão, exportação, contabilização, notificação).

Strangler precisa de um „redirecionador“: Gateway, Proxy ou camada de roteamento

Para que usuários e sistemas conectados não precisem aprender novos endpoints a cada mudança, costuma-se usar uma camada de roteamento. Dependendo da situação inicial isso pode ser: um reverse proxy na frente de aplicações web, um API-Gateway para endpoints de serviço ou uma camada de integração que consolida interfaces de arquivos e eventos. O que importa é a operabilidade: configuração centralizada, logs claros, monitoramento e um rollback controlado.

Para administradores é importante que essa camada não se torne uma caixa-preta. Eles precisam de roteamentos rastreáveis (qual request foi para onde), correlação via logs (por ex. Request-ID) e timeouts/regras de retry definidos, para que falhas não fiquem „coladas“.

Operação paralela é um modo de operação – não um „truque de projeto“

Operação paralela significa: componentes antigos e novos funcionam simultaneamente em produção por um período. Isso é normal, mas caro – sobretudo na operação. Você terá mais partes móveis, mais monitoramento, maior potencial de incidentes e responsabilidades mais complexas. Por isso a operação paralela deve ser planejada como um modo operacional temporal, incluindo critérios de encerramento.

Modelos típicos de operação paralela (e quando são adequados)

• Alternância por grupos de usuários (grupo piloto → ondas): adequado quando papéis de usuário são claramente separáveis e os processos não atravessam grupos.
• Alternância por mandantes/locais: adequado em estruturas de filiais/plantas, quando os fluxos de dados entre locais são limitados.
• Alternância por etapas do processo: p. ex. „entrada nova, faturamento ainda no antigo“ – arriscado se existirem muitas retroalimentações, mas às vezes inevitável.
• Alternância por tipo de objeto: p. ex. novos ativos no sistema novo, saldos antigos no antigo – pode funcionar se existirem regras claras para histórico/reporting.

Do ponto de vista operacional, projete a operação paralela de modo que os domínios de falha permaneçam pequenos: uma falha no componente novo não deve arrastar o sistema legado (por ex. via interfaces bloqueantes ou bloqueios de banco de dados), e inversamente o legado não deve sabotar todos os fluxos novos por exportações instáveis.

Feature Flags e regras de roteamento: controle em vez de „implantamos e esperamos“

Feature Flags são chaves com as quais você ativa/desativa funcionalidades de forma direcionada – sem novo deploy. Para a direção de TI e responsáveis de projeto não é o detalhe técnico que importa, e sim a governança: quem pode alternar? Como fica documentado o motivo da mudança? Com que rapidez é possível reverter? Quais dependências surgem (por exemplo, se dados já tiverem sido gerados no novo formato)?

Uma prática sensata é manter um pequeno registro de mudanças (Decision Log) por ação de comutação: momento, owner, grupo de usuários afetado, efeito esperado, indicador de monitoramento, condição de rollback. Isso evita o clássico „ninguém mais sabe por que está roteado assim“.

Consistência de dados no rollout: o núcleo do qual muitas substituições dependem

Consistência de dados significa que os dados estão corretos do ponto de vista funcional, completos e disponíveis na ordem esperada. Em operação paralela isso se torna difícil, porque dois sistemas escrevem simultaneamente ou pelo menos ambos reivindicam ser a „verdade“. É aqui que se decide se a substituição do legado será estável ou se você ficará meses fazendo reconciliações de deltas.

Primeiro esclarecer: Quem é o „System of Record“ para cada área de dados?

Você precisa, para cada área de dados (por ex. Debitoren, Artikel, Preise, Aufträge, Lagerbewegungen, Belege) de uma definição sobre qual sistema é o líder. Isso não é apenas uma questão de arquitetura, mas operacional:

• Onde são efetuadas as correções em caso de suporte?
• Onde se situa o processo de aprovação (Vier-Augen, SoD/Trennung von Funktionen)?
• Quais trilhas de auditoria são necessárias (quem alterou o quê e quando)?
• Como evitar retrabalhos no fechamento mensal?

Nas primeiras etapas do padrão Strangler costuma ser sensato deixar o legado inicialmente como sistema líder de dados e a nova componente „apenas“ consumi-los. Posteriormente, você inverte a liderança. Essa mudança de liderança é um marco próprio e requer uma janela clara de cutover, além de um plano de comunicação e aceitação.

Padrões de sincronização: Dual Write, CDC e Events – com expectativas realistas

Existem vários caminhos para sincronizar dados entre o antigo e o novo. Nenhum é „gratuito“.

• Dual Write: Uma ação grava em ambos os sistemas (por ex., criar pedido → Legacy e novo sistema). Vantagem: disponibilidade rápida. Desvantagem: o tratamento de falhas é complexo (e se o System A gravar e o System B não?), além disso surgem dependências e frequentemente riscos de desempenho.
• Change Data Capture (CDC): mudanças são extraídas do log do banco de dados ou via Trigger/Replication como deltas. Vantagem: desacopla aplicação e sincronização. Desvantagem: você replica também alterações „técnicas“ e precisa reconstruir eventos de negócio; além disso, mudanças de esquema no legado passam a ser um risco de integração.
• Integração baseada em eventos: o sistema publica eventos de domínio (por ex., „Auftrag freigegeben“), que outros sistemas consomem. Vantagem: semântica de negócio clara. Desvantagem: exige definições de evento bem elaboradas, idempotência (processamento múltiplo sem efeitos adversos) e um conceito operacional de messaging confiável.

Para tomadores de decisão é crucial: consistência de dados não é binária. Alguns processos requerem consistência forte (imediatamente correta, por ex., liberações de pagamento), outros toleram consistência eventual (pequeno atraso, por ex., índice de busca, reporting, notificações). Essa classificação deve ser alinhada cedo com a área de negócio e com a auditoria.

Conflitos e duplicatas: Planeje explicitamente o „hässlichen Pfad“

No funcionamento em paralelo, os conflitos surgem tipicamente assim: dois sistemas alteram o mesmo objeto, mas seguindo regras diferentes. Ou uma importação é executada em duplicado porque um retry ocorreu „cedo demais“. Ou um utilizador corrige dados no sistema legado enquanto a nova interface já tinha sido alterada.

São necessárias regras vinculantes para isso:

• Resolução de conflitos: „Last write wins“ raramente é correto do ponto de vista funcional. Melhor são prioridades (sistema líder vence) ou regras de merge orientadas pelo domínio (por exemplo, dados mestres de contato vs. condições).
• Idempotência: Cada integração deve tolerar múltiplos processamentos sem duplicatas (por exemplo, mesma numeração de documento, mesma referência externa).
• Dead-Letter/Quarentena: Deltas não processáveis devem ser localizáveis, com responsabilidade clara e possibilidade de reexecução.

Sem essas regras, a consistência dos dados degenera em „conciliação via Excel“ e retrabalho manual — com a frustração correspondente e custos indiretos difíceis de quantificar.

Planejamento do rollout: ondas, aprovações e fallback, sem sobrecarregar a operação

Um bom rollout é mais do que „deployment + treinamento“. Em funcionamento paralelo é preciso integrar rollout e operação: quem faz o first-level em caso de erros? Quais logs estão imediatamente disponíveis? Como é feita a escalada? Quais processos não podem ser alterados durante uma onda (por exemplo, fechamento mensal, inventário, alteração de preços)?

Planejamento em ondas com critérios rígidos

Comprovou-se eficaz um planejamento por ondas com critérios de entrada claros, não apenas datas. Exemplos de critérios rígidos:

• Dashboards de monitoramento e alerting para o novo componente estão em produção e testados (incluindo redução do „ruído de alarmes“).
• Runbooks para incidentes típicos existem (timeouts, congestionamento de filas, importações com erro, erros de permissão).
• A reconciliação de deltas é automatizada e fornece relatórios claros (diferenças por tipo de objeto, janela temporal, classe de causa).
• O mecanismo de rollback foi praticado (pelo menos em Staging/Pre-Prod de forma realista).

Esse último ponto é especialmente subestimado: rollback não é „voltamos ao estado anterior“. Se o novo sistema já gerou dados, é preciso saber como esses dados serão visíveis no sistema legado ou como migrá-los/neutrá-los corretamente.

Cutovers: mini-cutovers em vez de Big Bang

Mesmo no Strangler Pattern há cutovers — só que menores. Tipicamente ocorrem mini-cutovers na troca de um passo de processo ou na mudança da responsabilidade pelos dados. Cada mini-cutover precisa de:

• Congelamento de dados (curto, mas vinculante): quem pode alterar o quê durante esse período?
• Conciliação: o que foi alterado desde a última sincronização?
• Comutação: roteamento/feature flags, jobs, cronogramas, permissões.
• Verificação: testes de verificação funcionais (por exemplo, criar pedido → nota de entrega → fatura), além de checagens técnicas (filas, taxas de erro, carga no DB).

Para a direção de TI é importante que esses passos estejam documentados como processo repetível e com cobertura de pessoal. Caso contrário, o sucesso do projeto depende de indivíduos que „sabem como fazer“.

Estabilizar primeiro as interfaces: o fundamento subestimado da substituição do legado

Muitos sistemas legados comunicam-se por interfaces que evoluíram ao longo do tempo: exportações CSV para pastas, jobs noturnos, acessos diretos ao banco de dados por ferramentas de terceiros, workflows baseados em e-mail. Uma substituição gradual torna-se muito mais simples se você primeiro inventariar o panorama de interfaces e consolidá-lo em poucos pontos.

Na prática isso significa: identifique pontos de integração críticos do sistema (por exemplo, contabilidade financeira, expedição, retornos de produção, identidades/permissões) e estabeleça contratos claros nesses pontos. “Contrato” aqui não se refere ao jurídico, mas à estabilidade técnica: versionamento, campos inequívocos, IDs estáveis, tratamento de erros documentado, SLAs definidos para a entrega de dados.

Se você estabelecer um modelo interno de governança de API/integração (responsáveis, regras de depreciação, caminhos de teste/staging), reduz o risco de que uma alteração em sistema legado paralise repentinamente sua nova componente. Um ponto temático adequado para linkagem interna seria, por exemplo, um artigo sobre governança de API e estratégias de depreciação.

Segurança, permissões e auditoria: a operação em paralelo intensifica o tema

Na operação em paralelo costumam existir modelos de usuários e funções duplicados. Isso gera privilégios ocultos: um usuário pode estar corretamente restrito no sistema novo, mas ainda ter privilégios amplos no legado — e acabar usando o “caminho mais simples”. Além disso há contas técnicas (Service Accounts) para sincronização, importações, filas e jobs em lote.

Pontos concretos que você deve esclarecer desde o início:

• Fonte de identidade: De onde vêm usuários e grupos? AD/Entra ID? Um IAM próprio? É importante que o provisionamento seja rastreável.
• Mapeamento de funções: Se as funções não correspondem 1:1, são necessárias funções de transição, com prazo determinado e recertificação.
• Contas de serviço: Privilégios mínimos, rotação de segredos, registro consistente. Especialmente contas de sincronização são um ponto de entrada e difíceis de auditar se não tratadas corretamente.
• Trilhas de auditoria: Quando a responsabilidade pelos dados muda, deve ficar claro onde está a evidência das alterações e como ela permanece consultável em ambos os sistemas.

Importante para decisores: segurança aqui não é “escopo adicional”, mas afeta a viabilidade da implantação. Ajustar permissões no funcionamento em paralelo mais tarde costuma ser mais caro do que uma definição precoce e pragmática de papéis e da segmentação das contas de serviço.

Monitoramento, registro e transferência operacional: sem observabilidade, a operação em paralelo fica cega

No funcionamento em paralelo os padrões de falha são muitas vezes indiretos: um delta fica pendente, um retry roda indefinidamente, uma fila se acumula, ou um job crítico por tempo colide com um lock de banco de dados. Se você vê isso apenas por tickets de usuários, já é tarde demais. Por isso você precisa desde o início de um mínimo de observabilidade: monitoramento (estado), registro (eventos) e — quando fizer sentido — tracing (cadeia entre sistemas).

Sinais práticos e operáveis incluem, por exemplo:

• Backlog de sincronização (quantas mudanças estão “à espera”), mais a idade da entrada mais antiga.
• Taxas de erro por interface e por classe de erro (validação, timeout, autenticação, conflito de dados).

Para a transferência de operação, importa menos qual ferramenta é utilizada e mais se responsabilidades e runbooks estão claros. Se houver on-call ou plantão, a operação deve permanecer capaz de atuar em falhas típicas sem investigação por parte dos desenvolvedores.

Quando o Strangler Pattern não é adequado (ou apenas com restrições claras)

Há situações em que a substituição gradual funciona apenas de forma limitada:

• Acoplamento transacional extremamente estreito: Se quase toda operação atravessa todos os módulos e exige consistência estrita, o funcionamento em paralelo torna-se rapidamente incontrolável.
• Acessos diretos ao banco de dados por sistemas terceiros: Se várias ferramentas lêem/escrevem diretamente em tabelas legadas, esse crescimento desordenado precisa ser encerrado ou controlado primeiro.
• Propriedade dos dados pouco clara: Se não for possível definir quem é o responsável pelos dados, conflitos são garantidos — e a substituição vira questão política em vez de técnica.
• Falta de disciplina operacional: Sem ambientes limpos, implantações reproduzíveis e monitoramento, cada etapa intermediária se torna um risco.

Isso não significa que você esteja obrigado ao Big Bang. Mas então você precisa alterar a ordem: primeiro estabilizar pontos de integração, centralizar acessos a dados, esclarecer papéis e ownership — e só então aplicar o Strangler Pattern.

Um plano prático de execução para a substituição do legado em etapas

Como orientação para responsáveis pelo projeto, um fluxo em etapas claras tem se mostrado eficaz. A forma exata depende do sistema e do setor, mas a lógica é robusta:

1. Inventário & dependências: interfaces, jobs, fluxos de dados, grupos de usuários, janelas críticas (fechamento, inventário).
2. Definir interfaces: módulos de processo, liderança dos dados por área, contratos de integração.
3. Construir roteamento e mecanismos de comutação: Gateway/Proxy, Feature Flags, registro centralizado.
4. Definir caminho dos dados: CDC/eventos/Dual Write, regras de conflito, quarentena, relatórios de reconciliação.
5. Piloto com carga real: não apenas demonstração, mas com casos reais, incluindo exceções.
6. Rollout em ondas: critérios de entrada, checklists de cutover, exercícios de rollback.
7. Desativar & limpar: desativar caminhos antigos, remover jobs, revogar permissões, atualizar documentação.

O último ponto é essencial: muitas organizações mantêm componentes legados “por segurança” em operação. Resultado: custos duplicados, risco indefinido, ninguém se atreve a desligar. Planeje o descomissionamento como subprojeto com prazo, responsáveis e evidências (p.ex. “nenhum acesso nas últimas X semanas”, “todos os exports migrados”, “requisitos de auditoria cumpridos”).

Conclusão: Substituir passo a passo significa tratar consistência e operação como um produto

Uma substituição do legado passo a passo não é automaticamente mais fácil — mas em muitas empresas é a única opção realista. O Strangler Pattern funciona se você definir, por etapa, bordas de processo claras, planejar o funcionamento paralelo como um estado operacional real e não deixar a consistência dos dados ao acaso. Essenciais são decisões precoces sobre propriedade dos dados, padrões robustos de sincronização com regras de conflito, bem como um design de rollout com ondas, aceites e fallback ensaiado.

Se estiver a planear uma substituição e quiser discutir de forma estruturada as interfaces, o funcionamento em paralelo ou o conceito de consistência de dados, pode contactar-nos através de .

Discutir projeto ou iniciativa de modernização com Net-Base.