Guide stratégique pour la migration des données

La migration des données consiste à déplacer les données d’un emplacement de stockage à un autre, que ce soit d’un datacenter on-premises vers le cloud, d’une plateforme de base de données à une autre, ou de baies de stockage traditionnelles vers une infrastructure moderne. L’exécution d’une migration sans stratégie claire peut entraîner des dépassements budgétaires, des pertes de données et des perturbations des opérations commerciales.

Les enjeux sont élevés. Selon une étude d’Oracle, plus de 80 % des projets de migration de données dépassent le temps et le budget. Ce chiffre ne s’est pas considérablement amélioré au fil des ans, non pas parce que la technologie est insuffisante, mais parce que les organisations sous-estiment la planification, le travail de qualité des données et la gestion des risques exigés par les migrations réussies.

Ce guide présente tout ce qu’implique une stratégie de migration de données : comment fonctionnent les migrations, quelle approche convient à votre situation, les risques à prévoir et un cadre de projet étape par étape pour maintenir votre migration sur la bonne voie.

Il n’est jamais facile de choisir de passer à un nouveau système. Mais lorsque votre environnement actuel ne répond plus à vos besoins, que ce soit en raison de contraintes de capacité, de limitations de performance, de modifications de licence ou d’une transition vers une infrastructure cloud, la migration devient inévitable. La question est de savoir comment y parvenir sans créer plus de problèmes que vous ne pouvez le résoudre.

Une solide stratégie de migration des données vous donne un chemin structuré de la planification à la désactivation. Il traite de la mécanique technique du transfert des données, des risques commerciaux impliqués et des processus de gouvernance nécessaires pour maintenir la précision et l’accessibilité des données tout au long de la transition.

La migration des données consiste à déplacer les données d’un emplacement de stockage à un autre, y compris les étapes de planification, de mappage, d’extraction et de formatage nécessaires pour garantir l’accessibilité et l’exactitude des données dans le nouvel environnement. Il comprend le transfert de bases de données, de fichiers, d’applications et de charges de travail entières entre des systèmes dont le format, la structure ou la plateforme peuvent différer.

La capacité à migrer efficacement les données est devenue essentielle, car les organisations traitent un nombre exponentiel de données dans des environnements plus divers. Autrefois, la copie d’une base de données d’un serveur à un autre implique souvent des plateformes cloud, des architectures distribuées et des exigences de conformité qui ajoutent une complexité considérable.

La plupart des migrations de données suivent un processus ETL général : extraire, transformer, charger, bien que les spécificités varient en fonction des environnements source et cible. La migration repose essentiellement sur les étapes suivantes :

• Analyser les données que vous souhaitez migrer pour identifier les problèmes de compatibilité entre les environnements source et cible, notamment les différences de schéma, les discordances de type de données et les incohérences de codage.
• Mappage des champs source avec leurs équivalents cibles. Une bonne documentation de mappage des données est essentielle pour détecter les erreurs de transformation avant qu’elles n’atteignent la production.
• Sauvegarder toutes les données avant le début de la migration. Ce n’est pas négociable. Sans sauvegarde vérifiée, une migration échouée peut entraîner une perte permanente de données.
• Testez votre logique de migration par rapport à une copie de l’environnement de production pour valider l’exactitude des données dans le système cible avant de vous engager.
• Extraction de données du système source à l’aide d’un chargeur de données ou d’une application ETL.
• Transformer les données si nécessaire pour se conformer au format, au schéma ou aux exigences de qualité des données du système cible.
• Chargement des données transformées dans l’environnement cible.
• Vérifier que les données transférées sont complètes, précises et accessibles, y compris le nombre de lignes, les sommes de contrôle et les tests au niveau des applications.

La plupart des migrations rencontrent des problèmes lors des étapes de mappage et de test. Les organisations qui traitent la migration comme une opération de copie pure, omettant un profilage et une validation des données rigoureux, ont tendance à détecter les problèmes de qualité des données uniquement après le basculement, lorsqu’ils sont les plus difficiles à corriger.

Il s’agit des risques les plus courants associés aux migrations de données et des raisons pour lesquelles chacun d’eux doit être abordé explicitement dans votre stratégie.

1. Dépasser le budget

