3.6 Modernização de sistemas legados

Visão geral e motivação

Os sistemas legados são os sistemas que movem o mundo. Os livros-razão bancários centrais, os motores tributários e de benefícios, os sistemas de controle de tráfego aéreo e de defesa, a administração de apólices de seguros e os registros governamentais de que as sociedades dependem costumam ter décadas. Muitos são escritos em COBOL (Common Business-Oriented Language) ou em outras tecnologias mais antigas e ainda processam a maioria das transações críticas. “Legado” não é um insulto. Significa que o sistema é valioso o bastante para ter sobrevivido, crítico o bastante para que a falha seja catastrófica e antigo o bastante para que mudá-lo com segurança seja difícil. A modernização de legados é a disciplina de melhorar, migrar ou substituir esses sistemas sem quebrar os serviços essenciais que eles prestam.

Este é um problema desproporcionalmente corporativo e governamental, e é onde ocorrem as maiores e mais públicas falhas de TI. Uma vasta parcela das grandes transações no mundo ainda toca sistemas de mainframe. Uma grande fração do código de produção nas grandes instituições está em linguagens mais antigas, mantidas por um grupo envelhecido e minguante de especialistas. Os governos carregam o fardo mais pesado: obrigações estatutárias codificadas ao longo de décadas, ciclos de contratação e de orçamento que sobrevivem às administrações e serviços ao cidadão que não podem ser interrompidos. O risco dominante não é que esses sistemas sejam velhos, já que muitos funcionam esplendidamente. É que o conhecimento para mantê-los está se aposentando, as plataformas são cada vez mais caras e restritas e a tentação de “simplesmente reescrever” leva a alguns dos fracassos mais caros da história do campo.

Este capítulo cobre os padrões incrementais de modernização que realmente funcionam (figueira-estranguladora e ramificação por abstração), como avaliar e priorizar o risco do legado, a custódia dos parques de mainframe e de COBOL, a disciplina da migração de dados e da execução em paralelo e, acima de tudo, como resistir à tentação da grande reescrita. A convicção central é que a modernização bem-sucedida é quase sempre incremental, guiada por evidências e entrega valor de forma contínua. Nunca é um big bang de vários anos.

Princípios fundamentais

Legado significa valioso e fundamental, não meramente velho. Respeite o que o sistema faz antes de tocá-lo. Ele codifica décadas de regras de negócio duramente conquistadas.
O incremental vence o big-bang, quase sempre. Substitua peça por peça atrás de uma interface estável. Entregue valor continuamente e mantenha pequeno o risco.
A grande reescrita é o modo de falha padrão. As reescritas completas rotineiramente estouram prazos, entregam menos e são canceladas. Trate o impulso com profunda desconfiança.
Você não consegue modernizar o que não entende. Faça engenharia reversa e documente o comportamento (inclusive as regras não documentadas) antes de substituí-lo.
A migração de dados é onde os projetos morrem. Os dados são mais antigos, mais sujos e mais emaranhados do que qualquer um espera. Planeje-os como um esforço de primeira classe.
Rode o antigo e o novo em paralelo para construir confiança. A execução em paralelo e a comparação pegam discrepâncias antes da virada.
Priorize por risco e valor, não por idade. Modernize primeiro o que é mais arriscado e mais valioso, não o que é simplesmente mais velho.
Mantenha as luzes acesas enquanto troca o motor. O serviço precisa continuar funcionando o tempo todo. Não há indisponibilidade aceitável para sistemas críticos de cidadãos ou financeiros.

Recomendações

Modernize incrementalmente com o padrão figueira-estranguladora

A figueira-estranguladora (que leva o nome da trepadeira que cresce ao redor de uma árvore e gradualmente a substitui) é o cavalo de batalha da modernização segura. Ponha uma camada de roteamento (um gateway de API, uma fachada ou um proxy) na frente do sistema legado. Depois, capacidade por capacidade, construa a substituição num sistema moderno e redirecione essa fatia do tráfego para ele, deixando o resto no sistema legado. Com o tempo o novo sistema cresce e o antigo encolhe, até poder ser aposentado. Isso entrega valor continuamente, mantém cada mudança pequena e reversível, evita uma virada arriscada e permite parar ou repriorizar a qualquer momento. É o oposto do big bang. O sistema legado continua funcionando e continua merecendo seu lugar enquanto você o substitui ao redor dele.

