Une migration vers le cloud réussit rarement par hasard : elle repose sur un inventaire précis, un plan de bascule écrit et un retour arrière testé. Ce guide décrit la méthode appliquée sur les infrastructures prises en charge par Open Vista, de l'audit initial jusqu'à la vérification après coupure.
1. Inventorier l'existant avant tout déplacement
L'audit commence par une cartographie complète de ce qui tourne aujourd'hui :
- serveurs et machines virtuelles, rôle, système d'exploitation et version ;
- applications, dépendances (base de données, file d'attente, cache, stockage partagé) ;
- volumes de données, rythme de croissance et durée de conservation ;
- noms DNS, enregistrements et durée de vie (TTL) ;
- certificats TLS, boîtes e-mail, flux entrants et sortants ;
- tâches planifiées, scripts internes et intégrations tierces ;
- sauvegardes existantes et date du dernier test de restauration.
Relevez en parallèle les métriques réelles (vCPU, mémoire, IOPS, bande passante) sur deux à quatre semaines : ce sont elles qui dimensionnent la cible, pas les fiches techniques d'origine.
2. Écrire le plan de migration
Le plan se rédige avant de toucher à la production. Il fixe le découpage en vagues successives, de la charge la moins critique à la plus critique, et l'ordre des dépendances entre applications. Il indique aussi, pour chaque service, une fenêtre de bascule annoncée aux utilisateurs, un objectif de temps de reprise et de perte de données admissible, une matrice « qui exécute, qui vérifie, qui décide » et des critères de go/no-go explicites. Un plan refusé par les métiers n'est pas un plan : il se valide avec eux.
3. Préparer la cible et répéter la procédure
La cible est provisionnée et dimensionnée d'après les mesures de l'audit. Avant la bascule, l'environnement est reconstruit et testé hors production : restauration des données, installation des certificats, rejeu des tâches planifiées, tests fonctionnels, mesure des performances sous charge réaliste. Un site pilote, choisi pour son faible impact et sa représentativité, valide la procédure complète avant sa généralisation.
4. Réaliser la bascule
Le jour J se déroule dans une fenêtre de changement gelée. Abaissez le TTL des enregistrements DNS 24 à 48 heures avant, afin que la propagation soit rapide. Après la dernière synchronisation, contrôlez au minimum :
dig +short www.exemple.ma curl -sI https://www.exemple.ma | head -1
Puis vérifiez l'authentification, l'envoi et la réception des e-mails, les webhooks sortants, les tâches planifiées, la journalisation et les intégrations. Chaque contrôle a un résultat attendu et un responsable ; un contrôle non conforme déclenche le retour arrière.
5. Garder un retour arrière utilisable
Le retour arrière n'est crédible que préparé et testé. Conservez l'ancienne infrastructure en état de marche pendant toute la période d'observation convenue, les sauvegardes complètes prises juste avant la bascule, et une procédure écrite qui précise le délai de retour, les étapes et la personne qui décide de l'appliquer. Ne décommissionnez l'ancien environnement qu'après validation par les utilisateurs et par l'équipe d'exploitation.
6. Stabiliser après la migration
Les quatre premières semaines servent à observer : disponibilité, temps de réponse, saturation, coûts. On ajuste les ressources, on revoit les alertes et les sauvegardes, on durcit les accès et on forme les équipes aux nouveaux réflexes. Un rapport de fin de migration documente les écarts constatés, les décisions prises et les points à surveiller, pour que la prochaine migration soit plus courte.