Selon un livre blanc Oracle sur la migration des données, les dépassements de coûts sont en moyenne de 30 % et les dépassements de temps de 41 % pour les projets de migration des données. Ces dépassements remontent presque toujours à la sous-estimation de la complexité des données sources, en particulier la quantité de travail de nettoyage et de transformation nécessaire une fois que le profilage réel des données commence.

L’autre cause courante de dépassement de budget est la dérive du périmètre. Les migrations révèlent souvent des dépendances, des intégrations et des problèmes de qualité des données qui n’étaient pas visibles pendant la définition initiale du périmètre. Chaque découverte ajoute un travail non budgétisé. Les organisations qui introduisent des imprévus dans leurs budgets de migration, généralement de 20 % à 25 % au-dessus de l’estimation initiale, gèrent ces découvertes sans faire dérailler le projet. Ceux qui ne finissent pas par prendre des raccourcis ou à la recherche d’une approbation budgétaire supplémentaire en milieu de projet, qui présentent tous deux leurs propres risques.

2. de perte de données

La perte de données est un résultat courant des migrations qui sautent ou précipitent la phase de sauvegarde. Chaque plan de migration doit inclure une stratégie de sauvegarde vérifiée et testée avant le transfert des données. Cela signifie non seulement créer une sauvegarde, mais aussi confirmer que vous pouvez la restaurer.

La distinction est plus importante qu’elle ne semble. De nombreuses organisations découvrent, lors d’une tentative de restauration réelle, que leur sauvegarde est incomplète, corrompue ou incompatible avec l’environnement cible. Une sauvegarde qui n’a jamais été testée n’est pas une sauvegarde, c’est une hypothèse. Les tests de restauration doivent être une exigence de validation formelle avant le début de l’exécution de la migration, et non une réflexion après le basculement.

3. arrêt

Sans la géo-réplication ou les architectures exécutées en parallèle, la migration des données nécessite généralement de mettre les systèmes hors ligne. Cela affecte les performances des applications et l’accès des utilisateurs. L’approche de migration que vous choisissez, Big Bang, trickle ou zero downtime, détermine en grande partie le nombre d’arrêts que votre entreprise doit absorber.

Les estimations des temps d’arrêt permettent également d’être optimistes. Une fenêtre de migration prévue à quatre heures peut atteindre 12 si les volumes de données sont plus importants que prévu, si la logique de transformation s’exécute plus lentement que les étapes testées ou si les étapes de validation font apparaître des problèmes qui doivent être résolus avant que le basculement puisse se poursuivre. La communication d’une estimation réaliste des temps d’arrêt, et la création d’un tampon dans la fenêtre de maintenance, évitent le type de pression à mi-migration qui conduit à de mauvaises décisions quant à la poursuite ou à la reprise.

4. Corruption des données

La corruption des données se produit lorsque des données inutiles, mal formées ou incompatibles sont transférées dans le nouveau système. Les données corrompues peuvent provoquer des pannes d’application et produire des résultats inexacts, parfois plus difficiles à détecter que la perte de données purement et simplement. Un enregistrement manquant est évident, mais un enregistrement avec des valeurs subtilement erronées peut passer des semaines à l’insu.

Les sources courantes de corruption sont les discordances d’encodage de caractères entre les systèmes source et cible, les conversions de types de données qui tronquent ou transforment les valeurs en silence, et la logique de transformation qui gère les cas de périphérie de manière incorrecte. Le nettoyage rigoureux des données avant la migration et la validation après le basculement sont les principales défenses. La validation doit inclure à la fois des contrôles techniques : nombre de rangées, totaux de contrôle, vérification des contraintes, et des tests au niveau des applications qui confirment que les données se comportent correctement dans le contexte des processus métier réels.

5. Gravité des données

La gravité des données désigne la tendance des données à accumuler des dépendances : applications, services et autres ensembles de données qui s’y connectent au fil du temps. Plus un ensemble de données a de gravité, plus il est difficile de se déplacer sans perturber ces dépendances. Les organisations découvrent souvent que la gravité des données au cours de la migration lors du déplacement d’une base de données nécessite également de reconfigurer des dizaines de services connectés.