Use a ramificação por abstração para as costuras internas

Onde você precisa substituir um componente do qual muitas partes do sistema dependem, use a ramificação por abstração. Introduza uma camada de abstração (uma interface) sobre a implementação existente, migre os chamadores para dependerem da abstração, construa a nova implementação atrás da mesma abstração, faça a troca (muitas vezes atrás de um sinalizador de funcionalidade, gradualmente) e por fim remova a implementação antiga. Isso permite substituir um grande componente de forma incremental na linha principal de desenvolvimento, sem um ramo de vida longa, mantendo o sistema passível de lançamento o tempo todo. Combina naturalmente com a figueira-estranguladora: a fachada trata das costuras externas, a ramificação por abstração trata das internas.

Avalie e priorize o risco do legado deliberadamente

Antes de modernizar, construa um inventário claro e uma avaliação de risco do parque. Para cada sistema, pontue a criticidade de negócio, o risco técnico (obsolescência, plataformas sem suporte, exposição de segurança), a frequência de mudança e, de forma crucial, o risco de conhecimento (quantas pessoas ainda conseguem mantê-lo e quão perto estão de se aposentar). Plote os sistemas numa grade de risco versus valor. Priorize modernizar o que é ao mesmo tempo de alto risco e de alto valor. Considere deixar em paz os sistemas estáveis, de baixa mudança e bem compreendidos mesmo que sejam velhos, porque um sistema que funciona e que ninguém precisa mudar não é uma emergência. Essa avaliação transforma “tudo é velho e assustador” num roteiro defensável e sequenciado.

Cuide do parque de mainframe e de COBOL, não apenas o substitua

Nem todo sistema de mainframe ou de COBOL deve, ou pode com segurança, ser substituído em breve. A prioridade de curto prazo costuma ser a custódia: capturar o conhecimento antes que ele se aposente. Documente as regras de negócio que o código codifica (boa parte delas não documentada e insubstituível), invista em testes automatizados que fixem o comportamento atual para que a mudança futura seja segura, recrute e treine em rodízio os mantenedores e modernize as práticas de entrega ao redor (controle de código-fonte, integração contínua (CI), testes automatizados) mesmo com o núcleo permanecendo no lugar. Onde você de fato modernizar, prefira expor as capacidades legadas por APIs modernas (encapsulamento) como primeiro passo. Trate com cautela a tradução automática de COBOL para uma linguagem moderna, porque ela produz código que roda mas muitas vezes reproduz fielmente uma lógica incompreensível. O recurso mais escasso é o entendimento, não a computação.

Trate a migração de dados e a execução em paralelo como o núcleo do projeto

A parte mais difícil e mais arriscada da maioria dos esforços de modernização são os dados. São volumosos, de qualidade pobre e inconsistente e cheios de significado não documentado acumulado ao longo de décadas. Faça o profiling e a limpeza deles, mapeie explicitamente os esquemas antigo e novo e construa uma migração repetível e automatizada com conciliação completa (contagens, somas de verificação, totais de negócio) para poder provar que nada foi perdido nem alterado. Reduza o risco da virada com a execução em paralelo: opere os sistemas antigo e novo lado a lado sobre as mesmas entradas e compare as saídas até o novo sistema coincidir com o antigo no seu limiar de confiança. Só então faça a virada e mantenha a capacidade de reverter. Para sistemas verdadeiramente críticos, migre e faça a virada em fatias e não de uma vez.

Gerencie a tentação da grande reescrita

