Resposta direta
O cadastro sobrevive à troca quando a identidade dele não depende do sistema. Isso exige três coisas definidas antes da migração: uma chave de negócio estável, que não seja o código interno gerado pelo sistema antigo; um dono por atributo, com regra de quem pode alterar e com base em quê; e um histórico de alterações guardado fora da aplicação. Com esses três elementos, a troca vira recarga de dados. Sem eles, cada novo sistema redefine o cadastro e o trabalho de organização recomeça.
- Objetivo
- Orientar implementação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a troca de sistema como teste de sobrevivência do cadastro e define o que precisa existir fora da aplicação, em vez de conferir apenas o que foi migrado.
O que a identidade do registro precisa cumprir
A chave de negócio identifica o registro fora de qualquer aplicação. Ela precisa existir no momento da criação, ser única na operação inteira e não mudar quando o cadastro é editado. CNPJ, número de contrato, matrícula e código do fabricante são candidatos. O número sequencial que o sistema gera não é, porque pertence ao sistema que o gerou.
Chaves compostas resolvem parte dos casos, mas cobram preço na conferência: cada campo da composição precisa de regra de preenchimento e de correção. Quando um deles muda de formato, todo o histórico passa a exigir tratamento. A decisão prática é escolher a chave mais estável que a operação já usa em documento externo, não a mais conveniente para o banco de dados.
Dono e histórico como parte da implementação
Dono de atributo é quem responde pelo valor correto de um campo, não quem digita. Endereço, condição de pagamento e classificação fiscal costumam ter donos diferentes, e a troca de sistema expõe isso: sem dono definido, o campo migra com o valor que estava na planilha de origem e ninguém tem autoridade para corrigi-lo depois.
O histórico precisa sobreviver fora da aplicação. Data, valor anterior, valor novo, origem e responsável pela alteração são o mínimo para reconstruir um cadastro quando o sistema novo não traz registro de mudanças ou traz um que será descartado no corte. Manter esse histórico em base própria parece redundância enquanto o sistema antigo está no ar; passa a ser a única fonte quando ele é desligado.
O que essa estrutura não resolve
A abordagem não corrige dado errado. Se a chave de negócio já está duplicada na origem, a troca de sistema transporta a duplicidade com mais organização. Também não substitui a conferência de saldos, títulos e movimentos, que têm regra contábil própria e não se reconstroem pelo cadastro.
Ela faz pouco sentido quando o cadastro só é usado dentro de um único sistema, sem documento externo, sem integração e sem obrigação de guarda. Nesse caso, o custo de manter chave, dono e histórico fora da aplicação não se paga. O limite mais ignorado é a manutenção: chave sem revisão periódica envelhece, dono sem substituto vira gargalo e histórico sem uso vira arquivo morto.
Recurso prático
Teste de sobrevivência do cadastro antes do corte
- Listar os atributos que a operação usa para reconhecer um registro e separar os que são código interno do sistema dos que existem em documento externo.
- Definir a chave de negócio de cada entidade e conferir se ela é única na operação inteira e permanece igual fora do sistema atual.
- Atribuir dono e regra de alteração a cada atributo, com registro de data, origem e responsável pela mudança.
- Montar uma base de cadastro fora da aplicação, com chave, atributos e histórico, e recarregá-la em ambiente vazio do sistema novo.
- Comparar o que voltou: campo perdido, valor truncado, registro sem correspondência e atributo sem dono viram pendência antes do corte.
O erro mais comum é usar o código gerado pelo sistema antigo como identidade. Ele parece estável porque aparece em toda planilha e em todo relatório, mas desaparece no primeiro registro criado no sistema novo.
Sobre o que está escrito aqui
Conceitos relacionados: chave de negócio · dono do atributo · dicionário de dados · histórico de alteração · contrato de campo. 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
- Falhas silenciosas em integrações: como perce… — falhas silenciosas
- Cadastros duplicados: como descobrir e consol… — cadastros duplicados
Páginas relacionadas
O mesmo problema em outro objetivo
- Cadastro preso ao sistema antigo: como separar dado de regra — Organizar um processo
- Cadastro que não sobrevive à troca de sistema: o que comparar — Comparar alternativas
- Cadastro que não sobrevive à troca de sistema: o que exigir — Orientar avaliação e contratação
Outras leituras em Integrações, sistemas e qualidade de dados
- Cadastro sem regra de deduplicação: comparar caminhos — Compara quatro saídas para cadastro sem regra de deduplicação e mostra o custo de erro, a manutenção e a reversibilidade de cada uma.
- Campos preenchidos sem padrão: como mapear a dispersão — Critérios objetivos para auditar campos com grafias diferentes, calcular o índice de dispersão de valores e separar erro humano de falha no desenho do sistema.
- Sistemas isolados: o que checar antes de comprar outro — Critérios operacionais para avaliar contratos de software quando a arquitetura atual opera sem comunicação direta entre áreas.
- Número sem unidade: o que comparar antes de tratar — Compara as formas de tratar um valor registrado sem unidade: perguntar à fonte, deduzir pelo contexto, padronizar com conversão registrada ou bloquear o dado.
- Campo obrigatório sem uso: como medir o uso de fato — Critérios para medir se um campo obrigatório virou dado usado na operação ou apenas preenchimento de tela, com sinais de uso, abandono e contorno.