Se os dados que você planeja migrar estiverem incorretos no momento, eles precisam ser corrigidos, seja você uma migração ou não. Dados inválidos = dados inúteis.
As migrações são arriscadas, isso é verdade. Mas o mesmo acontece com todos os principais projetos de TI. Existem maneiras de mitigar os riscos e eles certamente devem ser planejados antecipadamente em uma migração.
Primeiro, você sempre deve ter uma maneira de voltar ao sistema como é agora. As segundas migrações devem ser feitas nos servidores de teste configurados apenas para a migração. É tolice fazer uma migração sem a capacidade de testá-la primeiro. Terceiro, todo o código para a migração deve estar no controle de origem.
Quarto, você precisa de requisitos e planos de teste antes de iniciar a migração. Você precisa saber que, se você tiver 1.293.687 registros no sistema antigo, terá o mesmo no novo ou saberá aonde eles foram (talvez para uma tabela de exceção). Se você estiver normalizando um esquema desnormalizado, precisará calcular quantos registros você deve terminar antes de iniciar e depois verificar isso. Você precisa de documentação que especifique quais são os mapeamentos de um sistema para outro. Isso ajudará seu pessoal de controle de qualidade a verificar se os dados foram para o lugar certo.
Você precisa determinar como lidar com os dados incorretos atuais. O que pode ser limpo, o que pode precisar de um valor em um campo obrigatório que diga 'Desconhecido', o que deve ser jogado fora em uma tabela de exceção, o que precisa de intervenção manual de um grupo de usuários (decidindo se essas duas pessoas são realmente enganadas ou não) existem dois médicos nessa clínica com o mesmo nome, por exemplo, e se é um dup quais dados escolher quando os dois registros diferem etc.).
A chave para uma migração bem-sucedida é o planejamento. Descobri que o planejamento (que inclui escrever os casos de teste e os testes de unidade) geralmente leva mais tempo do que o desenvolvimento real.
A próxima chave para uma migração de dados bem-sucedida é o controle de qualidade. Este não é um projeto a ser lançado na equipe de controle de qualidade no dia anterior ao lançamento. Este não é um projeto a ser iniciado quando o controle de qualidade diz que há um problema.
Outra chave para uma migração bem-sucedida é implantar a maioria dos dados e testá-los enquanto o sistema original ainda está em execução. Se você estiver movendo muitos registros, isso pode ser demorado e novas alterações acontecerão. Portanto, seu processo deve ser capaz de extrair as alterações de dados após o início da migração. O SQL Server, por exemplo, tem algo chamado Change Data Capture que pode ajudar nisso. Você pode fazer um backup do sistema original e ativar a captura de dados alterados ao mesmo tempo. Em seguida, você pode redefinir o backup para o servidor de migração, testar a migração, obter a maioria dos dados carregados e, em seguida, você só precisa carregar os registros que foram alterados. Ao migrar os registros finais, desligue o sistema de origem até que a migração seja concluída. Esse é um dos motivos para migrar a maioria dos registros antes do tempo, portanto, o aplicativo fica inativo por menos tempo. Escolha bem o seu tempo de migração, não desligue o sistema da folha de pagamento no dia em que eles devem processar a folha de pagamento ou enviar W2s. E faça isso durante as horas de baixo uso. Se você tiver vários clientes, considere migrar um primeiro e verificar se tudo está bem antes de fazer os outros. É muito mais fácil reverter os dados de um cliente do que 10000, se houver um problema. Mas planeje isso com cuidado se fizer isso. s dados que 10000 se houver um problema. Mas planeje isso com cuidado se fizer isso. s dados que 10000 se houver um problema. Mas planeje isso com cuidado se fizer isso.
Se a migração envolver uma nova interface do usuário, peça aos usuários reais que a usem como parte dos testes de migração. Treine os outros usuários antes de ir ao ar (mas menos de uma semana antes de ir ao ar, ou eles esquecerão). Faça com que os usuários envolvidos nos testes ajudem a projetar o treinamento, eles saibam quais perguntas eles tiveram e o que as pessoas precisam saber em que ordem. Obtenha a entrada deles, exigindo um campo, porque você acha que não deve ajudar se os usuários geralmente não tiverem esses dados quando inserem os registros. Eles apenas colocarão lixo no campo recém-obrigatório, pois não poderão obter os dados de outra maneira.
Veja o que há de errado com os dados atuais. Você pode adicionar chaves estrangeiras, restrições, gatilhos, regras de negócios no aplicativo, valores padrão etc. para evitar que isso seja ruim no futuro? Ao limpar dados incorretos, você também precisa criar uma maneira de evitar que dados ruins entrem no futuro. Analise por que os dados ruins foram alocados e corrija os buracos no design.