Insights · Modernização de legado

Maturidade em modernização de legado: 4 níveis e autodiagnóstico

Publicado em 15 de outubro de 2026

Maturidade em modernização de legado não é o quanto a empresa fala de nuvem ou de IA. É o quanto ela consegue decidir, repetir e acompanhar a troca de sistemas antigos sem perder a regra de negócio. Este texto propõe o Diagnóstico Ithaca de maturidade em modernização, em quatro níveis, com sinais observáveis e um checklist para você marcar sozinho. Não confundir com a escala de autonomia de agentes de código (níveis 0 a 5 de Shapiro): lá o eixo é o agente; aqui o eixo é a organização diante do legado.

A definição de sistema legado e os sinais de risco estão em Sistema legado: o que é, sinais de risco e quando modernizar. O passo a passo depois da decisão está em Como modernizar um sistema legado: guia passo a passo. A conta de custo, em Custo da dívida técnica: quanto a empresa paga, e como estimar. Aqui o foco é só: em que nível você está, o que falta e qual o próximo passo realista.

Por que medir maturidade antes de modernizar

Modernizar sem saber o ponto de partida costuma produzir um de dois erros: um projeto único que some depois do go-live, ou uma sequência de apagar incêndio que nunca vira capacidade. O guia público The Code Modernization Playbook, da Anthropic (fornecedor de modelos de IA para esse tipo de trabalho), descreve uma progressão semelhante em quatro estágios, do atendimento só sob crise até práticas contínuas. Não copiamos os nomes nem a tabela do ebook. Usamos a ideia de progressão e montamos um diagnóstico próprio, com linguagem de quem opera legado no Brasil.

Dois números já no ar no site dão escala ao problema, sem substituir a sua medição. Parte já aparece em sistema legado: o que é e em custo da dívida técnica; aqui entram enxutos porque esta URL precisa da ordem de grandeza.

A consultoria Protiviti, que também vende modernização, ouviu 1.050 executivos de tecnologia na Global Technology Executive Survey de 2023. Quase 70% das organizações disseram que a dívida técnica tem alto impacto na capacidade de inovar. Nos setores com índice mais alto, biotecnologia e dispositivos médicos (82%), telecomunicações (81%) e serviços financeiros (78%). São respostas declaradas, de empresas grandes; não medição.
O relatório The Developer Coefficient (Stripe e Harris Poll, setembro de 2018) separa duas perguntas: 17,3 horas de uma semana média de 41,1 estimadas em manutenção; 13,5 horas na pergunta explícita de dívida técnica. Estimativa declarada, não telemetria. Nunca misture os dois rótulos.

Como regra prática de prontidão, o mesmo playbook da Anthropic sugere que times com mais de 40% do tempo em manutenção (em vez de entrega nova) têm um sinal claro de que modernizar pode valer a pena. É critério de fornecedor, não norma de mercado. Serve para o autodiagnóstico abaixo, com o rótulo certo.

A comparação entre migrar e modernizar está em lift and shift vs modernização. O que fazer quando falta gente de COBOL, Delphi ou VB6 está em falta de desenvolvedor COBOL, Delphi e VB6. Neste texto o eixo é só o nível de maturidade da organização.

O Diagnóstico Ithaca (visão geral)

O Diagnóstico Ithaca de maturidade em modernização classifica a organização em um de quatro níveis. Não é produto SaaS, nem score comprado: é um mapa para conversa de diretoria e de engenharia. Cada nível tem sinais observáveis, o que tipicamente falta e um próximo passo que cabe no calendário real.

Nível	Nome	Em uma frase
1	Reativo	Só se mexe no legado quando quebra, alguém se aposenta ou o regulador aperta o prazo
2	Por projeto	Há projetos anuais com orçamento, mas cada um reinventa o método e o inventário é raso
3	Com método	Processo repetível, inventário vivo, métricas e testes de caracterização antes de cortar
4	Contínuo	Modernização de fundo com supervisão humana, sessão rastreável e priorização por valor

A progressão é acumulativa: o nível 3 não descarta o orçamento do 2; ele padroniza o que o 2 fazia de forma isolada. Pular do 1 ao 4 sem inventário, testes e dono costuma voltar ao 1 depois do primeiro incidente.

Nível 1 · Reativo

Sinais observáveis. O legado só entra na pauta depois de falha em produção, de um especialista anunciar saída ou de um prazo regulatório. Quando o especialista é de COBOL, Delphi ou VB6, veja o que fazer com a falta de desenvolvedor. Documentação inexistente ou espalhada em cabeças. Poucos ou nenhum teste automatizado nas partes críticas. Dívida cresce porque o time evita tocar o núcleo e empilha contornos. A fatia da semana em manutenção costuma estar alta; se passar da regra prática de 40% do playbook da Anthropic, o sinal fica ainda mais forte (lembre: é limiar de fornecedor).