O instinto de jogar fora o sistema antigo e bagunçado e construir um novo, limpo, do zero é poderoso e quase sempre errado para sistemas grandes e críticos. As reescritas completas subestimam o valor escondido no código “feio” (casos de borda, regras regulatórias, comportamentos compatíveis com bugs dos quais usuários reais dependem), levam muito mais tempo que o projetado, não entregam valor até o fim e são frequentemente canceladas depois de um gasto enorme. Adote por padrão a modernização incremental. Reserve as reescritas para os casos em que a plataforma é genuinamente insustentável e os caminhos incrementais estão esgotados. Mesmo então, decomponha a reescrita em peças entregáveis de forma independente pelo padrão estrangulador em vez de um único lançamento em big-bang. Quando a liderança pressiona por uma reescrita total, insista na pergunta: que valor é entregue nos primeiros três meses, e o que acontece se o programa for parado na metade?

Compromissos: prós e contras

Abordagem	Prós	Contras
Figueira-estranguladora (incremental)	Valor contínuo, baixo risco, reversível, mantém o serviço funcionando	Cronograma geral mais longo, é preciso rodar dois sistemas em paralelo, custo de integração
Reescrita em big-bang	Folha em branco, sem restrições legadas no código novo	Taxa de fracasso muito alta, nenhum valor até o fim, custo enorme, regras de negócio perdidas
Encapsular (envolver com APIs)	Rápido, baixo risco, moderniza o acesso sem tocar no núcleo	O núcleo continua legado. Adia, não resolve, o risco subjacente
Deixar como está (custódia)	Sem risco de projeto. O mais barato no curto prazo	O risco de conhecimento e de plataforma continua se acumulando. Ação forçada eventual

A troca fundamental é velocidade de transformação versus risco de fracasso, e a modernização de legados é o domínio em que essa troca é mais desequilibrada. A reescrita em big-bang “rápida e limpa” é uma miragem que repetidamente produz o desfecho mais lento e mais caro de todos: um programa cancelado e um sistema ainda não modernizado. As abordagens incrementais parecem mais lentas e exigem rodar dois sistemas em paralelo, mas entregam valor o tempo todo, mantêm o risco pequeno e reversível e são o caminho empiricamente confiável. O juízo genuíno está entre cuidar de um sistema legado estável por mais um tempo e começar a substituição incremental agora. Deixe a trajetória de risco conduzir essa decisão, especialmente o risco de conhecimento, em vez do desconforto com a tecnologia antiga.

Perguntas para discutir com sua equipe

