Resposta direta
Sistema mantido apenas por histórico se contrata por escopo, não por disponibilidade. A separação é entre o que ainda produz dado novo e o que apenas é consultado. O primeiro justifica sustentação; o segundo cabe em congelamento com acesso preservado. Contrato de manutenção faz sentido quando existe base legal de retenção, consulta recorrente e responsável nomeado. Sem esses três itens, o custo de manter tende a superar o de extrair o histórico para uma base de consulta. A decisão é de negócio, antes de ser técnica.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a manutenção como decisão sobre o que ainda gera dado novo, e não sobre a idade do sistema.
O que o sistema ainda produz
A primeira separação é entre o que gera dado novo e o que só devolve dado antigo. Um sistema pode parecer parado porque a interface é antiga, mas ainda ser origem de um cadastro, de um lançamento fiscal ou de uma rotina mensal. Enquanto isso acontece, existe dependência de operação, e não apenas de leitura.
Para cada rotina ativa, vale registrar quem alimenta, com que frequência, o que consome a saída e o que aconteceria se ela parasse por uma semana. Esse levantamento não exige ferramenta nova. Costuma caber em uma planilha revisada com as áreas que usam o sistema.
O que entra no contrato
Contrato de manutenção de sistema antigo precisa nomear escopo, e não apenas horas de atendimento. Correção de falha, ajuste por mudança de regra legal, consulta sob demanda e recuperação de dado são serviços diferentes, com custos e responsáveis diferentes.
Também convém definir o que acontece no fim: em qual formato o dado é devolvido, quem confere a extração e por quanto tempo o acesso permanece. Sem essa cláusula, a saída do fornecedor vira um problema novo, meses depois.
O que a manutenção não resolve
Manter o sistema antigo não corrige a causa que o tornou crítico: processos que dependem de dado sem documentação e sem dono claro. Também não substitui a decisão de migrar. Adia o custo, e em alguns casos essa é a escolha certa.
A manutenção também não garante que o fornecedor conheça a regra de negócio embutida no código. Parte dessas regras existe só na prática de quem opera. Se essa pessoa sai, o contrato continua válido e o conhecimento, não. Quando não há registro das decisões e nem quem explique a regra, contratar manutenção apenas posterga a perda.
Recurso prático
Roteiro para decidir o que contratar em um sistema antigo
- Levantar telas, relatórios e rotinas em uso e classificar cada item como gera dado novo, consulta histórico ou sem uso.
- Para cada rotina que gera dado novo, identificar quem alimenta, com que frequência e o que é consumido a partir dela.
- Para cada consulta de histórico, registrar quem consulta, com que frequência e qual obrigação de retenção sustenta o acesso.
- Verificar se o histórico pode ser extraído para outra base em formato legível e quem confere essa extração.
- Definir o escopo do contrato: correção de falha, ajuste por mudança de regra, consulta sob demanda ou apenas acesso ao dado.
- Nomear um responsável interno pela relação com o fornecedor e pelo registro das mudanças de regra.
O ponto mais ignorado é a diferença entre rotina ativa e consulta. Contratar manutenção pelo volume de histórico guardado encarece o contrato sem entregar o que a operação precisa. O que define escopo e preço é quantas rotinas ainda geram dado novo.
Sobre o que está escrito aqui
Conceitos relacionados: sistema legado · contrato de manutenção · retenção de histórico · base de consulta · controle de acesso. 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
- Exportações manuais: quando ainda fazem sentido — exportações manuais
- Migração de dados: o que conferir antes e depois — migração sem conferência
Páginas relacionadas
O mesmo problema em outro objetivo
- Sistema antigo mantido pelo histórico: o que ele ainda faz — Diagnosticar
- 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
Outras leituras em Integrações, sistemas e qualidade de dados
- Cópia de base sem versão: como manter registros íntegros — Roteiro operacional para definir posse de arquivos, janelas de atualização e regras de descarte quando não há controle de versão automatizado no sistema.
- Integração sem documentação: como avaliar antes de contratar — O que verificar em uma integração sem documentação antes de contratar: evidências que substituem o histórico, escopo do contrato e limites da avaliação.
- Dado sensível em planilha: o que exigir na contratação — O que precisa estar definido no contrato e na operação quando dado sensível circula em planilha compartilhada: campos, acesso, revogação e responsabilidade.
- 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.