Migrer dans le Cloud, pas à pas vers 100 % de réussite

Après l’assessment vient la migration proprement dite dans le Cloud. Cet article a pour objet d’illustrer la façon dont Digora accompagne l’entreprise jusque dans les moindres détails de son projet. Rien n’est laissé au hasard, car cette étape de migration, bien conduite, participe à construire la confiance de l’entreprise et de ses équipes dans des services Cloud qu’elles seront amenées à exploiter quotidiennement.

Assurer la portabilité dans le Cloud : faire évoluer l’architecture

IaaS, PaaS voire SaaS ? Cette question est évidemment abordée très tôt, dès l’assessment véritablement, car elle conditionne entièrement la méthode. Le PaaS et le SaaS ne tolèrent que des assets dont les versions sont à jour, prêts pour le Cloud. 
Or, entre des applications tierces dont l’éditeur n’a pas sauté le pas du Cloud, des applications « maisons » que l’on n’a pas le temps de maintenir et des bases de données que l’on n’a jamais fait évoluer, une migration Cloud peut être vite remise en question. 

Même si cumuler Up to Date et migration reste une opération faisable, avec beaucoup de méthodologie et des tests à blanc rigoureux, ce n’est généralement pas conseillé. 95 % des bases de données ne profitent jamais des dernières mises à jour. Or, faire évoluer une très ancienne version (une situation courante en entreprise), qui plus est privée de support, requiert beaucoup de temps et d’attention.
Nous recommandons en général d’opter pour une migration iso puis d’opérer la montée de version une fois dans le Cloud. Le procédé permet de provisionner des environnements sandbox à moindre coût, que l’on veillera à éteindre le soir tout simplement. C’est aussi la formule la plus courante puisque rares sont les entreprises à disposer on premise des serveurs, espaces et CPU disponibles pour un upgrade avant migration. 

Si l’approche en termes de migration reste la même quel que soit le CSP choisi, la question demeure du point de vue des applications, lesquelles peuvent présenter le plus de résistance à la migration. Il faudra alors compter avec un délai supplémentaire, incompréhensible, surtout s’il dépend du bon vouloir d’un éditeur. Mais c’est aussi un appel d’air pour l’entreprise, qui profitera de ce passage pour rénover ses applications maison, consolider sa sécurité en optant, dans le cadre du maintien en conditions opérationnelles, pour des sessions de patchs et réaliser un important ménage dans son infrastructure.

Les bonnes pratiques de la migration

Deux points majeurs méritent toute l’attention, la sécurité et le réseau. 

Côté sécurité, les CSP mettent à disposition de nombreuses briques (bastions, double authentification, etc.), à titre gratuit parfois ou plus souvent à coût contenu, compte tenu de la facilité de mise en œuvre, en comparaison des lourdes solutions on premise sous licences. 
Toutefois, l’étude des besoins réels de l’entreprise en cyber sécurité demeure indispensable pour ne pas payer des solutions packagées dont une partie peut vite se montrer superflue. 

Et parce que la sécurité c’est aussi le respect et l’application des textes, Digora fait intervenir son RSSI auprès du DPO de l’entreprise, pour traduire techniquement la réglementation adéquate. RGPD, données financières, données de santé, il faut aussi savoir impliquer le Cloud Provider sur ces aspects pour s’assurer qu’il dispose des niveaux de certification suffisants. 

La partie réseau ensuite peut offrir quelques complications selon la localisation de l’entreprise, ses interconnexions mais également la taille du projet. La mise en place de liens réseaux fait intervenir de multiples interlocuteurs, susceptibles de retarder la migration de plusieurs mois si la question est traitée trop tardivement ou si le projet implique une mise en œuvre physique. 
En effet, dans une démarche move to Cloud massive, des liens dédiés et robustes peuvent nécessiter des travaux, quand un petit projet se satisfera d’un VPN IPsec classique. 

Outre le réseau, les flux réseaux impliquent une importante réflexion sur leur architecture pour éviter l’écueil de latence induite par les sauts et ponts réseaux depuis le CSP.

POC et migration proprement dite

L’entreprise qui se dirige vers une infrastructure hybride ou du Multicloud gagne à opter pour un POC avant une mise en production. Le POC permet sur plusieurs mois d’évaluer la faisabilité d’un projet, les besoins réels en performance et l’architecture réseau, sans être dispendieux. C’est aussi là une bonne occasion de tester les mises à jour, d’identifier leurs répercussions sur les applications et les requêtes inabouties. Par ailleurs c’est avec un POC que les équipes peuvent tester les nouveaux services disponibles et les nouvelles options des bases de données. 
Une fois validé, l’environnement est alors conservé en tant qu’environnement de production. 

Hors POC, un environnement de recette est créé pour une migration à blanc, dont l’utilité en premier lieu est d’évaluer le downtime réel que supporte l’entreprise, c’est-à-dire la période d’interruption de service tolérée. En son absence, il est impératif d’employer des mécanismes de migration à chaud. 
L’environnement de recette permet de valider l’entièreté du cahier de test avec l’ensemble des interlocuteurs. Il arrive que plusieurs MEP à blanc soient programmées pour atteindre progressivement les 100 % de réussite, et ce même si ce taux est atteint dès la première mise en production. 
Digora affiche 100 % de taux de réussite des migrations de bases de données qui lui sont confiées.