Vocês têm um lugar para pôr uma camada de roteamento na frente do seu sistema legado e, se não, o que seria preciso para criar um? A figueira-estranguladora depende de uma costura: um gateway de API, uma fachada ou um proxy pelo qual vocês possam redirecionar uma capacidade por vez para uma nova implementação. Muitos sistemas antigos não têm tal costura, então o primeiro incremento de modernização costuma ser apenas construir o ponto de interceptação, e esse trabalho é fácil de subestimar. Levem o mapa atual de integração e perguntem onde o tráfego poderia ser interceptado por capacidade sem uma virada em big-bang. Se não há lugar nenhum, a ramificação por abstração numa costura interna pode ser o movimento inicial. Sem uma camada de roteamento vocês não têm caminho incremental, que é exatamente como as organizações são empurradas de volta para a reescrita que costuma fracassar.
Vocês realmente plotaram o seu parque numa grade de risco versus valor, ou o seu roteiro é conduzido pelo sistema que parece mais velho? O capítulo insiste em modernizar primeiro o que é de alto risco e alto valor e em deixar deliberadamente em paz os sistemas estáveis, de baixa mudança e bem compreendidos mesmo quando são antigos. Sem uma grade explícita, a atenção flui para a reclamação mais barulhenta ou a tecnologia menos na moda, e as genuínas bombas-relógio (um sistema crítico com dois mantenedores perto da aposentadoria) esperam. Pontuem cada sistema por criticidade de negócio, risco técnico, frequência de mudança e risco de conhecimento e depois sequenciem a partir do canto superior direito. Levem essa grade à reunião como o mapa compartilhado. O risco de conhecimento merece o peso maior, porque é a única entrada que só piora e que não pode ser comprada de volta depois que as pessoas vão embora.
Quando vocês fizerem a virada, como provarão que nem um único registro foi perdido ou alterado, e quem assina essa evidência? A migração de dados é onde esses projetos morrem, e a confiança vem da conciliação: contagens de linhas, somas de verificação e totais de controle de negócio que coincidem entre o antigo e o novo, mais a execução em paralelo que compara as saídas sobre as mesmas entradas até concordarem com um limiar alto. Para um sistema de benefícios ou de livro-razão, uma discrepância é um cidadão pago a menos ou um centavo perdido, então a evidência precisa satisfazer um auditor, não apenas um engenheiro. Decidam agora quais totais conciliarão, que limiar de confiança dispara a virada e por quanto tempo rodarão o antigo e o novo em paralelo. Mantenham a reversão disponível o tempo todo e façam a virada em fatias e não de uma vez. As discrepâncias que vocês encontram durante a execução em paralelo costumam ser regras legadas não documentadas que vocês precisam preservar, então tratem cada uma como uma descoberta, e não apenas um defeito.
Quais dos seus sistemas legados vocês estão custodiando versus substituindo ativamente, e quem decidiu qual é qual? O capítulo traça uma linha deliberada entre os sistemas que valem estabilizar no lugar (documentando regras, acrescentando testes de caracterização, treinando mantenedores em rodízio) e os que valem substituir de forma incremental, e os dois exigem financiamento e pessoal muito diferentes. Para uma grande organização o perigo é a deriva: um sistema rotulado “custódia por ora” vira em silêncio “custódia para sempre” até o último mantenedor se aposentar e a escolha ser feita por vocês sob crise. As considerações concorrentes são o custo da custódia e a obsolescência da plataforma de um lado contra o risco e a perturbação da substituição do outro, e o risco de conhecimento deve pender a balança porque só piora. Levem a grade de risco versus valor, o número de mantenedores e o horizonte de aposentadoria de cada sistema e um responsável explícito pela decisão entre custodiar e substituir. Em parques corporativos e governamentais, nomeiem uma cadência de revisão e uma autoridade responsável por cada sistema, porque uma classificação que ninguém revisita é uma decisão que ninguém está tomando.
Quando a liderança pede uma reescrita completa, qual é a sua resposta de praxe, e vocês conseguem mostrar o que um caminho incremental entrega nos primeiros três meses? A reescrita em big-bang é o modo de falha padrão, e ainda assim continua sendo financiada porque um recomeço limpo é fácil de vender e uma figueira-estranguladora não é. Uma equipe grande precisa de uma resposta ensaiada para que o argumento seja ganho com evidências e não por quem for mais sênior na sala. A tensão genuína é que algumas plataformas realmente são insustentáveis e uma reescrita se justifica, então a resposta não pode ser uma recusa geral: precisa pesar se ainda existem costuras incrementais contra o custo real de manter a plataforma antiga viva. Levem o valor que um primeiro incremento incremental entregaria, a taxa histórica de fracasso de reescritas comparáveis e uma decomposição de qualquer reescrita proposta em peças entregáveis de forma independente. No governo, onde um programa cancelado de vários anos queima dinheiro público à vista de todos, insistam em que qualquer reescrita entregue valor cedo e sobreviva a ser parada na metade sem perda total.
Como vocês capturarão as regras de negócio trancadas no seu código mais antigo antes que as pessoas que as entendem tenham ido embora? Boa parte do valor de um sistema legado é comportamento não documentado que décadas de casos de borda, regulamentações e correções compatíveis com bugs acumularam, e ele vive num grupo minguante de especialistas que se aposentam e não em algum registro escrito. Para uma grande organização este é o único risco que não pode ser comprado de volta depois que as pessoas saem, então merece financiamento antes do trabalho de plataforma, mais visível. A atração concorrente é que a captura de conhecimento (documentação, testes de caracterização, engenharia reversa, treinamento em rodízio) parece custo que não entrega nada, que é exatamente por que é adiada. Levem um inventário de quem detém o conhecimento crítico, quão perto estão de sair e que cobertura de testes fixa o comportamento atual hoje. Em contextos regulamentados e públicos, tratem as regras estatutárias codificadas no código antigo como um ativo de conformidade: perdê-las em silêncio não é uma dívida técnica, é uma exposição jurídica.

