Resposta direta
Migração se contrata por responsabilidade, não por capacidade técnica. Antes de assinar, o contrato precisa dizer qual base é a fonte, quem decide quando os números divergem, qual é o critério de aceite e o que acontece se o prazo escorregar. O fornecedor entrega conversão de registros; a empresa dona do processo responde pela regra de negócio. Sem isso, o projeto termina com dados no sistema novo e nenhum dono claro para o que ficou faltando.
- Objetivo
- Orientar avaliação e contratação
- Formato indicado
- Projeto de implementação
- Atualizado em
O que esta página acrescenta: Trata a migração como contratação, com escopo, aceite e responsabilidade, em vez da conferência técnica do dado ou da escolha do sistema.
Escopo se lê pela lista de bases
Uma proposta de migração é tão clara quanto a lista de bases que ela nomeia. Se o documento fala em migrar os dados do sistema antigo, cabe pedir a relação de tabelas, planilhas e arquivos que entram, e o que segue rodando fora do sistema novo.
Volume e complexidade são coisas diferentes. Uma base pequena com regra de negócio mal definida dá mais trabalho que uma base grande e padronizada. O preço deveria seguir a regra, não a quantidade de linhas.
Aceite se escreve antes da virada
Aceite se escreve como conferência, não como ausência de erro. O contrato precisa dizer qual relatório de reconciliação fecha a entrega, quem compara os totais e em quanto tempo a divergência é tratada.
Na virada, alguém da operação aprova a entrada do sistema novo. Esse mesmo nome responde pelos primeiros dias. Sem essa definição, o fornecedor encerra o projeto e a divergência passa a ser discussão interna.
O que a migração não resolve
Contratar bem não corrige cadastro duplicado na origem, regra de negócio indefinida nem dado que nunca foi mantido. Se a empresa não tem quem decida o que é o registro correto, nenhum fornecedor decide por ela.
Também não há como prometer que os números vão bater no fim. Parte das divergências nasce do processo, e não do dado migrado. O que se pode exigir é que a diferença apareça identificada, com responsável e prazo de tratamento.
Recurso prático
Sequência mínima antes de assinar a migração
- Listar as bases de origem e o que cada uma alimenta hoje
- Escrever a regra de negócio que decide empate entre registros
- Definir o critério de aceite como conferência, não como ausência de erro
- Nomear quem aprova a virada e quem responde depois dela
- Fixar o que fica fora do escopo e como entra depois, se entrar
O erro mais comum é aceitar a entrega pela contagem de registros migrados, que diz pouco sobre o dado ter chegado com o mesmo significado.
Conceitos usados nesta página
- Critério de aceite — Critério de aceite é a condição objetiva que define quando uma entrega, tarefa ou automação é considerada concluída — verificável por quem recebe, não por quem produziu.
- Matriz de responsabilidade — Matriz de responsabilidade é a representação explícita de quem executa, quem aprova, quem é consultado e quem precisa ser informado em cada etapa de um processo.
Sobre o que está escrito aqui
Conceitos relacionados: base legada · critério de aceite · matriz de responsabilidade · janela de virada · regra de negócio. 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
- Migração que não anda: como separar dado, processo e decisão — Diagnosticar
- Migração em curso: o que decidir antes de desligar o antigo — Organizar um processo
- Migração: comparar corte único, etapas e paralelo — Comparar alternativas
- Migração sem critério de aceite: como medir se o dado chegou — Explicar medição
Outras leituras em Integrações, sistemas e qualidade de dados
- Planilha paralela: como organizar e migrar para o sistema — Critérios para mapear dados, responsabilidades e fluxos de planilhas paralelas antes de tentar absorvê-las pelo sistema oficial da empresa.
- Planilhas paralelas: sinais de dependência na rotina — Critérios para identificar planilhas que substituíram o sistema oficial, avaliar riscos operacionais e mapear a dependência de pessoas específicas.
- Cadastro sem chave única: o que exigir na contratação — O que exigir de um fornecedor de cadastro sem chave única: critérios de avaliação, responsabilidade sobre duplicidade e o que medir antes de assinar.
- 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.
- Tabela de apoio sem dono: como implantar com responsabilidade — O que fazer quando a tabela de apoio não tem dono: responsabilidade nomeada, controle de alteração e o que registrar para a operação não depender de memória.