« On bascule le week-end. » C'est la phrase qui précède les lundis difficiles. Une migration cloud n'est pas un déménagement de cartons. C'est un graphe : DNS, identités, bases, fichiers, jobs de nuit, VPN, licences, gens qui se connectent à 8 h. Tout couper le samedi, tout rallumer le dimanche, ça marche dans les slides. Dans une PME, il manque toujours une imprimante réseau, un cron, un certificat, un partenaire qui pointe encore vers l'ancienne IP.
Nous migrons par lots. Avec un repli. Au TJM de 1000 HT, EUR ou CHF. Pas un forfait miracle annoncé avant l'audit. France et Suisse, à distance sur les consoles, sur site si le dossier le justifie.
Pourquoi le « big bang » casse
Le big bang suppose un inventaire parfait. Personne n'en a un. Les dépendances cachées (un vieux NAS qui authentifie encore, un accès prestataire en dur, un fichier hosts sur le PC du gérant) apparaissent pendant la coupure. Plus la fenêtre est unique, plus le rollback est un vœu.
Nous cartographions d'abord : applications, données, identités (souvent Entra ID / Microsoft 365 déjà là), réseau, ce qui doit rester au bureau. Ensuite des vagues. Exemple : d'abord le fichier peu critique, puis une appli de recette, puis la prod, le DNS en dernier ou presque, avec un TTL baissé avant, pas le jour J.
Le dirigeant veut une date unique pour « en parler au comité ». Le profil technique veut des critères de réussite par vague (latence, jobs OK, utilisateurs OK). Nous écrivons les deux : une trajectoire, pas une nuit héroïque.
AWS, Azure, GCP, OpenStack : la cible n'est pas le logo
La question n'est pas « qui est le plus moderne ». C'est : vos équipes sont déjà dans Microsoft 365 ? Azure et Entra se parlent. Vous avez une contrainte de résidence en Suisse ? OpenStack ou un hébergeur souverain se discute. Vous avez déjà de l'AWS ? On n'ajoute pas un GCP « pour voir » sans propriétaire.
La migration n'est pas le FinOps. On peut arriver sur un cloud plus cher qu'un serveur bien tenu, si on copie les mauvaises habitudes (recette 24/7, disques orphelins). On le dit avant. On étiquette dès la première instance.
Ce que l'audit doit sortir
- Ce qui ne migre pas (imprimante, automate, appli métier sur dongle).
- RPO / RTO : quelle perte, quel délai, déjà évoqués pour le PRA.
- Qui a les comptes root. Un cloud dont l'admin est un freelance parti, ce n'est pas une cible, c'est un chantier d'identités.
- Le réseau : VPN, peering, utilisateurs à Genève et en France, latence réelle.
Sans ça, le devis est un dessin. Avec ça, le TJM a un sens : des jours d'audit, puis des jours d'exécution, pas une ligne « migration cloud » au forfait.
Le run se discute après. Rester sur du TJM infini pour éteindre des machines, ce n'est pas de l'exploitation. Un forfait de run, une fois les uns stables, si.
Comment nous procédons
- Audit 1 à 3 semaines selon le SI.
- Cible et lots, validés avec vous, y compris le lot « on ne touche pas ».
- Vagues avec repli, DNS maîtrisé, tests utilisateurs.
- Documentation : pas un wiki mort, les accès et les runbooks que le helpdesk peut lire.
Nous avons vu des bascules où le DNS a été changé trop tôt, TTL encore à 24 h, une partie des utilisateurs sur l'ancien serveur, l'autre sur le nouveau, les deux écrivant dans des bases différentes. Le lundi, on fusionne à la main. Baisser le TTL une semaine avant, migrer les données, basculer, garder l'ancien froid 48 h : c'est moins héroïque. C'est ce qui évite le lundi.
Si on vous a vendu « un week-end et c'est plié », faites relire le plan. Nous vous disons où il va casser, avant le samedi.