Aposentar sistema legado: plano para desligar sem quebrar nada

Por que sistema legado nao morre sozinho

Todo parque de TI com mais de uma decada carrega pelo menos um sistema que ninguem quer tocar. Roda em servidor antigo, depende de versao de banco fora de suporte, tem uma integracao que alguem escreveu em 2013 e nunca documentou. A equipe sabe que precisa sair do ar, mas cada tentativa esbarra na mesma pergunta: quem ainda usa isso? Sem resposta confiavel, o projeto trava e o sistema segue consumindo licenca, backup, janela de manutencao e superficie de ataque.

O custo de manter um legado ligado raramente aparece numa linha unica do orcamento. Ele se dilui: o host que nao pode ser atualizado porque a aplicacao quebra, o firewall com regra permissiva para um protocolo antigo, o storage que guarda quinze anos de historico que ninguem consulta, as horas de suporte gastas em chamados que so aquele sistema gera. Quando somado, o legado costuma custar mais parado do que custaria migrar de vez.

O erro comum e tratar o desligamento como evento — marcar uma data, desligar e torcer. Desativacao de aplicacao e processo, com fases mensuraveis e criterio objetivo de saida. O plano abaixo descreve esse metodo em quatro etapas: mapear dependencias, congelar entrada, migrar historico e provar ausencia de uso.

Etapa 1 — Mapear dependencias antes de qualquer coisa

Mapear dependencia de legado nao e ler documentacao, e observar trafego. Documentacao envelhece; pacote na rede nao mente. O inventario precisa cobrir tres camadas: quem chama o sistema, o que o sistema chama, e o que ele escreve em disco ou em outro banco. Sem essas tres, o desligamento sempre revela um consumidor esquecido no pior momento possivel.

Ferramentas simples resolvem a maior parte. Logs de acesso do servidor web, conexoes ativas via netstat ou ss, contadores de sessao no banco de dados, logs de autenticacao do diretorio, regras de firewall que citam o IP do host. Rodar coleta por trinta dias corridos cobre ciclos mensais — fechamento contabil, folha, faturamento — que uma amostra de uma semana perde inteira.

• Consumidores humanos: contas que fizeram login nos ultimos 90 dias, agrupadas por setor e frequencia.
• Consumidores tecnicos: jobs agendados, scripts de ETL, servicos que autenticam com conta de servico, integracoes por API ou arquivo em pasta compartilhada.
• Dependencias de saida: bancos externos, servidores SMTP, servicos de terceiros, licencas ancoradas em MAC address ou hostname.
• Artefatos silenciosos: relatorios que caem numa pasta e sao lidos por outra ferramenta, arquivos gerados para importacao manual, e-mails automaticos que alguem usa como gatilho.
• Amarras de infraestrutura: entradas de DNS, certificados, regras de NAT, reservas de DHCP, rotas estaticas criadas so para aquele host.

O resultado dessa etapa e uma lista nominal com responsavel por item. Dependencia sem dono nao entra no plano — vira pendencia para o gestor da area resolver. Esse detalhe evita o cenario classico do desligamento adiado porque "tem um relatorio que talvez alguem use".

Etapa 2 — Congelar a entrada e parar de alimentar o legado

Congelamento de entrada significa que o sistema continua legivel, mas deixa de receber dado novo. E o passo que transforma um alvo movel em alvo parado. Enquanto o legado grava, qualquer migracao de historico vira corrida contra o proprio sistema: o extrato exportado ontem ja esta desatualizado hoje, e a validacao nunca fecha.

Na pratica, congelar tem gradacao. Comeca por bloquear cadastro de registro novo mantendo edicao do existente, depois bloqueia edicao mantendo consulta, e por fim restringe consulta a um grupo pequeno de auditores. Cada degrau precisa de aviso formal com data e canal alternativo indicado — se o usuario nao sabe onde fazer o que fazia ali, ele vai abrir chamado pedindo o sistema de volta, e o projeto perde tracao politica.

Sistema legado em modo somente-leitura ja entrega metade do beneficio do desligamento: para de gerar dado novo para migrar, para de exigir janela de manutencao critica e para de ser porta de entrada para escrita nao auditada.

Durante o congelamento, vale ligar registro de auditoria detalhado. Cada leitura passa a ser logada com usuario, horario e recurso acessado. Esse log e a materia-prima da etapa final — a prova de que ninguem mais usa. Sem ele, a decisao de desligar volta a ser opiniao.

Etapa 3 — Migrar historico com criterio, nao com tudo

A tentacao natural e migrar o banco inteiro para o sistema novo. Quase sempre e desperdicio. Historico de legado tem tres destinos possiveis e a maior parte cabe no segundo: dado operacional que precisa estar vivo no sistema novo, dado de consulta que so precisa estar recuperavel, e dado que so existe por inercia e pode ser descartado dentro da politica de retencao.

Separar esses tres exige conversa com quem responde pelo processo, nao so com TI. A pergunta util nao e "voces querem manter?" — a resposta sera sempre sim. A pergunta util e: "nos ultimos doze meses, quantas vezes voces consultaram registro anterior a tal data, e o que aconteceria se a consulta levasse dois dias em vez de dois segundos?". Isso separa necessidade real de conforto.

