Resposta direta
O ponto de partida é separar uso de dependência. Um sistema antigo continua no ar por motivos distintos. Alguém ainda opera nele. Algum processo ainda lê dados dele. O histórico é a única cópia de algo que a empresa precisa guardar. Cada caso pede uma decisão diferente. Antes de discutir desligamento, vale listar quem acessa, com que frequência, o que sai dele em consulta ou arquivo, e o que não existe em nenhum outro lugar. Sem essa lista, a conversa vira opinião sobre risco.
- Objetivo
- Diagnosticar
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Foca no sistema que ninguém quer manter e separa uso, dependência e retenção de histórico, sem tratar substituição como ponto de partida.
Uso declarado não é o mesmo que dependência real
Quem opera o sistema todos os dias costuma ser a parte visível. A dependência mais difícil está fora disso: rotinas automáticas que buscam dados, relatórios agendados, consultas feitas por outras áreas. Essas não aparecem em treinamento nem em reclamação de usuário.
Um levantamento útil começa pelo tráfego, não pela percepção. Registros de acesso, agendamentos, contas de serviço e chamados técnicos mostram o que o sistema faz sem que ninguém peça. A partir daí, cada item recebe um responsável.
O histórico costuma ser a parte que ninguém consegue substituir
Boa parte do valor de um sistema antigo está em registros que nunca foram migrados. Contratos encerrados, notas fiscais, alterações de cadastro, histórico de preço. Enquanto esses dados forem a única cópia, o desligamento fica travado por motivo legítimo, não por resistência.
Diagnosticar significa medir o tamanho desse problema. Quantos registros existem, com que idade, quais são consultados de fato, quais poderiam ser arquivados em outro meio. Sem essa medida, a retenção vira desculpa permanente.
O que esse levantamento não resolve
O levantamento mostra dependências e riscos. Não decide prioridade, orçamento nem cronograma. Também não substitui a leitura técnica do código, quando ela for necessária para saber se um dado pode ser extraído sem quebrar regra de negócio embutida.
Em sistemas com muitos anos de alteração, o comportamento real pode divergir do documentado. Nesse caso, o levantamento aponta onde investigar, mas a confirmação exige teste em ambiente controlado. Quem espera resposta definitiva de uma primeira passada costuma subestimar o esforço.
Recurso prático
Roteiro para levantar o que o sistema antigo ainda faz
- Listar todos os acessos ao sistema no período mais longo disponível, separando pessoas de rotinas automáticas.
- Para cada acesso, anotar a tarefa executada e o que ela produz: consulta, arquivo, atualização de cadastro.
- Marcar quais dessas saídas não existem em nenhum outro sistema, incluindo o histórico.
- Identificar quem responde por cada rotina hoje e o que aconteceria se ela parasse.
- Registrar tudo em documento único, com data, para servir de base à decisão.
O erro mais comum é levantar apenas quem usa a tela e ignorar rotinas automáticas e consultas diretas ao banco, que costumam ser as dependências mais difíceis de substituir.
Sobre o que está escrito aqui
Conceitos relacionados: sistema legado · dependência de dados · retenção de histórico · inventário de acessos · documentação de processo. 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
- APIs e integração: o que perguntar antes de c… — sistema sem integração
- Dados desatualizados: o que precisa estar em dia — dados desatualizados
Páginas relacionadas
O mesmo problema em outro objetivo
- Sistema antigo mantido pelo histórico: o que depende dele — Organizar um processo
- 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
- Planilha paralela com uma só pessoa: avaliar e contratar — Critérios para avaliar e contratar apoio quando uma planilha paralela sustenta a operação e o conhecimento está concentrado em uma só pessoa.
- 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.
- 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.
- Arquitetura sem mapa: como reconstruir o caminho do dado — Levantamento da arquitetura a partir do caminho que um dado percorre, com origem, transformação, destino e responsável registrados por campo crítico.
- Cadastro sem chave única: como escolher o identificador — Descreve como definir identificador próprio, regra de correspondência e responsável quando o cadastro existe em sistemas sem chave comum.