La migration cloud peut prendre différentes formes : trouvez la stratégie adaptée à vos besoins

Vous est-il déjà arrivé de dire des choses qui vous ont surpris vous-même ? Par exemple, lorsque vous réalisez que vous parlez exactement comme vos parents. J’en ai peut-être, ou peut-être pas, déjà fait l’expérience, qui sait ! Et là, je viens de m’entendre dire que je trouvais les stratégies de migration passionnantes. 

Oui, tout à fait. La façon dont une entreprise migre ses processus opérationnels entre son infrastructure existante et le Data Cloud Snowflake m’intéresse au plus haut point. Pourquoi ? Tout simplement parce qu’il s’agit d’un défi complexe. Pour Snowflake, il ne s’agit pas moins que de transférer une base de données existante, des pipelines de données et une couche de services avec des outils de reporting et d’analyse, ainsi que les rapports et les tableaux de bord proprement dits. Et cela implique de tenir compte non seulement de la technologie, mais également des individus et des processus impliqués. Le fait que le témoignage qui a suscité mon intérêt ait été rapporté par l’un de mes clients préférés (il ne s’agit pas de favoritisme, voyons…) n’y est pas non plus pour rien.

J’ai longtemps pensé que le passage à une nouvelle architecture n’avait pas besoin d’être un « Big Bang ». Il y a plusieurs années, le Chief Data Officer (CDO) d’une entreprise de vêtements d’extérieur m’a confié qu’ils avaient créé une nouvelle architecture de données, mais que celle-ci ne pouvait pas être mise en service avant que les données ne soient toutes stockées dans leur data lake. Ils voulaient éviter de faire la moindre erreur et ne souhaitaient utiliser la plateforme que lorsqu’elle serait prête. Cette situation durait déjà depuis plusieurs années. 

Un autre CDO m’a raconté comment il avait abordé la question en adoptant une approche plus pragmatique et progressive. Plutôt que d’annoncer à l’entreprise qu’il allait mettre en place un environnement commun (et de la faire attendre), son équipe a travaillé en étroite collaboration avec chacune des unités commerciales pour obtenir les informations nécessaires, en veillant à les intégrer à une infrastructure back-end et à des outils de visualisation communs. Au fil du temps, l’équipe a créé un nouveau « magasin d’informations d’entreprise » comprenant des capacités de tableaux de bord communes à toutes les marques. Cette grande annonce a beaucoup surpris les parties prenantes de l’entreprise, mais n’a pas fait l’effet d’un « Big Bang » du point de vue de la migration. Personne n’a dû attendre des années pour obtenir les informations dont il avait besoin. Cette approche progressive a permis de créer de la valeur tout au long du processus. C’est alors que je suis devenue une « progressiste » convaincue… Du moins, jusqu’à tout récemment.  

Le mois dernier, j’ai pu participer au Snowflake Data Cloud World Tour organisé à Toronto. C’était un événement extraordinaire avec des conférences passionnantes et des échanges en marge des panels qui l’étaient encore plus. Pendant une pause, je me suis retrouvée en compagnie des responsables data d’un retailer canadien et d’un fournisseur d’assurance, et la conversation s’est orientée vers les stratégies de migration. Quoi de plus normal ? 

Au fil de nos échanges, je leur ai fait part d’une discussion que j’avais eue récemment avec un autre client qui rencontrait des difficultés. Il avançait péniblement dans son projet de migration vers l’architecture qu’il souhaitait mettre en place et se préparait à un Big Bang. Cette situation m’a rappelé celle de l’entreprise de vêtements. Mes interlocuteurs acquiesçaient de la tête. Mais lorsque j’ai évoqué l’autre méthode, l’approche progressive, l’une de mes partenaires de pause s’est complètement désolidarisée. D’après son expérience, la meilleure stratégie était celle du Big Bang : se lancer et faire les choses rapidement. Sa stratégie de migration consistait en un portage sans modification à grande échelle. Il ne s’agissait pas d’une refonte de l’architecture, mais simplement d’un transfert vers une nouvelle infrastructure. Son entreprise utilisait une ancienne plateforme on-premise qui ne répondait plus à ses besoins réels et dont la maintenance était coûteuse. Ce portage sans modification de type Big Bang leur a évité d’exploiter deux systèmes en même temps, leur priorité étant de se débarrasser au plus vite de leur ancien système. 