Ce risque est particulièrement prononcé dans les environnements qui ont connu une croissance organique pendant de nombreuses années. Les intégrations sont créées, les API sont codées en dur avec des chaînes de connexion et les outils de reporting sont orientés vers des sources de données spécifiques, souvent sans documentation centralisée. Un exercice approfondi de cartographie des dépendances pendant l’analyse des paysages est le meilleur moyen de faire apparaître ces connexions avant qu’elles ne deviennent des surprises pendant la journée de basculement. Chaque application, service et tâche planifiée qui touche les données migrées doit être identifié, testé et mis à jour dans le cadre du plan de migration.

6. Faible qualité des données

Les problèmes de qualité des données — duplication des enregistrements, formatage incohérent, valeurs manquantes et données obsolètes — ne disparaissent pas lors de la migration. Elles arrivent dans le système cible et deviennent les problèmes de votre nouveau système. Un processus d’examen et de nettoyage de la gouvernance des données avant la migration est le seul moyen fiable d’éviter cela. Les organisations qui ignorent le profilage des données avant la migration consacrent systématiquement plus de temps au nettoyage après la migration qu’elles n’auraient passé sur le nettoyage initial, et elles le passent dans des conditions pires, les utilisateurs étant déjà sur le nouveau système et les opérations commerciales en fonction de données qui ne sont pas encore dignes de confiance. Considérer la migration comme une opportunité d’améliorer la qualité des données, plutôt que de se contenter de la déplacer, produit un résultat significativement meilleur de l’autre côté.

Votre stratégie de migration définit la manière dont les données passent de la source à la cible : tout cela en même temps, par phases ou sans interruption perceptible. La bonne approche dépend de votre tolérance aux temps d’arrêt, de la complexité de votre environnement et de la criticité des systèmes migrés.

1. Migration Big Bang

Une migration Big Bang transfère toutes les données en une seule opération, généralement pendant une fenêtre de maintenance planifiée. Les systèmes sont hors ligne, le traitement ETL est exécuté et le système cible fournit l’ensemble complet des données.

L’avantage réside dans la simplicité et la rapidité. Il n’est pas nécessaire de maintenir des systèmes parallèles ou de gérer la synchronisation des données. L’inconvénient est l’exposition au risque : Si la migration échoue à mi-chemin, vous pouvez être confronté à une reprise ou à des temps d’arrêt prolongés. Le Big Bang fonctionne bien pour les ensembles de données plus petits, les systèmes dotés de fenêtres de maintenance naturelles et les organisations où un arrêt bref est acceptable.

2. Migration difficile

Dans une migration difficile, les données se déplacent par phases tandis que les anciens et les nouveaux systèmes fonctionnent en parallèle. Le système source reste actif pendant la migration, ce qui élimine les temps d’arrêt pour les utilisateurs. Les outils de synchronisation des données assurent la cohérence des deux environnements pendant la période de transition.

Les migrations complexes sont plus complexes à exécuter. L’exécution de systèmes parallèles nécessite une infrastructure supplémentaire, une logique de synchronisation minutieuse et un point de basculement défini où le nouveau système devient autoritaire. Mais pour les environnements critiques, cette complexité supplémentaire est souvent le bon compromis.

3. Migration sans arrêt

La migration sans temps d’arrêt est une extension de l’approche complexe qui utilise une réplication continue et un basculement quasi instantané pour éliminer toute interruption de service. Au lieu d’une fenêtre de maintenance planifiée, le basculement se produit lorsque le système cible atteint la parité avec la source. Cette approche est de plus en plus courante pour les organisations qui ont des exigences de disponibilité 24X7 ou des engagements SLA qui interdisent les arrêts.

La complexité des migrations sans arrêt est la plus élevée des trois approches, mais le risque d’interruption des activités est le plus faible. Les plateformes de stockage et de base de données modernes ont rendu cette approche plus accessible : des outils tels que la géoréplication et le clustering active-active prennent en charge la synchronisation continue à grande échelle.

La plupart des migrations d’entreprise ne rentrent pas proprement dans une seule catégorie. En règle générale, il est préférable d’utiliser une approche « stagnante » ou « zéro arrêt » pour les bases de données de production actives, tout en utilisant Big Bang pour les données d’archivage qui peuvent tolérer une brève indisponibilité.

Le type de migration est déterminé par ce que vous déplacez et les environnements impliqués. Chaque type a ses propres considérations techniques, modes de défaillance et exigences de planification. Comprendre quel type, ou combinaison de types, s’applique à votre projet est l’une des premières décisions que votre stratégie de migration doit prendre.

Migrations de bases de données