O que falta. Inventário mínimo (o que existe, quem usa, criticidade). Dono nomeado. Critério escrito de quando modernizar versus quando só estabilizar. Registro do tempo gasto em manutenção versus entrega nova.

Próximo passo realista. Em duas a quatro semanas: listar os sistemas que ainda geram receita ou risco; marcar quem consegue alterá-los com segurança; registrar por duas sprints a fatia de horas em manutenção nos hotspots. Sem isso, qualquer RFP de "modernização total" é chute. Para o vocabulário do problema, volte a sistema legado: o que é.

Nível 2 · Por projeto

Sinais observáveis. Existe orçamento anual e um ou mais projetos nomeados. A escolha do alvo às vezes segue política interna mais do que valor de negócio. Cada projeto monta o próprio método: inventário raso (linhas de código, idade, criticidade sem ROI), pouca reutilização entre iniciativas, verificação humana pesada mesmo quando há ferramenta de conversão. O go-live termina e o aprendizado some com o time do projeto.

O que falta. Playbook interno compartilhado. Inventário que sobreviva ao projeto. Métricas comparáveis entre iniciativas (lead time no módulo, cobertura de testes de caracterização, horas de juros da dívida). Decisão explícita de modernizar preservando regra de negócio, em vez de só mover de servidor.

Próximo passo realista. Fechar um projeto-piloto com escopo periférico, novo ao lado do antigo, e documentar o método (mapa de regras, testes de caracterização, critério de cutover) num lugar que o próximo projeto possa ler. O guia passo a passo está em como modernizar um sistema legado. Se a conta de custo ainda não está clara para a diretoria, use o mapa de custo da dívida técnica.

Nível 3 · Com método

Sinais observáveis. Há time ou papel dedicado, processo padronizado e métricas claras. O inventário é vivo: dívida, dependências e prontidão para modernizar entram em revisão periódica. Ferramentas (incluindo agentes de código, quando houver) ajudam a documentar regras e sugerir refatoração, mas a decisão de o que vai a produção permanece humana. Existem padrões repetíveis (por exemplo, extrair um módulo, trocar uma integração, decompor um monólito) e testes automatizados que protegem a equivalência funcional nas fatias críticas.

O que falta. Às vezes falta só ritmo contínuo: o método existe, mas ainda depende de "abrir um projeto" para cada fatia. Pode faltar trilha completa de sessão (pedido, passos, modelo, custo, resultado, autoria) quando agentes entram no fluxo. Pode faltar disciplina de não tratar lift and shift como modernização (a diferença está em lift and shift vs modernização).

Próximo passo realista. Transformar o playbook em capacidade permanente: fila priorizada por juros da dívida e valor de negócio; fatias com o novo ao lado do antigo; revisão humana obrigatória antes do merge/cutover. Para sistemas que não podem parar, o método da plataforma está em Modernização de sistemas legados com IA, sem parar a operação.

Nível 4 · Contínuo

Sinais observáveis. A modernização não espera o próximo "programa". Há varredura regular de hotspots, propostas priorizadas com ROI interno, e o time humano concentra-se em estratégia, limites e aceite. Agentes de código podem acelerar leitura, testes e refatoração, desde que cada sessão seja rastreável e alguém do time do cliente leia o que vai a produção. Código morto, consultas ruins e acoplamentos conhecidos entram em fila contínua, não só em crise.

O que falta. Mesmo no nível 4, falta humildade operacional: ninguém moderniza o núcleo crítico sem equivalência comprovada. Falta também separar maturidade da organização (este diagnóstico) de autonomia do agente (Shapiro). Um time no nível 4 ainda pode operar agentes em níveis baixos de autonomia de propósito, justamente porque a supervisão é o produto.

Próximo passo realista. Não é "ligar agentes no automático". É manter o inventário, a fila e a trilha enquanto se amplia o escopo. Se a organização ainda não tem plataforma com supervisão e rastreio, o ponto de partida é implantar esse modo de trabalho, não pular para autonomia alta.

Autodiagnóstico (marque sozinho)

Responda com sim ou não. Conte os "sim". O resultado é orientativo, não um score de produto: na dúvida entre dois níveis, fique no mais baixo até ter evidência.

Bloco A · base (nível 1 → 2)

Temos lista escrita dos sistemas legados que ainda importam para receita ou risco?
Sabemos, por sistema, quem consegue alterar com segurança?
Registramos, ao menos por algumas sprints, a fatia de horas em manutenção versus entrega nova?
Nos hotspots, a fatia da semana em manutenção fica, na maior parte do tempo, abaixo de cerca de 40%? Marque sim só se estiver abaixo. Se estiver acima com frequência, marque não: isso puxa o placar para o nível 1 ou o 2. A marca de 40% é a regra prática do playbook da Anthropic (visão de fornecedor), não norma de mercado.

