Êtes-vous sur le point de faire face à un migration de données d'un système à un autre? Si pas encore, Ce post sera tout aussi utile car à un moment donné vous allez devoir faire face à cette situation. Soit pour des raisons de mise à jour de vos systèmes, soit pour une extension ou une amélioration de l'ensemble de l'infrastructure qui le supporte. Vous devrez peut-être également migrer vers d'autres systèmes si vous souhaitez tester de nouvelles applications ou de nouveaux modules que votre équipe développe avant de les mettre en production.. La logique sera de les tester avec des données réelles et pour eux vous devrez faire face à un migration de données d'un système à un autre.
Pouvez-vous imaginer combien d'erreurs peuvent survenir dans l'une de ces migrations de données si vous n'anticipez pas certaines choses et apprenez à les éviter?
Regardons cinq de ces erreurs et situations à éviter.
Imaginez que vous faites face à une migration car votre entreprise a fusionné avec une autre. Il est impossible que votre migration se passe bien si les utilisateurs qui connaissent les données des deux sociétés ne s'engagent pas avec votre service dès le départ pour choisir comment ils doivent intégrer ces données.
La même chose se produit si, bien qu'il ne s'agisse pas d'une fusion, vous essayez d'intégrer des données de plusieurs systèmes en un seul. Les personnes qui comprennent les données commerciales doivent s'identifier et vous aider.
De toute façon, les personnes qui utiliseront les données après le projet de migration devraient travailler avec vous pour vous aider à choisir comment s'intégrer les unes aux autres.
Vous êtes sur le point de déplacer des données du système A vers le système B. Qui est le propriétaire de ces données, qui peut autoriser la modification ou la suppression des données redondantes ou erronées? Assurez-vous que personne ne vienne plus tard pour vous demander des explications.
Les entreprises ne réalisent souvent pas qu'une évaluation des données à migrer est nécessaire avant de se lancer dans le travail coûteux de migration des données d'un système à un autre..
Vous devez comprendre la qualité des données existantes sur le système dont vous héritez; cas contraire, Vous pouvez tomber dans un grand piège où vous ne pouvez obtenir aucune information à partir des données migrées et passer des heures et des heures à essayer de les corriger ou de les améliorer.
Par exemple, tu devrais te poser ces questions: Les données système à migrer sont-elles utiles aux utilisateurs qui les utiliseront maintenant ?? Sont-ils bien liés et normalisés dans le référentiel de données actuel?
Ne laisse pas ça pour la fin. C'est vraiment nécessaire si vous voulez vous assurer que toute la procédure fonctionne correctement.
Posez-vous ces questions: Comment les données seront-elles testées? Qui les testera et les évaluera? Qui va approuver que le résultat à obtenir est celui souhaité? Qui est le consommateur final des données?
Les travailleurs d'une organisation peuvent être très bons dans ce qu'ils font, mais cela ne veut pas dire qu'ils sont des experts en gestion et migration de données. Ils sont souvent créateurs et consommateurs de données, mais sont familiers avec l'utilisation des outils, processus, prestations de service, modèles, etc. nécessaire pour une migration réussie.
Ensuite, Comme vous pouvez le voir, un migration de données d'un système à un autre à ne pas prendre à la légère. Il s'agit d'une procédure critique qui peut prendre beaucoup de temps et, si toutes ces choses ne sont pas prises en compte, ça peut être catastrophique.
