Migração de dados entre sistemas: como trocar sem perder nada

O sistema novo está pronto, as telas foram aprovadas, o treinamento foi agendado. Aí alguém pergunta: "e os clientes, os saldos e os pedidos em aberto, como vão para lá?". A resposta costuma ser "exporta e importa". Três semanas depois, a primeira carga revela clientes duplicados, produtos sem unidade de medida, títulos a receber sem vencimento e um campo "status" com quarenta valores diferentes, dos quais metade ninguém sabe o que significa.

É nesse ponto que muitas trocas de sistema atrasam. Não por causa do software novo, mas porque os dados da empresa contam uma história diferente da que todo mundo imaginava. Planilhas viraram cadastro, cadastros viraram gambiarra e o sistema antigo aceitou tudo isso por anos sem reclamar.

Migração de dados entre sistemas é levar cadastros, saldos, documentos em aberto e, quando fizer sentido, o histórico de um sistema para outro sem perder nem distorcer informação. Feita direito, ela é um projeto com etapas, responsáveis e critérios de aceite, e não uma exportação de planilha na véspera. Este texto mostra como conduzi-la, seja numa troca de ERP, na saída de um sistema próprio antigo ou na consolidação de várias bases.

Migração de dados em uma página

Se você só tiver tempo para ler uma seção, leia esta. Uma migração bem feita passa por seis etapas, nesta ordem:

1. Inventário: listar todas as fontes de dados e decidir o que migra, o que vai para arquivo de consulta e o que fica para trás.
2. Limpeza: corrigir e deduplicar na origem, antes de mover qualquer coisa.
3. De-para: documentar como cada campo, código e status do sistema antigo vira algo no sistema novo.
4. Cargas de teste: rodar a migração completa várias vezes num ambiente separado, cada vez com menos erro.
5. Validação pelas áreas: quem usa os dados no dia a dia confere e assina que estão certos.
6. Corte final: congelar o sistema antigo, rodar a carga definitiva, conferir e liberar o novo.

A regra que atravessa todas elas: migração é um processo repetível, não um evento. Se a carga só pode ser executada uma vez, na madrugada da virada, a empresa está apostando. Se ela foi rodada e conferida várias vezes, a virada vira rotina.

Por que a migração de dados atrasa projetos

Quase sempre, o problema é de planejamento, não de tecnologia. Os motivos mais comuns:

• Ela entra no cronograma como tarefa, não como frente de trabalho. Uma linha "migrar dados" no fim do plano, com poucos dias, para algo que exige semanas de trabalho conjunto entre TI e áreas.
• Ninguém é dono dos dados. A TI sabe mover registros, mas não sabe se o limite de crédito de um cliente está certo. Quem sabe é o financeiro, e o financeiro não foi envolvido.
• O sistema antigo esconde regras. Um campo "observação" que, quando contém a palavra "BLOQ", impede o faturamento. Um tipo de pedido que existe só para um cliente. Se o sistema não tem documentação, essas regras só aparecem quando alguém procura. O processo para descobri-las está em assumir um sistema legado sem documentação.
• O sistema novo tem regras mais rígidas. Ele exige CPF ou CNPJ válido, CEP no formato certo, NCM em todo produto. Ótimo para o futuro, mas os dados antigos não passam.
• A empresa não para durante o projeto. Pedidos, notas e pagamentos continuam entrando no sistema antigo até o último dia.

Inventário: o que migrar e o que arquivar

O primeiro trabalho é saber o que existe. Parece óbvio, mas quase toda empresa descobre fontes que ninguém tinha mencionado: a planilha de comissões do comercial, o Access do almoxarifado, a tabela de preços especiais que vive no e-mail do gerente.

Para cada fonte, levante:

• quais entidades ela guarda (clientes, produtos, pedidos, títulos, contratos, ordens de serviço);
• quantos registros existem, e quantos estão ativos;
• quem usa e para quê;
• se ela é a fonte oficial daquele dado ou uma cópia.

Com isso em mãos, cada conjunto de dados recebe um destino:

O inventário também é o momento de olhar para a LGPD. Dados pessoais que a empresa não precisa mais guardar não deveriam ser copiados para um sistema novo só porque estavam no antigo. A decisão sobre prazos de retenção é do jurídico e do contador; o projeto de migração precisa garantir que o sistema novo respeite o que eles definirem.

Limpeza e deduplicação antes de migrar

A tentação é migrar tudo e "limpar depois, no sistema novo". Não funciona. Depois da virada, a equipe está ocupada aprendendo o sistema e apagando incêndio. A limpeza nunca acontece, e o sistema novo herda a bagunça do antigo.

Os problemas que mais aparecem:

• Clientes duplicados: o mesmo CNPJ cadastrado três vezes, com razões sociais escritas de formas diferentes, cada um com uma parte do histórico.
• Produtos duplicados ou genéricos: "PARAFUSO DIVERSOS", o mesmo item com dois códigos porque veio de fornecedores diferentes.
• Campos obrigatórios vazios: e-mail, telefone, unidade de medida, NCM, centro de custo.
• Formatos misturados: datas como texto, CEP com e sem traço, documentos com pontuação e sem.

Quem decide o que é duplicado

A TI consegue encontrar candidatos a duplicidade com regras: mesmo CNPJ, mesmo e-mail, nomes muito parecidos. Mas quem decide qual cadastro sobrevive, e o que acontece com o histórico do outro, é a área dona do dado. Defina esse dono por entidade logo no início: comercial para clientes, compras para fornecedores, engenharia ou suprimentos para produtos, financeiro para títulos.

Uma boa prática é gerar relatórios de inconsistência a cada carga de teste e entregar para cada dono a lista do que é dele. A lista diminui a cada rodada, e esse número vira o indicador de prontidão da migração.

De-para de campos, códigos e status

O de-para é o documento que diz, para cada informação do sistema antigo, onde ela vai parar no sistema novo e como é transformada. É a peça mais importante do projeto e a que mais costuma ser feita de cabeça.

Ele tem três camadas:

Campos. "CLI_NOME" vira "razão social". "CLI_FANT" vira "nome fantasia". "CLI_OBS" é dividido: o que for instrução de entrega vai para um campo, o que for restrição de crédito vai para outro.

Códigos e tabelas. Condições de pagamento, tipos de operação, unidades de medida, centros de custo, plano de contas. O sistema antigo tem "30/60/90" escrito de quatro jeitos; o novo tem uma tabela de condições. Cada código antigo precisa de um destino, e os que não têm destino precisam de uma decisão.

Status. É onde mora o maior risco. Um pedido "LIBERADO" no sistema antigo pode significar "aprovado pelo crédito", "separado no estoque" ou "pronto para faturar", dependendo de quem cadastrou. Se o de-para errar aqui, pedidos somem da fila de alguém ou aparecem duas vezes.

Na prática, o de-para vira uma planilha viva, revisada pelas áreas, com uma linha por campo ou código e colunas para origem, destino, regra de transformação, responsável e situação (aprovado, pendente, em discussão). Se a troca de sistema ainda está em fase de escolha, vale ler ERP sob medida ou ERP de mercado: o modelo de dados do sistema escolhido define o tamanho desse de-para.

Cargas de teste e validação pelas áreas

A migração deve ser um programa, não um procedimento manual. Ele lê a origem, aplica as regras do de-para, grava no destino e gera um relatório do que entrou, do que foi rejeitado e por quê. Isso permite repetir a carga quantas vezes for preciso, sempre com o mesmo resultado.

Um ciclo típico:

1. Copiar a base de produção do sistema antigo para um ambiente separado.
2. Rodar a migração completa num ambiente de homologação do sistema novo.
3. Gerar o relatório de rejeições e entregar para os donos dos dados.
4. Corrigir na origem o que for erro de dado e no programa o que for erro de regra.
5. Repetir.

O que as áreas conferem

Conferir não é abrir três cadastros e dizer que está bom. Combine critérios objetivos:

• Contagens: quantidade de clientes ativos, produtos, títulos em aberto e pedidos pendentes, origem contra destino.
• Totais: soma do contas a receber, do contas a pagar e do valor de estoque, que devem bater com o fechamento do sistema antigo na mesma data.
• Amostras dirigidas: os casos difíceis que a área conhece, como o cliente com três endereços de entrega, o produto com conversão de unidade ou o contrato com reajuste anual.
• Teste de processo: emitir um pedido, faturar, baixar um título usando os dados migrados. É aqui que aparecem os problemas que nenhuma contagem pega.

Cada área assina o aceite da sua parte. Sem essa assinatura, a data da virada não é marcada.

Histórico: migrar tudo ou consultar no legado

Toda migração tem essa discussão. Migrar anos de notas, pedidos e movimentações parece mais seguro, mas multiplica o trabalho de de-para, porque o histórico antigo usa códigos e regras que já mudaram várias vezes.

As alternativas mais usadas:

• Migrar só saldos e documentos em aberto, e manter o sistema antigo disponível apenas para consulta, sem permitir lançamentos.
• Migrar um período recente, que atende às análises do dia a dia, e arquivar o restante.
• Extrair o histórico para uma base de consulta separada, com relatórios simples ou um painel de BI, e desligar o sistema antigo de vez.

Critérios para escolher:

• O que a operação realmente consulta no histórico, e com que frequência?
• O que precisa ficar guardado por obrigação fiscal, trabalhista ou contratual? Esse prazo deve ser confirmado com o contador e o jurídico.
• Quanto custa manter o sistema antigo rodando, com licença, servidor e alguém que saiba usá-lo?

Na maioria dos casos, migrar saldos e documentos em aberto, com o histórico preservado numa base de consulta, entrega o melhor equilíbrio entre esforço e segurança.