Une migration de base de données transfère des données ou des applications entre deux systèmes de base de données, soit pour changer de fournisseur, soit pour mettre à niveau le logiciel de base de données. Les facteurs déclenchants courants sont les annonces de fin de vie d’un fournisseur de bases de données, les modifications des coûts de licence, les limitations de performance de la plateforme actuelle ou le passage à des alternatives open source.

Les différences entre les schémas sont la principale source de complexité. Deux bases de données peuvent stocker des données conceptuellement similaires de manière structurellement incompatible, notamment : 

• Différents types de données
• Conventions de nom
• Règles de contrainte
• Approches d’indexation

Les procédures stockées et les fonctions personnalisées écrites dans le dialecte d’une base de données nécessitent souvent une réécriture pour le système cible.

Les dépendances applicatives compliquent la tâche. La plupart des bases de données de production sont utilisées par plusieurs applications qui les lisent et les écrivent. Chacune de ces applications doit être testée par rapport à la base de données cible avant le basculement, et toutes les requêtes qui reposent sur un comportement spécifique au fournisseur doivent être identifiées et réécrites. Le fait de manquer cette étape est l’une des raisons les plus courantes pour lesquelles les migrations de bases de données échouent après coup.

Que faut-il surveiller ?

• Des conversions implicites de types de données qui se comportent différemment selon les plateformes
• Différences d’encodage des caractères (UTF-8 et Latin-1, par exemple) qui corrompent les données textuelles
• Comportements de séquence et d’incrémentation automatique qui ne se transfèrent pas proprement entre les fournisseurs
• Déclencheurs et procédures stockées écrits dans des dialectes SQL spécifiques au fournisseur

Migrations vers le cloud

Les migrations cloud déplacent les données ou les applications des environnements sur site vers l’infrastructure cloud, ou entre les fournisseurs de cloud. Elles sont souvent les plus volumineuses et les plus complexes sur le plan organisationnel, car elles impliquent souvent des migrations de bases de données, des migrations de stockage et des migrations d’applications exécutées en parallèle.

Les migrations de type « lift-and-shift », qui déplacent les charges de travail vers le cloud avec un minimum de modifications, sont les plus rapides à exécuter, mais laissent souvent en place des problèmes de performances et de coûts. Le remaniement ou le remaniement des charges de travail pour tirer parti des services cloud natifs augmente la complexité de la migration, mais produit généralement de meilleurs résultats à long terme.

Les exigences de conformité, les règles de résidence des données et la latence du réseau ajoutent des dimensions auxquelles les migrations purement sur site ne sont pas confrontées. Le RGPD, l’HIPAA et d’autres réglementations peuvent restreindre le lieu de transit ou de résidence des données, même temporairement. Pour les organisations qui déplacent de gros ensembles de données, la bande passante réseau peut devenir un véritable goulet d’étranglement. Certaines migrations sont plus rapides et moins coûteuses en utilisant des services de transfert de données physiques que la transmission par câble.

Les migrations de cloud à cloud (passage entre AWS, Microsoft Azure et Google Cloud, par exemple) sont de plus en plus fréquentes à mesure que les organisations réévaluent les relations avec les fournisseurs ou consolident les environnements multi-cloud. Ces migrations nécessitent de comprendre les dépendances de services propriétaires qui se sont accumulées dans le cloud source, les API de stockage d’objets, les services de base de données managés, les fonctions sans serveur et de déterminer si des services équivalents existent sur le site de destination.

Que faut-il surveiller ?

• Coûts de sortie qui gonflent considérablement le budget de migration
• Dépendances de service propriétaires qui n’ont pas d’équivalent direct chez le fournisseur cible
• Résidence des données en conflit avec les exigences de conformité
• Impacts de latence sur les applications conçues pour un accès on-premises à faible latence

Migrations du stockage

Les migrations de stockage déplacent les données des baies de stockage existantes vers de nouveaux matériels. Ils font partie des types de migration les plus courants dans les environnements d’entreprise, en raison des cycles d’actualisation matérielle, des besoins d’extension de capacité et du passage des architectures à disques rotatifs aux architectures 100 % flash.

Contrairement aux migrations de bases de données ou d’applications, les migrations de stockage n’impliquent pas intrinsèquement la transformation des données. Le format des données ne change pas ; vous déplacez des blocs ou des fichiers d’un emplacement physique à un autre. Mais le risque opérationnel est tout aussi réel. Toute migration de baie de stockage qui interrompt l’accès aux données de production affecte chaque application et chaque utilisateur en fonction de ce stockage.