Perspectiva por setor

Startup. O seu legado é o seu próprio MVP apressado, não um mainframe: um protótipo que agora carrega receita e que todos temem tocar. Não o reescreva. Envolva o módulo mais assustador atrás de uma interface limpa, acrescente testes de caracterização para fixar o comportamento dele e tire funcionalidades de dentro dele de forma incremental, para que cada pequeno lançamento entregue valor e reduza o risco. Você não tem pista para uma reconstrução do zero, então a opcionalidade importa mais que a elegância.

Pequena empresa. Você não tem equipe de modernização e tem orçamento apertado, então o movimento prático costuma ser manter funcionando um sistema que funciona: capture o que a pessoa que o entende sabe, ponha-o no controle de código-fonte com alguns testes automatizados e apoie-se num fornecedor ou num produto pronto em vez de uma reconstrução sob medida. Enquadre a decisão como comprar versus construir e prefira comprar quando a capacidade é uma commodity. Gaste o seu esforço limitado no único sistema cuja falha pararia o negócio, e não no que simplesmente parece mais velho.

Grande empresa. O problema é a escala de portfólio: dezenas de sistemas, muitas equipes e risco de conhecimento em todo o parque. Conduza uma avaliação compartilhada de risco versus valor, padronize os padrões incrementais (figueira-estranguladora e ramificação por abstração) e trate a migração de dados e a execução em paralelo como disciplinas de primeira classe, com uma conciliação em que todos confiem. Governe a modernização como um portfólio contínuo contra a trajetória de risco e não como um amontoado de projetos heroicos e orce explicitamente a custódia e a captura de conhecimento para que nenhum sistema crítico dependa de um único mantenedor que se aposenta.

Governo. As obrigações estatutárias codificadas ao longo de décadas, as regras de contratação e os serviços ao cidadão que não podem ser interrompidos tornam especialmente perigosa a substituição em big-bang. Favoreça a migração incremental por figueira-estranguladora com virada fatia a fatia, prove por conciliação e por longa execução em paralelo que nenhum registro de cidadão foi perdido ou calculado errado e mantenha a reversão disponível o tempo todo. A contratação deve exigir portabilidade de dados e divulgação das regras de negócio em vez de tradução opaca, e qualquer programa de vários anos deve entregar valor auditável cedo e resistir ao escrutínio público se for parado no meio.

Exemplos

Startup. O MVP original de uma startup de três anos virou um tipo próprio de legado: um protótipo apressado que agora trata receita real e que todos têm medo de tocar. Em vez de uma reescrita, a equipe envolve o pior módulo atrás de uma interface limpa, acrescenta testes de caracterização para fixar seu comportamento atual e move funcionalidades para fora dele, peça por peça, ao longo de alguns meses. Cada pequeno lançamento entrega valor e encolhe a parte assustadora, de modo que a startup obtém um sistema mantível sem apostar a empresa numa reconstrução do zero que não pode bancar.

Grande empresa. Uma grande seguradora opera a administração de apólices num sistema COBOL de mainframe confiável mas caro de mudar e mantido por um punhado de engenheiros perto da aposentadoria. Em vez de uma reescrita, a seguradora envolve o mainframe com APIs modernas e aplica a figueira-estranguladora: as novas capacidades de cotar-e-comprar e de autoatendimento são construídas numa plataforma moderna e roteadas por uma fachada, enquanto os registros centrais de apólices permanecem no mainframe. Em paralelo, a equipe documenta as regras de negócio e acrescenta testes de caracterização ao redor do COBOL. Ao longo de vários anos, capacidade após capacidade sai do mainframe, cada lançamento entregando valor, até o núcleo restante poder ser aposentado nos termos da seguradora e não sob crise.

