Migrer dans Azure quand c’est la bonne réponse.

Non, et c’est même rarement le bon plan. Dans presque tous les parcs que nous auditons, il existe des machines pour lesquelles Azure coûte plus cher que l’existant, ou dont l’éditeur ne supporte pas le déplacement. Ces machines restent où elles sont, et elles sont gouvernées avec les autres.

Le mouvement utile est presque toujours partiel. Ce qui compte, c’est que la frontière soit choisie sur des chiffres et écrite, plutôt que fixée par ce qui a été facile à migrer en premier.

Oui pour la production : les données au repos dans la région de Zurich restent en Suisse, et cette région dispose de trois zones de disponibilité — on peut donc y construire de la haute disponibilité sans sortir du pays.

La nuance est sur la reprise après sinistre. La région appairée de Genève est classée à accès réservé : elle s’obtient sur demande et n’offre pas de zones de disponibilité. Un plan de reprise entièrement suisse est faisable, mais il se vérifie au cadrage — pas au moment de le construire.

Impossible à dire sans l’inventaire, et quiconque vous donne un chiffre avant l’audit vous donne un chiffre faux. Ce que nous pouvons dire, c’est où l’écart se creuse : les licences non déclarées machine par machine, les environnements allumés en permanence, la rétention longue des sauvegardes et le trafic sortant.

Nous chiffrons le coût mensuel de la cible pendant l’audit, licences et sauvegardes comprises, et nous le comparons au coût réel de l’existant — renouvellement de matériel et heures d’exploitation inclus. C’est cette comparaison qui décide, pas le prix affiché d’une machine virtuelle.

Alors on ne le migre pas, et on le sait avant d’avoir engagé quoi que ce soit. C’est précisément pour cela que nous écrivons aux éditeurs pendant l’audit et que nous conservons leur réponse : un éditeur qui n’a rien promis refusera d’intervenir après l’incident, et il aura raison.

Dans ce cas, deux voies : garder cette application sur site pendant que le reste part, ou souscrire au sursis des mises à jour étendues le temps que l’éditeur rattrape. Les deux sont défendables ; l’improvisation ne l’est pas.

Cela dépend de ce qui tourne dessus, et le calcul a changé le 1^er avril 2026. Avant cette date, migrer dans Azure donnait accès aux correctifs des versions anciennes sans supplément : c’était un argument financier puissant. Depuis, le prix est le même partout — dans Azure, sur site ou chez un autre fournisseur — pour les nouveaux programmes, dont Windows Server 2016 et SQL Server 2016.

Le point à retenir : la facturation du sursis est rétroactive à la date de fin de support. Souscrire plus tard ne coûte pas moins cher, et Microsoft écrit qu’aucune manipulation ne permet d’y échapper. Attendre n’a donc plus d’intérêt financier : il n’en reste que le risque.

Oui, à une condition : que l’ancien environnement soit encore debout. C’est la raison pour laquelle nous ne l’éteignons jamais avant votre validation écrite, même lorsque la migration s’est bien passée et que la ressource semble immobilisée pour rien.

Ce sont quelques semaines de double exploitation, et c’est le prix d’une décision réversible. Sur notre mandat hospitalier, les serveurs sur site sont restés en ligne pendant toute la campagne d’essais du client et n’ont été éteints qu’après sa validation.

Les deux sont possibles, et c’est vous qui choisissez. Nous pouvons rester en contrat de service, avec du support de niveau 2 et 3, la revue mensuelle de la facture et la gestion des correctifs. Nous pouvons aussi transférer à vos équipes ou à votre prestataire habituel, documentation comprise.

Ce que nous ne faisons pas, c’est construire un environnement que personne d’autre que nous ne sait tenir. Nous ne cherchons pas à rester ; nous cherchons à ce que vos administrateurs sachent tenir la cible après nous.