O fim de semana da virada

Com cargas de teste estáveis e aceite das áreas, a virada deixa de ser um salto no escuro. Ela segue um roteiro escrito, ensaiado pelo menos uma vez com cronômetro.

Um roteiro típico:

1. Congelamento: a partir de um horário combinado, ninguém lança nada no sistema antigo. Pedidos que chegarem nesse intervalo são anotados para entrada posterior.
2. Fechamento na origem: estoque, financeiro e faturamento fecham o dia e registram os totais de referência.
3. Carga definitiva: o mesmo programa das cargas de teste, agora apontado para produção.
4. Conferência: contagens, totais e amostras, pelos mesmos critérios das rodadas anteriores.
5. Decisão de seguir ou voltar: um responsável nomeado, com critérios definidos antes, decide se libera o sistema novo.
6. Liberação e acompanhamento: equipe de plantão nos primeiros dias para tratar o que aparecer.

O plano de volta

Todo roteiro de virada precisa de um plano de volta escrito: até que momento é possível desistir e reabrir o sistema antigo sem perda, e o que fazer com o que já foi lançado no novo.

Alguns projetos não admitem parar a operação nem por um fim de semana. Nesses casos, a alternativa é migrar por partes, módulo a módulo ou filial a filial, com os dois sistemas convivendo e sincronizando dados por um período. Se o sistema antigo não oferece API para essa sincronização, há caminhos descritos em integrar sistema legado sem API. É a mesma lógica incremental discutida em reescrever ou refatorar um sistema legado: menos risco em cada passo, em troca de um período de convivência que precisa ser bem controlado.

Checklist de prontidão para a virada

• Todas as fontes de dados foram inventariadas, inclusive planilhas e bases paralelas?
• Cada entidade tem um dono na área de negócio?
• O de-para está aprovado, sem itens pendentes?
• A migração roda por programa, de forma repetível, com relatório de rejeições?
• As últimas cargas de teste rodaram sem erros relevantes?
• As áreas assinaram o aceite de contagens, totais, amostras e testes de processo?
• O roteiro da virada foi ensaiado?
• Existe um plano de volta escrito, com responsável e critérios?
• Está decidido o que acontece com o histórico e com o sistema antigo?

Se alguma resposta for "não", a data da virada ainda não deveria estar marcada.

Perguntas frequentes

Qual a diferença entre migração de dados e integração de sistemas?

Migração de dados é a transferência, feita numa troca de sistema, de cadastros, saldos e documentos em aberto de uma base para outra, com data de corte. Integração é a troca contínua de dados entre sistemas que seguem funcionando juntos. Numa migração por partes, as duas se encontram durante o período de convivência.

Quem deve ser responsável pela migração de dados, a TI ou as áreas?

As duas. Na migração de dados, a TI constrói o programa de carga, aplica as regras do de-para e gera os relatórios de rejeição, mas cada entidade precisa de um dono na área de negócio: comercial para clientes, compras para fornecedores, financeiro para títulos. São esses donos que decidem duplicidades e assinam o aceite.

Dá para migrar dados entre sistemas usando planilha de exportação e importação?

Para volumes pequenos, dá, mas é arriscado numa troca de sistema. Exportar e importar planilha à mão não é repetível e esconde rejeições. O mais seguro é um programa de migração de dados que lê a origem, aplica as regras do de-para, grava no destino e relata o que foi rejeitado, rodado várias vezes antes da virada.

Dados pessoais antigos precisam ir para o sistema novo?

Não necessariamente. Pela lógica da LGPD, dados pessoais que a empresa não precisa mais guardar não deveriam ser copiados para o sistema novo só porque existiam no antigo. Os prazos de retenção de cada tipo de dado devem ser definidos pelo jurídico e pelo contador, e a migração de dados precisa respeitar essas decisões.

Como a Pervian Tech trabalha migração de dados

Na Pervian Tech, tratamos migração como parte do trabalho de arquitetura de software, não como tarefa de última semana. Começamos pelo inventário e por uma primeira leitura dos dados reais, que mostra cedo onde estão as inconsistências e quanto trabalho de limpeza existe. A partir daí, montamos o de-para com as áreas, construímos a migração como programa repetível e conduzimos as cargas de teste até que os números batam.

Quando a migração faz parte de um projeto maior de modernização de sistemas legados, ela é planejada junto com a arquitetura do sistema novo, para que o modelo de dados já nasça pensando no que vem do antigo. Outros textos sobre o tema estão na categoria modernização.

Cada migração é sob medida, porque depende das fontes, do volume e da qualidade dos dados de cada empresa. O prazo depende do que o diagnóstico encontrar, e o investimento é definido sob consulta, depois de um diagnóstico inicial gratuito. Se a sua troca de sistema esbarrou nos dados, conte onde ela está travada.