Resposta curta
Migrar legado sem perder dado exige três coisas na ordem: um de-para campo a campo com a regra de conversão escrita, cargas de ensaio repetidas até pararem de surpreender, e reconciliação que prove registro a registro que nada sumiu. O cutover é a parte curta; o que decide é o que veio antes dele.
Por que a migração é adiada há três anos
O sistema antigo todo mundo sabe que precisa sair. Ele trava, ninguém mais dá suporte, o relatório sai errado e a pessoa que entendia dele saiu da empresa. Mesmo assim ele fica, porque o medo de perder histórico é maior que o incômodo de conviver com o problema.
Esse medo é legítimo: migração malfeita perde registro, duplica lançamento e desmonta o fechamento contábil. O que resolve não é coragem, é método, e um método que produz prova antes de virar a chave, não depois.
Como fazemos
Inventário
Levantamos tudo que existe na origem, inclusive o que ninguém usa há anos. Migração que começa pelo que 'é importante' descobre tarde que o campo esquecido era o que amarrava dois cadastros.
De-para campo a campo
O documento mais chato e mais importante do projeto: origem, destino, regra de conversão e o que fazer com o que não tem equivalente. Aprovado por quem opera, não só por quem contrata.
Ensaios
Rodamos a migração em ambiente de teste quantas vezes for preciso, normalmente entre cinco e dez. Cada rodada é medida, e a seguinte começa do zero, para não mascarar erro com correção manual.
Reconciliação
Totais, contagens e saldos conferidos contra o sistema antigo, com relatório de divergência. Nenhum cutover acontece com divergência em aberto: é o critério que torna a virada uma decisão e não uma aposta.
Cutover
Fora do horário comercial, com janela definida, plano de retorno testado e o sistema antigo em modo leitura por um período. Na segunda-feira, ninguém percebe.
O que você recebe
- Documento de de-para completo, campo a campo
- Relatório de reconciliação com totais conferidos contra a origem
- Plano de cutover com janela, responsáveis e plano de retorno
- Sistema antigo em modo leitura durante o período de convivência
- Histórico completo migrado, consultável no sistema novo
Com o que trabalhamos
Perguntas frequentes
Migração de dados entre sistemas é o mesmo trabalho?
É o mesmo método. Trocar de ERP, de CRM ou sair da planilha para um sistema novo exige o mesmo de-para campo a campo, as mesmas cargas de ensaio e a mesma reconciliação. O que muda é quem decide a regra de conversão: numa troca de sistema pronto, parte dela vem do fornecedor novo, e ela precisa estar escrita antes da primeira carga. O mapeador de-para ajuda a dimensionar o tamanho do trabalho.
Quanto tempo a operação fica parada?
O cutover roda fora do horário comercial e a janela típica é de 4 a 12 horas, dependendo do volume. Em operação que não pode parar, fazemos a virada em modo de convivência: os dois sistemas ficam de pé, com o antigo em leitura, e a troca acontece por área.
E se der errado no meio da virada?
Existe plano de retorno testado nos ensaios, não escrito no dia. Até um ponto definido da janela, a decisão de voltar é reversível e o sistema antigo volta a receber lançamento. Passado esse ponto, seguimos, e é por isso que ele é decidido antes, com o cliente.
Dá para migrar só uma parte e deixar o resto para depois?
Dá, e muitas vezes é o certo. Cadastro e histórico costumam vir primeiro; movimentação antiga pode ficar em consulta no sistema legado por um tempo. O que não dá é migrar metade de um mesmo processo: isso cria dois lugares de verdade para o mesmo dado.
O sistema antigo não tem banco documentado. Muda alguma coisa?
Muda o prazo do inventário, não a viabilidade. Nesse caso a engenharia reversa é feita a partir do banco e do comportamento do sistema, e o de-para leva mais tempo para fechar. É comum: a maioria dos legados que migramos não tinha documentação nenhuma.