Governo. Uma agência de seguridade social precisa modernizar um sistema de cálculo de benefícios de décadas que paga milhões de cidadãos e não pode ser interrompido nem pagar errado. Ela rejeita uma substituição em big-bang depois de estudar programas comparáveis que fracassaram. Em vez disso, faz o profiling e a limpeza dos dados, constrói uma migração automatizada com conciliação completa contra totais de controle e roda o novo motor de benefícios em paralelo com o antigo por muitos meses, alimentando ambos com os mesmos pedidos e comparando cada cálculo, investigando cada discrepância (muitas vezes revelando regras legadas não documentadas que precisam ser preservadas). Só quando o novo sistema coincide com o antigo com uma confiança muito alta é que ela faz a virada tipo de benefício por tipo de benefício, mantendo a reversão o tempo todo. A fachada estranguladora permite aos cidadãos ver um serviço contínuo durante a transição.

Justificativa de negócio: motivações, ROI e TCO

A modernização de legados tem uma justificativa de negócio incomum, porque o maior custo muitas vezes é o custo da inação e o maior risco é o próprio projeto de modernização. Os custos crescentes de não modernizar são concretos: manutenção e licenciamento crescentes em plataformas obsolescentes, uma força de trabalho especializada cada vez mais escassa e cara, incapacidade de atender depressa a novas demandas regulatórias ou de serviço e exposição crescente a uma falha catastrófica sem ninguém restante que entenda o sistema. Contra isso, o custo da modernização é alto, e feita em big bang carrega uma probabilidade genuinamente alta de fracasso. É precisamente por isso que a abordagem incremental importa para o ROI: ela converte uma única grande aposta numa série de pequenas, cada uma devolvendo valor e podendo ser interrompida.

Defenda o caso junto à liderança reenquadrando a escolha. A pergunta não é “modernizar ou não”. É “modernizar de forma incremental agora, ou pagar custos crescentes de custódia e enfrentar uma modernização forçada e de maior risco depois, sob crise”. Quantifique o TCO do status quo (custos de plataforma e de licença, o ágio por habilidades escassas, o custo ponderado pelo risco de uma queda irrecuperável) e compare-o com um programa em fases que reduz risco e custo a cada incremento mantendo o serviço funcionando. De forma crítica, insista em que qualquer reescrita proposta seja estruturada para entregar valor cedo e com frequência. Um programa que não entrega nada por três anos e pode ser cancelado com perda total não é um investimento: é uma aposta. O argumento de ROI mais forte para a abordagem estranguladora é a opcionalidade: o valor é entregue continuamente e a organização pode ajustar o curso a qualquer momento.

Antipadrões e armadilhas

A reescrita em big-bang. Substituição de tudo ou nada, de vários anos, que não entrega valor até o fim e é frequentemente cancelada a grande custo.
Reescrever sem entender. Substituir código cujas regras de negócio nunca foram documentadas, descartando em silêncio casos de borda dos quais usuários reais e leis dependem.
Subestimar os dados. Tratar a migração de dados como reflexão tardia quando é a parte mais difícil e arriscada do projeto.
Pular a execução em paralelo. Virar para o novo sistema sem comparação em paralelo, descobrindo discrepâncias só depois que afetam pessoas reais.
Tradução automática como solução. Traduzir COBOL por máquina para uma linguagem moderna e achar que o trabalho está feito, produzindo código incompreensível que reproduz a lógica antiga literalmente.
Modernizar por idade, não por risco. Gastar esforço em sistemas velhos mas estáveis enquanto sistemas de alto risco e de muita mudança esperam.
Perder o conhecimento. Deixar os últimos mantenedores se aposentarem sem capturar as regras de negócio e acrescentar testes de caracterização.
Sem reversão. Fazer a virada sem caminho de volta quando o novo sistema se comporta mal sob carga e dados reais.

Modelo de maturidade

