Réussir sa migration Cloud en introspectant le système source



Réussir sa migration Cloud en introspectant le système source

 

 

La migration des données vers le Cloud est une entreprise périlleuse qui nécessite une organisation rigoureuse. Peut-être un peu plus…  

 

Nous avons la conviction que la clé du succès de ces migrations est de réellement connaître les données et les processus qui sont en source. En somme, de faire un véritable état des lieux et corriger les innombrables problèmes avant « déménagement » !

 

Car le manque de connaissance et de compréhension de la plateforme en source peut sérieusement compromettre, voire même faire échouer un projet de migration.  On vous explique ça.

 

Tous dans le Cloud !

Gartner a récemment indiqué que le marché du cloud public avait explosé, avec une croissance de 41,4 % en 2022 suivi d’une croissance de plus de 20 % en 2023, pour atteindre pratiquement 600 milliards de dollars !

 

Le Cloud joue un rôle dans la croissance des entreprises : pour répondre aux exigences des tendances commerciales actuelles, 46 % des entreprises avaient prévu d'intensifier leurs efforts de transformation numérique entre 2022 et 2023. Et quand on parle de transformation, il s’agit pour l’essentiel de migrations Cloud.

 

Le entreprises n’ont plus le choix, mais les obstacles sont nombreux. 

 


 
 

Le chemin tortueux vers une migration réussie

Pour les entreprises, la perspective d’une migration de données peut être assez effrayante :

  • Elles se disent bien que les processus affecteront tous les aspects de l’exploitation, à commencer par le business. Une perspective très angoissante.  
  • Les personnes qui ont la charge de cette migration se font bien préciser qu’il faut de surcroît respecter le budget et le calendrier, ce qu’elles savent très hypothétique.

 

Ces injonctions sont si difficilement conciliables que de nombreuses migrations ne sont pas mises en œuvre. A juste titre, car de nombreux projets de migration échouent.

 

"Seulement 16 % des migrations ont été terminées dans les délais et en dessous du budget prévu" (Scientific Research OpenAccess).

 

"Plus de 80 % des migrations ne parviennent pas à être livrées à temps et/ou dépassent le budget prévu" (ItToday).

 

Mais pourquoi les migrations Cloud échouent-elles ?

Il existe un certain nombre de facteurs qui contribuent aux échecs d’une migration. 

Chaque migration est évidemment unique, car les datasets et l'architecture de chaque entreprise sont différents, les moyens mis en œuvre aussi, et donc les raisons des échecs le sont nécessairement. Mais certains écueils sont généralisables.   

 

Pas de réelle introspection du système en source

 

Il existe un premier dénominateur commun à tous les échecs de migration : le manque de compréhension des données et des flux au sein de l’architecture source.

 

Sans informations granulaires sur l’ensemble du patrimoine qu’il faut réellement migrer, un certain nombre de problèmes surviennent :

  • Les équipes peuvent être sensiblement perturbées par des données manquantes ou incomplètes après migration, et pire, inexactes.
  • Il peut y avoir des violations de réglementation si certains types de données sont déplacées de manière inappropriée.
  • Le transfert de données/processus non pertinents peut allonger la fenêtre de migration, augmentant ainsi les coûts et les retards. 
  • Les problèmes qui auraient dû être solutionnés en source le sont au sein du nouvel environnement, ce qui enlève du temps et des ressources aux projets à réelle valeur ajoutée.

 

Notre approche


  • Les usages de la donnée : l’analyse des usages des données doit être défini pour savoir quelle direction métier sera affectée, et à travers quels outils le cas échéant.
  • Définir les pipelines de données utiles : quand les données ayant réellement un usage sont couplées à leur source via le « data lineage », on parvient à discriminer pour l’ensemble du système en source « le bon grain de l’ivrai », et il devient possible d’opérer de vastes décommissionnements en amont de la migration. Souvent, 50 % du système n'a pas d'usage. 

 

Avec les données et les processus réellement utiles dans le système source, il devient possible de définir l’effort à produire pour migrer, ainsi qu’une timeline réaliste. Ensuite, il est possible de hiérarchiser la migration en fonction des impacts métiers.  

 

 

L’incomplétude des migrations

 

Pour migrer, il s’agira d’aller choisir un outil de transfert des données vers le Cloud qui permettra de déplacer la donnée et les processus vers la cible. Le marché en propose pléthore.  

 

La simple réécriture du code dans le langage cible générera d’innombrable régressions hyper dommageables.

En effet, les outils de transformation de données propriétaire (ETL/ELT) traitent souvent une large partie des transformations. Les schedulers ordonnancent les flux, etc.

Si la migration doit être « As Is », elle doit donc inclure le code, mais aussi les job ETL et l’ordonnancement, soigner les dépendances, l’articulation avec les outils de dataviz, etc. C’est infiniment plus complexe. Et ça n'est jamais traité de façon exhaustive. 

Notre approche


La traduction du code, c’est donc bien une proportion très limitée de l’effort !

Notre vocation est d’adresser automatiquement l’exhaustivité du stack technique en source pour faire une migration « As Is », enfin pas totalement, puisque nous aurons pris soin d’épurer et d’optimiser le système en source !

 

Pour ce faire, nous posons des sondes et des parsers sur l’ensemble des technos de stockage, de processing, d’ordonnancement, d’exposition de la donnée, avec des analyses rejouées en continue.

Sur la base de l’information recueillie, la migration devra être conduite de façon ultra rapide, en automatisant l'ensemble des processus pour que le métier puisse très vite se servir de la plateforme cible, en confiance.

 

Puis, nous allons comparer le système en source (une fois "nettoyé / optimisé") avec le système en cible pour garantir une fonctionnalité iso.

 

Conclusion 

 

Les migrations Cloud sont souvent des échecs car elles sont conduites de façon largement manuelle et empirique.

Résultat, elles s’étirent dans le temps et n’aboutissent que rarement aux résultats attendus. Nous proposons une méthodologie en 2 actes permettant de toucher à la cible sereinement, dans des délais contraints et dans le budget annoncé.

Pour ce faire, notre forte capacité d’introspection des systèmes legacy mise en œuvre chez de nombreux clients grands comptes nous a permis de créer un authentique catalyseur de migration Cloud.  


Commentaires

Posts les plus consultés de ce blog

La Data Observabilité, Buzzword ou nécessité ?

BCBS 239 : L'enjeu de la fréquence et de l'exactitude du reporting de risque

Le data lineage, l’arme idéale pour la Data Loss Prevention ?