1. Dado quente: migra para o sistema novo com mapeamento de campo documentado e conferencia por amostragem estatistica, nao por conferencia total.
2. Dado frio: exporta em formato aberto e durável — CSV com dicionario de dados, PDF/A para documentos, dump SQL com script de restauracao testado. Guarda em storage com retencao definida e teste de restore anual.
3. Dado descartavel: elimina conforme politica de retencao e exigencia legal ou regulatoria aplicavel ao setor, com registro formal do descarte.

O ponto critico e a validacao. Migracao sem prova de integridade e transferencia de risco, nao resolucao. Contagem de registros por tabela e por periodo, soma de valores em campos numericos chave, comparacao de amostra aleatoria campo a campo e teste de leitura pelo usuario final antes do aceite. O aceite precisa ser assinado por quem responde pelo processo — TI valida a tecnica, a area valida o negocio.

Etapa 4 — Provar ausencia de uso e desligar em degraus

Desligar de uma vez e o metodo que mais gera trauma organizacional. O caminho seguro e a degradacao progressiva, onde cada degrau e reversivel em minutos e o proximo so acontece depois de um periodo de silencio comprovado.

Uma sequencia que funciona bem: primeiro reduzir o acesso ao grupo minimo por trinta dias e monitorar o log de auditoria. Se aparecer acesso, investiga quem e por que — geralmente e uma dependencia que escapou do mapa. Silencio total, avanca. Segundo degrau: desligar a aplicacao mantendo o servidor ligado e o banco intacto, por mais quinze a trinta dias. Terceiro: desligar a VM inteira mantendo o disco. Quarto: snapshot final, backup verificado com restore testado e remocao definitiva.

• Cada degrau tem data, responsavel e procedimento de reversao escrito antes de executar.
• Comunicacao vai para todos os usuarios mapeados na etapa 1, com canal direto para reportar quebra.
• Chamado aberto citando o sistema durante a janela para o relogio do degrau — nao anula o plano, so adia o proximo passo.
• Ao final, limpeza de rastros: DNS, certificados, contas de servico, regras de firewall, jobs de backup, entradas de monitoramento e licencas canceladas.

A limpeza final e a parte mais esquecida e a que mais gera confusao futura. Conta de servico orfa com senha antiga e vetor de ataque; regra de firewall apontando para IP reciclado abre acesso indevido; job de backup rodando sobre volume inexistente polui alerta e treina a equipe a ignorar falha. Desligamento so termina quando o inventario nao tem mais nenhuma linha citando aquele sistema.

Erros que fazem o projeto fracassar

O primeiro e comecar pelo sistema novo. Empresa contrata substituto, implanta em paralelo e deixa o legado ligado "so por enquanto". Sem congelamento de entrada e sem data de corte, o paralelo vira permanente: parte da operacao fica em um, parte no outro, e agora sao dois sistemas para manter em vez de um. Data de corte definida antes da implantacao evita esse limbo.

O segundo e subestimar dependencia invisivel. O relatorio que cai numa pasta de rede e alimenta uma planilha do financeiro nao aparece em nenhum diagrama de arquitetura, mas quebra o fechamento do mes. Por isso o mapeamento precisa de observacao real de trafego e arquivo, e nao apenas de entrevista com a equipe tecnica.

O terceiro e tratar backup do legado como arquivo morto sem testar restauracao. Fita, disco ou nuvem, se o restore nunca foi exercitado, o historico nao existe — existe uma esperanca de historico. Antes de apagar o original, restaurar em ambiente isolado e abrir os dados e requisito, nao zelo excessivo.

O quarto e ignorar o lado humano. Sistema antigo costuma ter um usuario que domina cada atalho e vira referencia informal da area. Se essa pessoa nao for envolvida desde o mapeamento, ela vira obstaculo por instinto de preservacao. Envolvida cedo, vira a melhor fonte de dependencia oculta que existe na empresa.

Como a Duk conduz desativacao de legado

Aposentar sistema legado exige duas coisas que raramente coexistem na equipe interna: tempo dedicado para o mapeamento e conhecimento de infraestrutura profundo o bastante para nao quebrar o que esta ao redor. A Duk Informatica & Cloud atua nesse tipo de projeto ha mais de 18 anos, com mais de 550 empresas atendidas em ambientes que vao de servidor unico a parque multi-site com integracao hibrida.

Na pratica, o trabalho comeca com inventario tecnico do ambiente — dependencias de rede, contas de servico, jobs, integracoes e amarras de licenciamento — seguido de plano de desligamento em degraus com data e procedimento de reversao para cada etapa. A migracao de historico usa o data center proprio em Alphaville quando o dado precisa continuar acessivel, e a condicao Microsoft Gold Partner cobre os casos em que o destino natural e Microsoft 365, Azure ou servidor de arquivos moderno com controle de acesso adequado.

O acompanhamento continua depois do desligamento: monitoramento com SLA para captar qualquer processo que ainda tente conversar com o sistema removido, e suporte 24/7 durante as janelas criticas de corte. O objetivo e simples — no fim do projeto, o legado nao aparece mais em nenhum inventario, nenhuma regra de firewall, nenhum job de backup, e ninguem sentiu falta. Se a sua empresa convive com um sistema que todo mundo sabe que deveria sair do ar, vale comecar pelo mapeamento: e barato, nao quebra nada e ja mostra o tamanho real do problema.