O diretor sabe que o sistema atual não dá mais conta. Trava nos dias de pico, o fornecedor demora semanas para qualquer ajuste e a equipe já se acostumou a conviver com as limitações. Mesmo assim, a troca é adiada pelo terceiro ano seguido. O motivo não é preço nem prazo. É uma pergunta que ninguém responde com segurança na reunião: e os nossos catorze anos de histórico de clientes, para onde vão?
Esse medo é legítimo. Todo gestor conhece uma história de troca de sistema em que o histórico sumiu, os saldos não batiam ou o financeiro passou meses conferindo lançamento por lançamento. Mas a conclusão errada seria achar que migrar dados é uma loteria. Não é.
A tese deste artigo: migração de dados é um projeto próprio, com etapas, responsáveis e critérios de aceite, e não um item de rodapé na proposta do sistema novo. As trocas que terminam em trauma são, quase sempre, as que trataram a migração como detalhe.
O que é migração de dados?
Migração de dados é o processo de transferir as informações de um sistema para outro preservando o conteúdo, o histórico e o significado de cada dado. Não se trata de copiar arquivos: os dois sistemas organizam as informações de formas diferentes, e a migração é a tradução cuidadosa de uma estrutura para a outra.
Um exemplo simples mostra o desafio. No sistema antigo, o cadastro do cliente tem um campo único de endereço, preenchido livremente. No novo, endereço é dividido em rua, número, cidade e CEP, com validação. Alguém precisa decidir como quebrar o campo antigo, o que fazer com os cadastros incompletos e como conferir se a tradução deu certo. Multiplique essa decisão por dezenas de campos e milhares de registros, e fica claro por que a migração merece método.
Por que a troca de sistema trava por causa dos dados?
Porque o dado é o único componente insubstituível do projeto. Tela nova se aprende, processo novo se treina, mas o histórico de compras de um cliente de dez anos não se reconstrói. Quando a empresa avalia a troca, seja por outro software pronto ou por um sistema sob medida, a migração é o ponto em que o risco se concentra.
O erro mais comum é deixar o assunto para o final. A proposta comercial resume tudo em uma linha, “migração de dados inclusa”, sem dizer o que será migrado, como será validado e quem responde por divergências. Aí a empresa descobre, com o projeto andando, que “inclusa” significava apenas importar os cadastros básicos, sem histórico. Essa definição precisa entrar por escrito na fase de escopo do projeto, quando ainda há poder de negociação.
Quais são as etapas de uma migração bem feita?
Projetos sérios de migração seguem uma sequência conhecida. Os nomes variam, o esqueleto não:
- Inventário. Listar quais dados existem, onde moram e o que realmente precisa ir para o sistema novo. Nem tudo merece a viagem: relatórios antigos podem virar arquivo morto consultável, em vez de poluir o sistema novo;
- Limpeza. Corrigir duplicidades, cadastros incompletos e inconsistências antes da mudança. É a etapa mais subestimada e a que mais determina o resultado final;
- Mapeamento de/para. Documentar de onde sai e para onde vai cada campo, com as regras de transformação no caminho. Esse documento é o contrato técnico da migração e a referência para resolver qualquer divergência futura;
- Migração de teste. Executar o processo completo em um ambiente de ensaio, sem afetar a operação. É aqui que os problemas aparecem baratos: campo truncado, data invertida, saldo que não fecha;
- Validação. Conferir totais, amostras e casos críticos com a participação de quem usa o dado no dia a dia. A mesma disciplina que defendemos no artigo sobre testes de software vale aqui: quem valida procurando defeito encontra antes da virada, não depois;
- Virada. A migração definitiva, em data planejada, com janela de parada combinada e plano de retorno caso algo saia do previsto.
Por que dados sujos são o maior vilão da migração?
Porque o sistema novo é mais exigente que o antigo. Sistemas modernos validam CPF, e-mail, datas e vínculos entre registros. O sistema antigo, tolerante, aceitou durante anos o cliente cadastrado três vezes com grafias diferentes, o telefone anotado no campo de observações e o “999” usado como código genérico. Na migração, tudo isso vem à tona de uma vez.
Para dar uma ideia de escala com um cenário ilustrativo: uma base com 20 mil clientes acumulada ao longo de uma década pode facilmente carregar milhares de registros duplicados ou incompletos. Migrar essa base sem limpeza significa pagar para transportar sujeira, e ainda estrear o sistema novo com relatórios distorcidos e vendedores desconfiados dos números.
Minha posição aqui é firme: a limpeza vem antes da migração, e o esforço dela deve ser orçado e planejado como parte do projeto. A boa notícia é que esse trabalho paga dividendos além da troca: dados limpos melhoram relatórios, cobrança e relacionamento desde já, mesmo antes do sistema novo entrar.
O que exigir do fornecedor do sistema novo?
A migração costuma ficar a cargo de quem implanta o sistema novo, e é nessa negociação que a empresa se protege. Antes de assinar, exija:
- Plano de migração por escrito. Quais dados entram, em que ordem, com qual método e em quais datas. Se o fornecedor não consegue descrever o plano, ele ainda não pensou no assunto;
- Migração de teste incluída. Pelo menos um ensaio completo antes da virada, com tempo reservado para a sua equipe conferir os resultados sem pressa;
- Critérios de aceite claros. O que precisa bater para a migração ser considerada aprovada: totais financeiros, contagem de registros, amostras conferidas por área. Sem critério combinado, “deu certo” vira opinião;
- Período de convivência. Um intervalo em que o sistema antigo permanece acessível para consulta enquanto o novo assume a operação. É o seguro barato contra a surpresa descoberta na terceira semana;
- Responsável nomeado. Uma pessoa do fornecedor respondendo pela migração, e uma pessoa sua validando. Migração órfã de dono é migração que atrasa.
E a regra inegociável, que merece parágrafo próprio: nunca desligue o sistema antigo antes de validar o novo em operação real. Mantenha o acesso, mesmo que em modo somente leitura, até que os fechamentos do mês tenham batido no sistema novo. O custo de manter a licença antiga por mais um ou dois ciclos é irrisório perto do custo de precisar de um dado que já não existe.
Migrar bem é o que separa a troca de sistema do trauma
O medo de perder o histórico já manteve muita empresa presa por anos a um sistema que a atrasa. A saída não é coragem, é método: inventário, limpeza, mapeamento, ensaio, validação e virada com plano de retorno. Com essas etapas contratadas e cumpridas, a migração deixa de ser um salto no escuro e vira um projeto administrável, com riscos conhecidos e controlados.
Se a sua empresa adia uma troca de sistema por causa dos dados, esse é exatamente o tipo de projeto que conduzimos. A DevCore planeja e executa migrações com limpeza de base, ensaios e critérios de aceite documentados. Converse com o nosso time antes de assinar a próxima proposta.
Perguntas frequentes sobre migração de dados
Preciso migrar todo o histórico para o sistema novo?
Quase nunca. O caminho comum é migrar cadastros, saldos e o histórico recente que a operação consulta de verdade, e preservar o restante em um arquivo morto acessível para auditorias e consultas eventuais. Isso reduz custo, prazo e risco sem perder informação.
Quem responde pela migração, o fornecedor antigo ou o novo?
Em geral, o fornecedor novo executa e o antigo tem a obrigação de entregar os dados em formato utilizável, algo que idealmente já consta no seu contrato atual. A sua empresa fica com o papel que não pode delegar: validar os resultados e aprovar a virada.
O que acontece se um erro aparecer depois da virada?
Com o processo bem feito, existe rede de proteção: o sistema antigo ainda acessível para consulta, o mapeamento documentado para rastrear a origem da divergência e o período de convivência para correções. É por essa rede, e não pela esperança de perfeição, que a migração planejada é mais segura.