Bloco B · projeto → método (nível 2 → 3)

Existe orçamento e dono nomeados para modernização, não só para "manter no ar"?
O último projeto deixou método reutilizável (mapa de regras, testes de caracterização, critério de cutover)?
O inventário inclui mais do que idade e linhas de código (dependências, criticidade, prontidão)?
Antes de cortar uma fatia crítica, rodamos equivalência (novo ao lado do antigo) com critério escrito de aceite?

Bloco C · método → contínuo (nível 3 → 4)

Há fila permanente de hotspots priorizada por valor e por juros da dívida, revista em ciclo fixo?
Mudanças com apoio de agentes de código deixam trilha (pedido, passos, resultado, autoria) legível por quem não escreveu o prompt?
Pessoas do time leem e aceitam o que vai a produção; autonomia do agente não substitui o aceite?
A modernização continua entre "programas", sem precisar reinventar o processo a cada ano?

Leitura do placar

"Sim" no total	Você provavelmente está no
0 a 3	Nível 1 · Reativo
4 a 6	Nível 2 · Por projeto
7 a 9	Nível 3 · Com método
10 a 12	Nível 4 · Contínuo

Se marcou forte no bloco A e fraco no B, não force o discurso de nível 3: feche o inventário e um piloto documentado primeiro. Se marcou forte no B e no C, o gargalo costuma ser ritmo e trilha, não "mais ferramenta".

O que a Ithaca faz com o resultado

A Ithaca opera uma plataforma de desenvolvimento agentic: agentes de código leem o sistema em produção, ajudam a caracterizar o comportamento atual e constroem a parte nova ao lado. Pessoas do time do cliente definem os limites, leem o que vai para produção e ficam com o registro de cada sessão. Isso não "sobe" sozinho o nível de maturidade: torna mais barato sair do reativo e sustentar o método (níveis 2 e 3) com supervisão e rastreabilidade, que são a base do nível 4 na nossa leitura.

Se o autodiagnóstico apontou nível 1 ou 2 e você quer um primeiro corte seguro, escolha um módulo periférico de alto juro, implante a plataforma lado a lado com o seu time e use a própria fatia como prova do método.

Agendar demonstração

Perguntas frequentes

O que é maturidade em modernização de legado?

É o grau em que a organização consegue inventariar, priorizar, executar e aprender a troca de sistemas antigos sem perder a regra de negócio. Vai do atendimento só sob crise até uma capacidade contínua com supervisão humana.

Qual a diferença entre este diagnóstico e os níveis de autonomia de agentes?

Os níveis de autonomia de agentes de código (Shapiro, 0 a 5) medem quanto o agente age sozinho. O Diagnóstico Ithaca mede como a organização trata modernização de legado. São eixos ortogonais: dá para estar no nível 3 de maturidade e operar agentes com autonomia baixa de propósito.

Os quatro níveis copiam o playbook da Anthropic?

Não. O playbook da Anthropic descreve uma progressão semelhante em quatro estágios (visão de fornecedor). Os nomes Reativo, Por projeto, Com método e Contínuo, o checklist e a leitura do placar são do Diagnóstico Ithaca. Não usamos a tabela nem os rótulos do ebook como marca.

A regra dos 40% de manutenção é obrigatória?

Não. É regra prática do playbook da Anthropic, material de fornecedor. Serve como limiar de conversa. Prefira medir a fatia real do seu time por algumas sprints e comparar com o que o negócio tolera.

Como sair do nível Reativo sem parar a operação?

Comece pelo inventário e pelo registro de horas; depois um piloto periférico com o novo ao lado do antigo, testes de caracterização e cutover com critério escrito. O detalhe operacional está nas páginas de modernizar legado sem parar e no guia passo a passo.

Fontes

Anthropic, "The Code Modernization Playbook" (material de fornecedor, sem data no documento; Cap. 6: prontidão e modelo de maturidade; acessado em 15/10/2026). https://resources.anthropic.com/code-modernization-download (regra prática dos 40%; progressão em quatro estágios; não copiar tabela/nomes do ebook).
Protiviti, Global Technology Executive Survey 2023. https://www.protiviti.com/us-en/global-technology-executive-survey-tech-debt-major-burden · press release 29/03/2023: https://www.protiviti.com/gl-en/press-release-global-technology-executive-survey-results (quase 70%; 82% / 81% / 78%; n = 1.050; consultoria que vende modernização; respostas declaradas).
Stripe e Harris Poll, "The Developer Coefficient", setembro de 2018. https://stripe.com/files/reports/the-developer-coefficient.pdf (17,3 h manutenção / 41,1 h; 13,5 h dívida técnica; estimativa declarada).