Resposta direta
O sistema antigo continua no ar porque alguém ainda retira dele uma informação que não existe em outro lugar. O ponto de partida é listar cada consulta feita, quem a faz, com que frequência e o que acontece se ela faltar. Cada uma se encaixa em uma de três categorias: pode virar relatório congelado, pode migrar para o sistema atual, ou precisa do legado vivo. A definição de quem responde pela base e de quem revisa essa lista vem depois. Sem o inventário, a discussão vira preferência técnica; com ele, vira decisão sobre acesso a dado histórico.
- Objetivo
- Organizar um processo
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata o legado como acesso a dado histórico com dono e revisão, e não como problema de tecnologia a ser substituído.
O que a consulta ao histórico realmente exige
Boa parte das leituras do sistema antigo repete sempre o mesmo recorte, no mesmo período, e aceita virar relatório fixo. Esse tipo de consulta não precisa do sistema ligado, apenas do resultado guardado em local confiável.
O que não aceita congelamento é a consulta que cruza dado antigo com dado que muda hoje. Essa é a que decide se o legado precisa seguir operando.
Separar as duas coisas evita tratar manutenção e desligamento como a mesma decisão.
Quem responde pela base herdada
Enquanto o sistema está no ar, alguém precisa responder por ele. Sem dono definido, cada erro de leitura vira investigação sem responsável e o sistema sobrevive por inércia.
Nomear o responsável pela base antiga e pelo inventário de consultas é mais útil do que fixar uma data de desligamento. A data depende do inventário, não o contrário.
A revisão da lista precisa de periodicidade definida, para que consultas extintas saiam do escopo e o custo de manter o legado acompanhe o uso real.
O que essa organização não resolve
Organizar as consultas não corrige divergência entre o dado antigo e o atual, nem decide a migração de histórico. São trabalhos distintos, com critérios próprios.
Se a consulta depende de informação que só existe na base antiga e não pode ser reproduzida, o sistema continua necessário. O inventário apenas torna essa dependência explícita e mensurável.
Também não define prazo de desligamento nem economia de custo. Ele sustenta a decisão de manter, migrar ou congelar com o que foi efetivamente consultado.
Recurso prático
Fluxo para definir o que o sistema antigo precisa continuar respondendo
- Levantar cada consulta feita ao sistema antigo, identificando a tela, o relatório ou a extração que a origina.
- Registrar quem faz a consulta, qual decisão ela alimenta e que outra fonte poderia responder por ela.
- Classificar a consulta em relatório congelado, migrável para o sistema atual, ou dependente do legado vivo.
- Bloquear novas gravações e manter a base antiga em modo somente leitura.
- Nomear quem responde por dúvidas sobre a base antiga e quem revisa a lista de consultas.
- Marcar a data de revisão do inventário, separada da data de desligamento.
O erro mais comum é bloquear a escrita antes de saber quem lê. O acesso de leitura costuma ser a razão de o sistema continuar sendo mantido.
Sobre o que está escrito aqui
Conceitos relacionados: sistema legado · consulta histórica · modo somente leitura · inventário de acessos · retenção de dados. Exemplos são ilustrativos. Não há cliente, resultado, preço, prazo ou certificação nesta página. Quando o formato indicado é Projeto de implementação, ele descreve uma possibilidade de trabalho — a conversa inicial avalia contexto e aderência.
Para continuar
- Integrações, sistemas e qualidade de dados — Página central do tema
- Sistemas desconectados: métricas para dimensi… — sistemas desconectados
- Sistemas isolados: o que checar antes de comp… — sistemas desconectados
Páginas relacionadas
O mesmo problema em outro objetivo
- Sistema antigo mantido pelo histórico: o que ele ainda faz — Diagnosticar
- Sistema antigo só pelo histórico: comparar alternativas — Comparar alternativas
- Sistema antigo mantido só pelo histórico: como medir — Explicar medição
- Sistema antigo só de histórico: o que sai da operação — Orientar implementação
- Sistema antigo mantido só pelo histórico: o que exigir — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Sistema novo sem desligar o antigo: o que decidir antes — O que definir antes de ligar um sistema novo para que o antigo possa ser desligado: data, responsável, critério de corte e o que ainda depende dele.
- Cópia de base sem versão: o que exigir na contratação — Critérios operacionais e contratuais para contratar cópias de bases de dados quando não há controle de versão nativo no fornecedor.
- Exclusão sem trilha: o que exigir antes de contratar — O que um sistema precisa registrar em cada exclusão e o que o contrato deve cobrir antes da assinatura, incluindo acesso ao histórico.
- Sistemas que ninguém desliga: como avaliar o custo — Mostra como levantar dependências, obrigações e responsáveis que mantêm um sistema ativo sem prazo definido, antes de decidir desligar, congelar ou manter.
- Migração que não anda: como separar dado, processo e decisão — Separa as causas que travam uma migração, entre dado, processo e responsabilidade, e indica o que medir antes de decidir o corte.