Nível 1: Iniciar. Os sistemas legados são temidos e congelados. A mudança é evitada. Não existe inventário nem avaliação de risco. A modernização, quando tentada, é uma reescrita ad hoc de tudo ou nada conduzida pela frustração. O conhecimento vive em poucas cabeças que se aposentam, sem nada escrito.
Nível 2: Desenvolver. Algumas equipes têm um inventário e uma noção aproximada de risco, e alguns sistemas legados são envolvidos com APIs para acesso. Os padrões incrementais são conhecidos mas aplicados de forma desigual, e o pensamento ainda deriva para reescritas em big-bang. A migração de dados é tentada mas subestimada, e a prática varia muito de equipe para equipe.
Nível 3: Padronizar. Os sistemas são priorizados por risco e valor segundo um método documentado para toda a organização. Os padrões incrementais (figueira-estranguladora, ramificação por abstração) são o padrão imposto, e toda modernização segue um manual padrão. A migração de dados é um esforço planejado e conciliado, com execução em paralelo antes da virada, e a captura de conhecimento e os testes de caracterização são prática exigida e não opcional.
Nível 4: Gerenciar. A modernização é medida e controlada com dados. O parque carrega linhas de base: o número de mantenedores e o horizonte de aposentadoria por sistema, a cobertura de testes de caracterização, as taxas de aprovação da conciliação de migração, as contagens de discrepâncias na execução em paralelo e o valor entregue por incremento, tudo acompanhado em relação a metas. As decisões entre custodiar e substituir e os pontos de seguir ou não na virada são tomados com base nessa evidência, e um sistema que passa do seu limite de risco de conhecimento dispara ação em vez de esperar por uma crise.
Nível 5: Orquestrar. A modernização é contínua, integrada ao planejamento de negócio e de risco e adaptativa. O portfólio é reequilibrado contra a trajetória de risco (especialmente o risco de conhecimento) à medida que ela muda, a substituição incremental é rotineira e sem drama, cada incremento entrega valor e é reversível, e a organização conduz o ritmo deliberadamente. As lições de cada migração realimentam o manual compartilhado, de modo que todo o parque melhora com o tempo.

Ideias para discussão

Para o seu sistema legado mais crítico, quantas pessoas ainda conseguem mantê-lo, e quão perto estão de sair?
Onde vocês são tentados por uma reescrita em big-bang, e que valor uma abordagem incremental poderia entregar nos primeiros três meses em vez disso?
Quão bem estão documentadas as regras de negócio dos seus sistemas mais antigos, e o que acontece com elas se o código for substituído?
Vocês fizeram o profiling dos dados que precisariam migrar, e sabem o quão sujos e emaranhados eles realmente são?
Em quais sistemas velhos mas estáveis vocês estão gastando energia de modernização que poderiam deixar em paz com segurança?
Vocês conseguiriam rodar o novo sistema em paralelo com o antigo e provar que concordam antes de fazer a virada?

Principais conclusões

Legado significa valioso e fundamental. Respeite e entenda um sistema antes de mudá-lo.
Modernize de forma incremental com a figueira-estranguladora e a ramificação por abstração, entregando valor continuamente e mantendo cada mudança pequena e reversível.
Trate a reescrita em big-bang como o modo de falha padrão. Reserve-a para plataformas genuinamente insustentáveis e mesmo então decomponha-a.
Priorize por risco e valor (especialmente o risco de conhecimento), não por idade. Alguns sistemas antigos são melhor custodiados do que substituídos.
A migração de dados e a execução em paralelo são o coração do esforço. Faça o profiling, concilie, rode em paralelo e mantenha a reversão.
O argumento de negócio mais forte é a opcionalidade: a modernização incremental converte uma grande aposta arriscada em muitas pequenas que devolvem valor.

Referências e leitura complementar

Michael Feathers, Working Effectively with Legacy Code
Martin Fowler, “StranglerFigApplication” and “BranchByAbstraction”
Sam Newman, Monolith to Microservices
Nicholas Carr / industry studies on mainframe and COBOL dependency (context on the scale of legacy estates)
Robert Annett, Working with Legacy Systems
Eric Evans, Domain-Driven Design (anti-corruption layer)
Gregor Hohpe, Enterprise Integration Patterns and The Software Architect Elevator
Standish Group CHAOS Report (evidence on large project and rewrite failure rates)