Nos échanges ne s’en sont pourtant pas arrêtés là. Elle nous a alors raconté que, à la suite du transfert vers la nouvelle plateforme, certains rapports et tableaux de bord existants ne fournissaient aucune valeur concrète à son entreprise. Et c’est bien là que réside le défi d’une stratégie de portage sans modification : on se retrouve souvent avec des bagages inutiles sur les bras. 

Alors, quelle solution adopter ? Ma collègue de pause avait choisi de tout mettre à l’arrêt. Oui, vous avez bien lu. Leurs 80 000 rapports et tableaux de bord migrés ont été désactivés, purement et simplement. Bien sûr, comme vous pouvez l’imaginer, cette décision a provoqué un tollé, même si celui-ci n’a pas été aussi virulent que ce à quoi ils s’attendaient. Certains rapports n’étaient finalement pas vraiment prisés par les utilisateurs. Et seuls quelque 3 000 d’entre eux ont été réactivés. Au final, cette histoire s’est bien terminée. Et, je dois bien le reconnaître, cette responsable data canadienne a un mental d’acier.

En conclusion, force est de constater que la migration est un défi, qui peut être relevé de différentes manières. Il convient donc de faire des choix concernant deux aspects : la stratégie de migration proprement dite et l’approche en matière de « transition ». 

Cette transition s’effectue soit en une seule fois (approche Big Bang), soit en plusieurs étapes (approche progressive) :

• Approche Big Bang : migration de l’ancienne plateforme vers la nouvelle en une seule opération réalisée à un instant T et dont les avantages se manifestent à ce moment-là.
• Approche progressive : migration de plateforme divisée en plusieurs composantes gérables exécutées sur une période donnée, dont les avantages s’accumulent étape par étape.

Ensuite, les stratégies de migration doivent refléter les éléments à déplacer et leur destination. Si vous ne souhaitez pas apporter de changements immédiats, vous allez extraire les données existantes et les transférer vers la nouvelle plateforme (portage sans modification). Si vous préférez opérer des changements en amont, vous devrez procéder à des ajustements afin d’optimiser votre environnement pour le cloud (portage avec amélioration) ou redévelopper votre infrastructure avant sa migration (refonte). Enfin, vous pouvez opter pour l’approche de transition qui vous convient le mieux. Chacune de ces approches a ses avantages et ses inconvénients.

L’illustration ci-dessous présente trois stratégies de migration courantes : 

En définitive, il n’existe pas de solution universelle. L’approche appropriée dépend de l’entreprise, de sa plateforme existante et de son appétence pour le changement. Un portage sans modification de type Big Bang peut ne pas sembler être la solution la plus optimale. Vous migrez tout d’un bloc, sans séparer le bon grain de l’ivraie. Cependant, les échanges que j’ai pu avoir au Canada m’ont appris qu’il est parfois préférable d’opter pour ce type de démarche. Ce qui compte, c’est d’apporter de la valeur le plus rapidement possible, qu’il s’agisse d’une valeur progressive provenant d’une nouvelle plateforme dans le cadre d’une approche par étapes ou d’un changement radical permettant de se départir d’une ancienne plateforme coûteuse. 

L’équipe des services professionnels Snowflake vous recommande, indépendamment de votre stratégie de migration, de suivre plusieurs étapes de base :

• Test du projet : identifiez un premier cas d’usage à forte valeur commerciale qui vous permettra de tester la migration de votre plateforme actuelle vers Snowflake.
• Définition du périmètre : en fonction des enseignements tirés de la démonstration de faisabilité/du projet pilote, identifiez ce qui relève ou non du périmètre de migration de votre plateforme actuelle vers Snowflake.
• Planification : établissez un plan de migration en définissant les coûts, les délais, les tâches et les ressources nécessaires à la migration entre votre plateforme actuelle et Snowflake.

Veillez également à disposer de toutes les informations dont vous avez besoin pour prendre vos décisions concernant la migration de votre infrastructure. Le questionnaire ci-dessous, que nous utilisons dans le cadre de l’évaluation de la préparation à la migration vers Snowflake, constitue un excellent point de départ.

Si vous souhaitez en savoir plus sur l’accompagnement que Snowflake peut vous proposer dans le cadre de votre migration et au-delà, je vous invite à vous rapprocher de nos collaborateurs de l’équipe des services professionnels Snowflake, ainsi que de l’équipe des formations et programmes d’éducation Snowflake.