Les migrations basées sur l’hôte utilisent un logiciel exécuté sur le serveur pour copier les données de la source vers le stockage cible. Ils sont flexibles et ne nécessitent pas de matériel spécialisé, mais consomment des ressources de processeur et de mémoire du serveur pendant la migration. Les migrations basées sur des baies utilisent des capacités de réplication intégrées au matériel de stockage, ce qui génère généralement moins de frais généraux côté hôte et prend en charge le basculement sans interruption.

Pour les organisations qui utilisent des baies 100 % flash, les migrations de stockage coïncident souvent avec un effort de modernisation de l’infrastructure plus large. Passer d’un stockage sur disque hybride ou rotatif à un stockage 100 % flash modifie considérablement les caractéristiques de performance : les applications qui ont été conçues pour un stockage à latence plus élevée peuvent nécessiter une reconfiguration pour tirer pleinement parti du nouvel environnement.

Que faut-il surveiller ?

• Configuration multi-chemins d’hébergement qui doit être mise à jour lorsque les cibles de stockage changent
• Applications dotées de chemins de stockage codés en dur qui se rompent après la migration
• Différences de performances entre les baies source et cible qui affectent le comportement des applications
• Planification de la capacité qui tient compte de différents taux de réduction des données entre l’ancien et le nouveau matériel

Migrations d’applications

Les migrations d’applications déplacent les applications entre les environnements, sur site vers le cloud, dans le cloud vers le cloud ou vers une nouvelle plateforme SaaS. Il s'agit du type de migration le plus complexe à planifier et à exécuter, car ils déclenchent presque toujours les migrations de base de données et de stockage en tant que dépendances.

La complexité se complique rapidement. La migration d’un système ERP, par exemple, peut nécessiter la migration de sa base de données sous-jacente, du stockage sur lequel il s’exécute, des services réseau dont il dépend et des intégrations qu’il maintient avec d’autres applications, chacune ayant ses propres exigences de migration et ses propres contraintes de séquençage.

Les migrations d’applications présentent également le risque le plus élevé, quel que soit le type de migration, car elles affectent directement les utilisateurs et les processus métier. Une migration de stockage mal effectuée est un problème d’infrastructure. Une migration d’application mal effectuée perturbe les flux de travail dont les utilisateurs dépendent pour faire leur travail.

Les migrations SaaS, qui passent d’une application autogérée à un service cloud géré par le fournisseur, présentent un ensemble de défis différent. Vous migrez souvent vers un environnement multi-locataire avec des options de personnalisation limitées, ce qui signifie évaluer si la plateforme cible peut réellement prendre en charge vos flux de travail actuels avant le transfert de données.

Que faut-il surveiller ?

• Intégrations tierces qui se connectent à l’application via des API documentées ou non documentées
• Dépendances d’authentification des utilisateurs (LDAP, Active Directory) qui doivent être répliquées ou migrées
• Configurations et extensions personnalisées qui ne peuvent pas être transférées vers l’environnement cible
• Exigences de formation de l’utilisateur final qui doivent être prises en compte dans le calendrier du projet

Comprendre ces dépendances est important pour le séquençage. Les migrations de stockage doivent généralement être effectuées avant de pouvoir valider les migrations d’applications. Les migrations de bases de données doivent être exécutées avant le basculement des applications. Traiter ces éléments comme des flux de travail indépendants plutôt que comme une séquence dépendante peut entraîner des problèmes inattendus lors du basculement.

La qualité des données est le facteur le plus négligé dans la planification de la migration. Les organisations constatent constamment que leurs données sources contiennent des doublons, des mises en forme incohérentes, des enregistrements orphelins et des valeurs manquantes qui n’étaient pas visibles tant que les données n’étaient pas nécessaires pour se conformer à un nouveau schéma.

Une évaluation préalable à la migration doit comprendre trois éléments :

