Si les données que vous prévoyez de migrer sont actuellement incorrectes, elles doivent être corrigées, que vous effectuiez une migration ou non. Mauvaises données = données inutiles.
Les migrations sont risquées, c'est vrai. Mais il en va de même pour tous les grands projets informatiques. Il existe des moyens d'atténuer les risques et ils doivent certainement être planifiés dès le début d'une migration.
Tout d'abord, vous devriez toujours avoir un moyen de revenir au système tel qu'il est actuellement. Les deuxièmes migrations doivent être effectuées sur des serveurs de test configurés uniquement pour la migration. Il est insensé de faire une migration sans avoir la possibilité de la tester d'abord. Troisièmement, tout le code de la migration doit être sous contrôle de code source.
Quatrièmement, vous avez besoin d'exigences et de plans de test avant de commencer la migration. Vous devez savoir que si vous aviez 1 293 687 enregistrements dans l'ancien système, que vous en avez de même dans le nouveau ou que vous savez où ils sont allés (dans une table d'exceptions peut-être). Si vous normalisez un schéma dénormalisé, vous devez calculer le nombre d'enregistrements avec lesquels vous devez vous retrouver avant de commencer, puis vérifier cela. Vous avez besoin d'une documentation qui spécifie les mappages d'un système à l'autre. Cela aidera votre personnel AQ à vérifier que les données sont bien placées.
Vous devez déterminer comment gérer les mauvaises données actuelles. Ce qui peut être nettoyé, ce qui pourrait avoir besoin d'une valeur dans un champ obligatoire qui dit 'Inconnu', ce qui devrait être jeté dans une table d'exceptions, ce qui nécessite une intervention manuelle d'un groupe d'utilisateurs (décider si ces deux personnes sont vraiment un dup ou y a-t-il deux médecins dans cette pratique avec le même nom par exemple et s'il s'agit d'un dup dont les données doivent être choisies lorsque les deux enregistrements diffèrent, etc.).
La clé d'une migration réussie est la planification. J'ai constaté que la planification (qui comprend la rédaction des cas de test et des tests unitaires) prend généralement plus de temps que le développement réel.
La prochaine clé d'une migration de données réussie est le contrôle qualité. Ce n'est pas un projet à lancer à l'équipe QA la veille du lancement. Ce n'est pas un projet à lancer lorsque QA dit qu'il y a un problème.
Une autre clé d'une migration réussie consiste à déployer la majorité des données et à les tester pendant que le système d'origine est toujours en cours d'exécution. Si vous déplacez de nombreux enregistrements, cela peut prendre du temps et de nouveaux changements se produiront. Par conséquent, votre processus doit également pouvoir extraire les modifications des données après le début de la migration. SQL Server, par exemple, a quelque chose appelé Change Data Capture qui peut vous aider. Vous pouvez effectuer une sauvegarde du système d'origine et activer simultanément la capture des données modifiées. Ensuite, vous pouvez réinstaller la sauvegarde sur votre serveur de migration, tester la migration, charger la majorité des données et ensuite il vous suffit de charger les enregistrements qui ont changé. Lorsque vous migrez les enregistrements finaux, désactivez le système source jusqu'à ce que la migration soit terminée. C'est une des raisons de migrer la majorité des enregistrements à l'avance, donc l'application est en panne le moins de temps. Choisissez bien votre heure de migration, ne fermez pas le système de paie le jour où ils devraient traiter la paie ou envoyer des W2. Et faites-le pendant les faibles heures d'utilisation. Si vous avez plusieurs clients, vous pouvez envisager de migrer un premier et de vous assurer que tout va bien avant de faire les autres. Il est beaucoup plus facile de restaurer les données d'un client que 10000 en cas de problème. Mais planifiez cela soigneusement si vous le faites. s données supérieures à 10000 en cas de problème. Mais planifiez cela soigneusement si vous le faites. s données supérieures à 10000 en cas de problème. Mais planifiez cela soigneusement si vous le faites.
Si la migration implique une nouvelle interface utilisateur, veuillez demander aux utilisateurs réels de l'utiliser dans le cadre des tests de migration. Ensuite, formez les autres utilisateurs avant de mettre en ligne (mais moins d'une semaine avant de mettre en ligne ou ils oublieront). Demandez aux utilisateurs impliqués dans les tests d'aider à concevoir la formation, ils savent quelles questions ils ont et ce que les gens doivent savoir dans quel ordre. Obtenez leur entrée, en rendant un champ obligatoire parce que vous pensez que cela devrait être utile si les utilisateurs n'ont généralement pas ces données lorsqu'ils entrent dans les enregistrements. Ils vont simplement mettre du courrier indésirable dans le champ nouvellement requis car ils ne peuvent pas entrer les données autrement.
Regardez ce qui ne va pas avec les données actuelles, pouvez-vous ajouter des clés étrangères, des contraintes, des déclencheurs, des règles métier dans l'application, des valeurs par défaut, etc. afin d'éviter que cela ne soit mauvais à l'avenir? Lorsque vous nettoyez de mauvaises données, vous devez également créer un moyen d'éviter que ces données tout aussi mauvaises ne pénètrent à l'avenir. Analysez pourquoi les mauvaises données ont été allouées et corrigez la conception des trous.