Déterminer l'approche de migration

Pour choisir une approche de migration, vous devez utiliser l'analyse que vous avez effectuée sur les modèles existants lors de la phase précédente. Les besoins futurs de votre entreprise en matière de données et d'analyses sont tout aussi importants. Les outils ETL traditionnels sur site traitent des modèles de données relationnels et des données structurées. Si vous avez des données semi-structurées et non structurées à traiter, vous pouvez utiliser AWS des services tels qu' AWS Glue Amazon EMR pour la migration. Parmi les autres facteurs susceptibles d'influencer l'approche migratoire, citons :

• Que vous souhaitiez utiliser une interface graphique (comme AWS Glue Studio) ou un framework personnalisé (comme les bibliothèques Spark/Python)

• Si vous disposez d'un accès sécurisé aux sources et AWS cibles sur site

• Compétences et formation requises pour l'équipe

• Exigences en matière d'audit et de conformité

Vous pouvez choisir entre trois approches de migration : big bang, phasée et lift and shift. Le tableau suivant compare ces trois approches.

Approche	Description	Cas d'utilisation	Avantages et inconvénients
Big Bang	Migrez tous les packages SSIS au cours d'une période donnée.	La complexité, la portée et l'architecture cible sont claires. L'équipe possède les compétences requises ou la courbe d'apprentissage est superficielle.	Risque élevé. Cela prend moins de temps que l'approche progressive. Vous pouvez utiliser AWS Glue Amazon EMR ou des frameworks personnalisés.
Progressif	Identifiez un package SSIS pour chaque modèle et chaque complexité distincts. Migrez le package vers l'architecture existante AWS, testez-le et comparez les résultats avec celle-ci.	Le temps n'est pas une contrainte. Vous souhaitez différents modèles pour différents modèles ETL.	Moins risquée que l'approche du big bang, mais elle demande plus de temps et d'efforts. Vous pouvez utiliser AWS Glue Amazon EMR ou des frameworks personnalisés.
Soulever et changer de vitesse	Migrez l'architecture actuelle telle quelle vers AWS.	Votre matériel sur site n'est plus pris en charge. Vous ne disposez pas des ressources nécessaires pour planifier une migration immédiatement.	Minimiser les efforts et le temps nécessaires à la migration. Les problèmes liés à la solution existante persistent AWS. Les packages SSIS sont exécutés tels quels. Aucun autre outil ou framework ETL n'est nécessaire.

La comparaison des données des systèmes source et cible est fondamentale pour une migration réussie. Le système de production existant étant régulièrement mis à jour par les systèmes sources, cette comparaison peut prêter à confusion. C'est pourquoi, lorsque vous déterminez votre approche de migration, nous vous recommandons de définir également votre stratégie de validation des données.

• Effectuez des sauvegardes de toutes les bases de données et de tous les fichiers applicables depuis l'environnement de production sur le système source à une date et à une heure spécifiques.

• Effectuez des sauvegardes de toutes les bases de données de l'environnement de production sur le système cible une fois que toutes les tâches ont correctement chargé les données à partir des données sources sauvegardées.

• Restaurez les données sources dans un environnement de test et exécutez les nouvelles tâches.

• Convenez d'un pourcentage de différences valides entre les bases de données source et cible (ancienne et nouvelle). Par exemple, vous pouvez décider qu'une différence inférieure à 1 % est acceptable.

• Répertoriez toutes les règles de validation à couvrir.

• Automatisez la comparaison autant que possible et couvrez toutes les règles.