• Profilage des données : Analyse systématique des données sources pour identifier les problèmes de qualité, les distributions de types de données, les taux nuls et les violations des contraintes. Le profilage vous donne une image précise de ce que vous migrez réellement, et non de ce que vous pensez migrer.
• Nettoyage des données : Résoudre les problèmes identifiés pendant le profilage avant le début de la migration. Cela inclut la déduplication, la normalisation des formats, la correction des problèmes d’encodage et la suppression ou l’archivage des enregistrements obsolètes.
• Validation du mappage source-cible : Confirmer que chaque champ source a une destination cible valide, que les types de données sont compatibles et que la logique de transformation est documentée et testée.

Le résultat de cette évaluation doit être un rapport sur la qualité des données que les parties prenantes valident avant le transfert des données. Cela crée une responsabilité et empêche le scénario courant où les problèmes de qualité des données découverts après la migration sont imputés à la migration elle-même plutôt qu’aux problèmes de données sources préexistants.

Les migrations de données créent des fenêtres temporaires de risque élevé. Les données en transit entre les systèmes sont potentiellement plus vulnérables que les données stockées dans un environnement connu et sécurisé. Toute stratégie de migration qui traite des données réglementées, telles que des informations personnelles, des dossiers financiers ou des données de santé, doit répondre explicitement aux exigences de conformité.

Les principales considérations de sécurité pour les migrations sont les suivantes :

• Chiffrement en transit : Assurez-vous que les données sont chiffrées tout au long du pipeline de migration. Cela s’applique à la fois aux transferts réseau et aux environnements intermédiaires.
• Contrôles d’accès : Restreindre l’accès au système de migration au personnel autorisé uniquement. Les autorisations temporaires élevées accordées à des fins de migration doivent être révoquées immédiatement après l’achèvement.
• Journalisation d’audit : Tenir des journaux détaillés de tous les accès et mouvements de données pendant la période de migration. Ces journaux servent à la fois de dossiers opérationnels et de documentation de conformité.
• Résidence des données : Pour les organisations soumises au RGPD, à la loi HIPAA ou à d’autres réglementations sur la gouvernance des données, confirmez que les données ne transitent pas ou ne résident pas temporairement dans des juridictions non conformes pendant la migration.
• Politique de restauration : Définissez les conditions dans lesquelles vous annuleriez la migration et vérifiez qu’un rollback est techniquement réalisable avant le basculement. Un plan de restauration qui n’existe que sur papier n’est pas un plan de restauration.

Les exigences de conformité réglementaire doivent être examinées et documentées pendant la phase de planification préalable à la migration, et non découvertes pendant l’exécution. Engager rapidement vos équipes de sécurité et de conformité permet d’éviter les mises en attente de dernière minute qui peuvent transformer une migration de deux semaines en un projet de trois mois.

Toutes les migrations de données impliquent une forme d’ETL, mais la forme exacte de votre plan de migration dépend des besoins uniques de votre entreprise. Les étapes ci-dessus, le profilage des données, la sélection de la stratégie, l’examen de la sécurité, doivent toutes alimenter un plan de migration formel avant le début de l’exécution.

Un plan de migration doit préciser la portée des données transférées, la stratégie de migration choisie et les raisons, la politique de restauration, les critères de test de validation, les délais de communication avec les parties prenantes et le plan de désactivation de l’environnement source.

Un plan de projet de migration de datacenter vous permet de respecter les délais et le budget. Voici une structure étape par étape qui s’appuie sur une méthodologie de migration établie :

1. Planification préalable à la migration

Réaliser une évaluation de l’impact avant la migration pour vérifier le coût réel de la migration. Examinez si les estimations de coûts sont basées sur des analyses concrètes ou des hypothèses. Les chiffres du budget tirés des estimations des fournisseurs ou des moyennes du secteur sans référence à votre environnement spécifique sont susceptibles d’être inexacts. Informez les cadres et le service informatique de leur implication requise, y compris des engagements en termes de temps qui ont tendance à être sous-estimés jusqu’à ce qu’ils soient déjà en retard.

Obtenir l’approbation officielle de la gouvernance de la sécurité avant le début de tout travail technique. Déterminer la structure de livraison du projet (agile ou cascade), définir les rôles et le pouvoir décisionnel, concevoir un plan de formation et confirmer votre politique de gestion de la configuration. L’objectif de cette phase est de s’assurer que tout le monde est d’accord sur ce qui est fait et qui est responsable avant que quiconque touche un système.

2. Lancement du projet

