Um plano de migração de dados entre sistemas não consiste em exportar tabelas, adaptar colunas e importar registos. A mudança afeta o significado da informação, as suas relações, as permissões que permitem utilizá-la e os processos que dela dependem. Uma importação pode terminar sem erros técnicos e, ainda assim, deixar encomendas sem linhas, utilizadores com acesso indevido, montantes inconsistentes ou fluxos bloqueados por estados que o novo sistema interpreta de outra forma.
A migração deve ser tratada como uma transição operacional verificável. O objetivo não é que os dados “estejam” no destino, mas que as pessoas e os sistemas possam continuar o trabalho com informação completa, coerente, rastreável e segura. Isto exige definir o âmbito, testar com dados controlados, reconciliar resultados, limitar a coexistência entre plataformas e dispor de uma reversão que proteja a atividade e os dados criados durante a mudança.
Porque falham as migrações que parecem corretas
As contagens totais costumam ser o primeiro controlo: se existem 10 000 clientes na origem e 10 000 no destino, o resultado parece satisfatório. Mas esse controlo não demonstra que cada cliente tenha os campos adequados, que os seus contactos estejam associados, que as suas permissões estejam corretas nem que as suas operações históricas possam ser consultadas.
As falhas habituais ocorrem devido a diferenças semânticas e operacionais:
- Um campo de texto livre na origem transforma-se numa lista fechada no destino e alguns valores ficam sem equivalência.
- Um mesmo estado representa fases diferentes consoante o sistema; por exemplo, fechado pode significar concluído, cancelado ou arquivado.
- As relações são quebradas porque são gerados novos identificadores sem manter uma correspondência fiável.
- Os anexos não são transferidos, são duplicados ou perdem permissões de acesso.
- As regras de negócio do destino rejeitam dados históricos válidos, como datas incompletas ou registos desativados.
- Os utilizadores validam os ecrãs principais, mas não os fluxos reais de criação, alteração, aprovação, faturação ou atendimento.
A qualidade de uma migração mede-se pela continuidade dos processos críticos, e não apenas pelo êxito de uma tarefa de importação.
Definir o âmbito e o inventário antes de transformar
O primeiro entregável deve ser um âmbito explícito. Para cada entidade, decida se é migrado todo o histórico, apenas um período, os registos ativos ou uma combinação. Inclua entidades principais e dependentes: clientes, produtos, encomendas, ocorrências, utilizadores, documentos, catálogos, configurações e registos de auditoria quando forem necessários para operar ou cumprir obrigações internas.
Também é necessário declarar o que não é migrado. Pode ser mais adequado arquivar eventos muito antigos, excluir duplicados resolvidos, manter anexos num repositório de consulta ou deixar uma aplicação anterior acessível em modo de leitura durante um período limitado. Excluir informação não significa perdê-la: defina onde será conservada, quem poderá consultá-la e durante quanto tempo.
Crie um inventário de origem e destino para cada conjunto de dados. Deve incluir, no mínimo:
- Nome técnico e significado de cada campo.
- Formato, obrigatoriedade, valores permitidos e regras de validação.
- Identificador de negócio e identificador técnico.
- Relações, cardinalidade e ordem de carregamento necessária.
- Estado do dado: ativo, histórico, anulado, bloqueado ou pendente.
- Responsável funcional que decide as regras e aprova exceções.
- Transformação prevista, incluindo valores predefinidos e normalizações.
Uma matriz de correspondência transforma estas decisões num artefacto revisável. Por exemplo, um estado pendiente_revision pode passar para en_validacion; se não existir equivalência, deve definir-se se é criado um novo estado, se é encaminhado para uma fila manual ou se é excluído com justificação. Não é aconselhável resolver este tipo de decisões dentro do script de migração sem validação do responsável pelo processo.
Preservar a rastreabilidade, as relações e as exceções
Sempre que possível, conserve os identificadores estáveis utilizados por outros processos, relatórios ou integrações. Se o destino exigir novas chaves, crie uma tabela de correspondência entre o identificador de origem e o de destino. Esta tabela é essencial para reconstruir relações, investigar ocorrências, sincronizar temporariamente e reverter decisões.
A rastreabilidade deve incluir um registo de execução com a versão do extrato, regras aplicadas, data, responsável, número de registos lidos, aceites, rejeitados e transformados. As rejeições não são um detalhe técnico: classifique-as por causa, impacto e tratamento. Um endereço de e-mail mal formatado pode exigir correção ou exclusão; uma fatura sem cliente associado pode impedir o avanço se afetar um fluxo financeiro crítico.
Defina também um mecanismo para evitar duplicados caso o carregamento seja repetido. Uma operação idempotente identifica se um registo já foi processado e atualiza-o ou ignora-o segundo uma regra conhecida, em vez de criar uma segunda cópia. Isto é especialmente importante em testes sucessivos e numa eventual retoma após uma falha.
Testar com migrações de teste representativas
Antes da produção, execute migrações de teste sobre uma cópia controlada. Evite utilizar dados pessoais em ambientes sem os controlos adequados; aplique anonimização ou pseudonimização quando apropriado e limite o acesso. O teste deve utilizar um volume e uma variedade suficientes para revelar problemas: registos normais, históricos, cancelados, incompletos, duplicados conhecidos, relações complexas, anexos e casos com permissões especiais.
Um bom teste segue uma sequência repetível:
- Extrair um corte identificável de dados de origem.
- Aplicar as transformações documentadas.
- Carregar respeitando as dependências entre entidades.
- Executar controlos automáticos de integridade.
- Validar cenários funcionais com utilizadores responsáveis.
- Registar defeitos, ajustar regras e repetir até cumprir os critérios de aceitação.
Controle muito mais do que o número de linhas. Compare a completude dos campos obrigatórios, a unicidade das chaves, as relações pai-filho, as somas de montantes, datas, estados, permissões e anexos. Para dados financeiros, reconcilie totais por períodos e categorias. Para dados operacionais, selecione amostras com critérios reproduzíveis e percorra os fluxos reais: localizar um cliente, alterar um dado autorizado, criar uma operação, aprová-la e recuperá-la num relatório.
A validação funcional deve responder a uma pergunta concreta: a equipa consegue executar amanhã as suas tarefas críticas sem utilizar o sistema anterior como fonte de correção?
Coexistência temporária sem duas fontes de verdade
A coexistência reduz o risco, mas pode criar o problema mais perigoso: dois sistemas editáveis com dados divergentes. Antes da mudança, defina uma fonte de verdade por entidade e processo. Durante a transição, uma opção habitual é deixar o sistema anterior em modo de consulta e concentrar os novos registos e as alterações no novo. Se ambos tiverem de receber alterações, estabeleça quais os campos que cada um pode editar, como são sincronizados, com que frequência e quem resolve conflitos.
Uma sincronização bidirecional sem regras claras costuma multiplicar duplicados, sobrescritas e ambiguidades. Prefira uma janela de coexistência curta, com limites explícitos e uma data de desativação. Se o sistema anterior tiver de continuar a gerar informação, identifique as diferenças desde o último corte e teste o mecanismo de carregamento incremental antes de depender dele.
Planear a mudança e uma reversão realmente viável
O plano de mudança deve especificar um congelamento seletivo: que operações são interrompidas, quando, quem as comunica e que alternativa temporária existe. Nem todos os processos necessitam da mesma janela. Pode congelar-se a edição de dados mestre enquanto as consultas ou atividades não afetadas continuam operacionais.
Estabeleça responsáveis pela execução técnica, aprovação funcional, comunicações, tratamento de ocorrências e autorização para avançar ou parar. Os critérios de avanço devem ser observáveis: carregamentos concluídos, reconciliações aprovadas, testes críticos superados, acessos verificados e ausência de ocorrências bloqueadoras.
A reversão nem sempre equivale a apagar o destino. Defina o que é desfeito, que novos dados criados após a mudança devem ser preservados e como seriam reintroduzidos no sistema anterior, se necessário. Mantenha um ponto de recuperação prévio, conserve os ficheiros de carregamento e as tabelas de correspondência, e teste a decisão de reversão num ensaio. Devem existir limiares concretos para a ativar, como perda de relações em entidades críticas, impossibilidade de operar um fluxo essencial ou discrepâncias não explicadas em dados sensíveis.
Operação posterior e lista de verificação
Após a mudança, mantenha uma reconciliação intensiva durante os primeiros ciclos operacionais. Centralize as ocorrências numa fila com prioridade, impacto, responsável e prazo de resolução. Observe erros de integração, trabalhos falhados, acessos negados, tempos de resposta e variações anómalas nos volumes. A desativação do sistema anterior só deve ocorrer quando tiverem sido cumpridos os prazos de consulta, as obrigações de conservação e os critérios de encerramento acordados.
Antes, durante e depois da produção, verifique:
- O âmbito, as exclusões e os responsáveis funcionais estão aprovados.
- Existe uma matriz de correspondência de dados e uma tabela de chaves origem-destino.
- As regras de transformação, exceções e rejeições são auditáveis.
- Os testes incluem casos representativos e fluxos críticos completos.
- A reconciliação verifica conteúdo, relações, permissões e resultados de negócio.
- A coexistência atribui uma única fonte de verdade a cada dado.
- A mudança tem janelas, comunicações, responsáveis e critérios de avanço.
- A reversão protege os dados gerados após o corte e tem autorização definida.
- A monitorização e a desativação segura do sistema anterior têm responsável e data.
Uma migração madura não pede confiança cega numa importação: produz evidências para decidir se deve avançar, corrigir ou reverter sem comprometer a operação.