Assurez-vous que votre back office est en ordre. Créer un plan de communication avec les parties prenantes qui précise qui reçoit les mises à jour, à quelle fréquence et par quel canal. Configurez votre plateforme de collaboration de projet, formalisez les accords avec les fournisseurs tiers et définissez les exigences matérielles et logicielles pour les phases ultérieures.

Ne sautez pas les accords avec les fournisseurs. Les migrations sont systématiquement bloquées, car aucun contrat fournisseur n’était en place lorsque du matériel ou des licences étaient nécessaires. Leur finalisation précoce permet d’éliminer une source potentielle de retard.

3. Analyse du paysage

L’analyse du paysage est la phase la plus importante de la planification de la migration, car elle détermine ce que vous migrez réellement, et non ce que vous supposez de migrer. Ces deux choses sont rarement les mêmes.

Créez un dictionnaire de données détaillé, une spécification de mappage source-cible de haut niveau et un rapport de définition du champ d’application. Déterminer les données volumétriques (quantité de données, nombre d’enregistrements, nombre de dépendances), établir un processus de gestion de la qualité des données, créer un registre des risques et affiner les estimations du projet en fonction de ce que vous découvrez. Les estimations produites avant l’analyse de paysage sont des indicateurs de position. Les estimations qui suivent sont des engagements.

4. Conception de la solution

Cartographier les transformations source-cible en détail et produire la conception finale pour la construction. Cette phase produit les artéfacts à partir desquels l’équipe de construction travaillera : spécifications détaillées de conception de mappage, spécification de conception d’interface et spécification de gestion de la qualité des données.

Définir les exigences matérielles de production et convenir d’accords de niveau de service pour la migration elle-même, pas seulement pour l’environnement cible après le basculement. Les migrations ont leurs propres exigences de performance et de disponibilité qui doivent être documentées et approuvées avant le début de l’exécution.

5. Création et test

Mettez en œuvre votre architecture de migration et testez-la en fonction de l’environnement réel, et non d’un petit échantillon. Les tests réalisés avec une fraction des données de production ne permettent souvent pas de détecter les problèmes de performance et d’évolutivité qui ne se produisent qu’à plein volume. Documentez la logique de migration dans son intégralité afin que tout membre de l’équipe puisse exécuter ou dépanner la migration sans s’appuyer sur les connaissances institutionnelles détenues par une seule personne.

Développer un moteur de validation pour confirmer indépendamment l’exactitude des données dans le système cible. Établir une surveillance continue de la qualité des données, créer une politique de repli et suivre la formation à l’exécution. L’équipe qui exécute la migration le jour du basculement aurait dû la répéter, et non pas l’exécuter pour la première fois sous pression.

6. Migration et validation

Exécutez la migration à l’aide de l’approche choisie : Le Big Bang, le chaos ou l’absence d’arrêt. À ce stade, la validation n’est pas une formalité, c’est le critère qui détermine si la migration est réellement terminée. Confirmer indépendamment que le nombre de lignes, les totaux de contrôle et les tests au niveau de l’application réussissent tous avant de déclarer la réussite.

Démontrer la conformité aux auditeurs et aux sponsors commerciaux dans le cadre de cette phase, pas après. Si la documentation de conformité est une réflexion après coup, attendez-vous à ce qu’elle entraîne des retards dans la mise en service du nouvel environnement.

7. Démantèlement et surveillance

Ne mettez hors service l’environnement hérité qu’une fois que le système cible a été validé et fonctionne de manière stable sous la charge de production. L’exécution indéfinie des deux environnements augmente les coûts et crée un risque de synchronisation, mais la réduction trop précoce avant la confirmation de la stabilité crée un ensemble de problèmes différent.

Transférer les responsabilités de surveillance de la qualité des données à l’équipe appropriée et documenter le transfert de manière explicite. Effectuer une validation de la mise hors service du système et documenter le processus de mise hors service à des fins d’audit. Les migrations qui se terminent au moment du basculement sans une phase formelle de désactivation ont tendance à laisser les systèmes orphelins fonctionner plus longtemps que prévu, souvent à un coût réel de l’infrastructure.

Les organisations qui exécutent des migrations avec succès ont tendance à partager quelques pratiques courantes que celles qui ont du mal à ignorer.

• Commencez par un audit des données, pas par un plan de migration. Comprendre l’état réel de vos données sources — problèmes de qualité, dépendances, volume — doit précéder toute planification stratégique. Les migrations concernées avant le profilage des données nécessitent presque toujours un recadrage en milieu de projet.
• Ne migrez jamais des données dont vous n’avez pas besoin. Les migrations sont l’occasion d’archiver ou de supprimer des données qui ne servent plus un objectif commercial. Le transfert de données inutiles augmente les coûts, le temps et les risques sans retour sur investissement.
• Testez avec des données à l’échelle de la production. Les tests réalisés avec un petit échantillon ne permettent souvent pas de détecter les problèmes de performances et d’évolutivité qui ne se produisent qu’à plein volume de production. Si votre ETL de migration nécessite deux heures de test, attendez-vous à ce qu’elle prenne 20 heures avec des données de production complètes.
• Définir les critères de réussite avant le basculement. Sachez exactement ce que signifie « migration réussie » avant de commencer : nombre de lignes spécifiques, contrôles d’intégrité, tests de fonctionnalité des applications. Sans critères définis, il n’existe aucune base objective pour déclarer la migration terminée.
• Communiquer avec les utilisateurs concernés. Les utilisateurs finaux et les propriétaires d’applications doivent savoir ce qui change, quand et que faire s’ils rencontrent des problèmes après le basculement. Une mauvaise communication transforme les réussites techniques en problèmes organisationnels.
• Planifiez la restauration avant d’en avoir besoin. Les plans de restauration doivent être testés, pas seulement documentés. La connaissance technique de votre procédure de restauration permet de réduire considérablement la pression de la fenêtre de basculement.

La migration des données passe d’une activité basée sur un projet à une capacité opérationnelle continue. À mesure que les entreprises adoptent des stratégies multi-cloud et déplacent les charges de travail de manière dynamique entre les environnements, la distinction entre « migration » et « gestion des données de routine » devient floue.

L’automatisation est à l’origine de ce changement. Les outils de profilage de données assistés par l’AI peuvent désormais identifier les problèmes de qualité et suggérer des règles de transformation sans analyse manuelle. Les plateformes de migration intelligentes peuvent surveiller la synchronisation des données en temps réel et signaler les anomalies pendant les migrations lentes avant qu’elles ne deviennent des problèmes. Les plateformes de stockage basées sur des architectures de structure de données prennent de plus en plus en charge la mobilité des données sans interruption en tant que capacité native plutôt qu’en tant que procédure exceptionnelle.

Les organisations qui intègrent la préparation à la migration dans leur infrastructure de données, plutôt que de la traiter comme une capacité ponctuelle, auront un avantage structurel à mesure que les environnements de données continuent d’évoluer. Le meilleur moment pour établir des pratiques et des outils de migration est avant l’annonce de la prochaine migration.

Le stockage de données est un élément fondamental de chaque migration. Sans une infrastructure de stockage qui prend en charge les mouvements de données sans interruption, les organisations doivent faire face à un choix difficile entre des temps d’arrêt prolongés et des solutions de contournement complexes.

Basées sur l’architecture Evergreen®, les offres d’abonnement Everpure sont conçues pour faciliter les migrations de données et les rendre plus abordables en éliminant les cycles de mise à niveau et les fenêtres de maintenance nécessaires aux baies de stockage traditionnelles :

• Evergreen//One™ réduit la complexité et le coût de l’administration et du support du stockage, en offrant une flexibilité financière et une simplicité opérationnelle tout en limitant les risques informatiques.
• Evergreen//Flex™ vous offre la flexibilité nécessaire pour répondre aux changements de demande et d’utilisation, renforcer l’agilité du stockage et maximiser le retour sur investissement sur l’utilisation de la capacité tout en réduisant les coûts initiaux.
• Evergreen//Forever™ offre une véritable agilité informatique : achetez votre stockage une seule fois et faites évoluer votre environnement sans interruption, sans pénalité, indéfiniment.

Pour les organisations qui migrent vers ou entre des environnements cloud, la plateforme de stockage unifié Everpure assure la résilience et la continuité des données tout au long du cycle de vie de la migration. Il en résulte des migrations moins perturbatrices, plus prévisibles et moins susceptibles d’entraîner des dépassements de coûts et de délais qui caractérisent la majorité des projets de migration.

Explorez le portefeuille Everpure Evergreen pour découvrir comment une infrastructure de stockage spécialement conçue peut simplifier votre prochaine migration de données.