Avant le renouvellement VMware 2027, le serveur dédié mérite-t-il une évaluation ?

Le 22 janvier 2024, Broadcom a annoncé la fin de la disponibilité des licences perpétuelles VMware et de certains services SaaS, selon son annonce officielle sur les modèles de licence. Cette évolution ne signifie pas que la location d’un serveur physique remplace automatiquement une licence ou les fonctions de VMware. Si vos charges sont stables, que votre équipe peut exploiter une autre plateforme et que vous n’avez pas besoin d’une haute disponibilité en cluster, évaluez une solution de virtualisation prise en charge avec un serveur dédié ; sinon, comparez d’abord le renouvellement, la migration et leurs risques réels.

Cette évaluation s’adresse aux responsables techniques qui préparent le budget VMware de 2027 et veulent comparer le coût complet d’un renouvellement avec celui d’une migration. Elle est également utile aux équipes qui gèrent un parc limité de machines virtuelles ou envisagent de déplacer des charges stables hors de leur environnement actuel.

Dernière vérification : 2 novembre 2026, à partir des informations de licence publiées par Broadcom et de la documentation officielle de Proxmox VE. Les discussions de la presse sur les renouvellements signalent un sujet d’actualité, mais ne permettent pas de déduire une hausse générale des tarifs ou une migration inévitable.

Évaluation du renouvellement et de la migration VMware : comparez les coûts complets

Ne comparez pas une facture de licence à un tarif de location isolé. Ce serait mettre en regard deux périmètres différents : la licence ou l’abonnement de virtualisation couvre des droits logiciels et, selon le contrat, des mises à jour ou une assistance ; la location du serveur fournit une infrastructure, pas un remplacement automatique du logiciel, de ses fonctions ni de l’exploitation.

Les modalités exactes dépendent de vos contrats. Broadcom distingue le fonctionnement d’une licence perpétuelle après l’expiration de l’abonnement de support, tandis que l’accès aux mises à jour et à l’assistance est affecté selon les modalités applicables. Vérifiez ces points dans votre documentation contractuelle et dans la note officielle sur les licences perpétuelles après expiration du support. Pour un abonnement, consultez également l’explication Broadcom sur les conséquences de l’expiration de l’abonnement. Ne transposez pas à votre situation une règle générale sans vérifier le produit, le type de licence et les conditions de votre contrat.

Préparez une comparaison sur une période identique. Saisissez les offres que vous avez réellement reçues, les coûts internes estimés et les tarifs vérifiés ; laissez la case vide lorsqu’un montant est encore inconnu, plutôt que de le remplacer par une économie supposée.

Pour rendre le tableau exploitable par la finance, conservez la pièce qui justifie chaque chiffre et notez sa date de vérification. Vous pouvez structurer le calcul selon la méthode de comparaison des coûts sur une même durée. Si le tarif VMware n’est pas encore confirmé, présentez plusieurs scénarios fondés sur des offres ou des hypothèses explicites ; ne publiez pas un « coût moyen » qui ne correspond à aucun devis.

Première étape : mesurer les ressources plutôt que recopier les fiches VM

La somme des ressources déclarées aux machines virtuelles n’est pas toujours une bonne estimation de la capacité nécessaire. Des allocations peuvent être surdimensionnées, tandis qu’une charge de pointe, une croissance de base de données ou une consolidation plus forte peut au contraire rendre la nouvelle machine insuffisante. Le taux de consolidation, l’usage réel de la mémoire, les entrées-sorties et les pointes réseau doivent être observés ensemble.

Avant de choisir une cible, relevez les tendances sur une période représentative de votre activité, y compris les traitements périodiques. Dans l’interface de gestion VMware, exportez les mesures disponibles pour les processeurs virtuels, la mémoire active, les volumes et le réseau. Complétez-les par l’inventaire des systèmes invités, des tâches planifiées et des fenêtres de sauvegarde. Une mesure ponctuelle prise pendant une période calme ne suffit pas à dimensionner un serveur destiné à fonctionner en continu.

Vous pouvez également recueillir des observations depuis les systèmes invités Linux :

lscpu
free -h
df -h
iostat -xz

Ces commandes donnent des informations locales sur le processeur, la mémoire, l’espace disque et l’activité des disques ; elles ne remplacent pas les données de l’hyperviseur. Interprétez les résultats en tenant compte de la durée d’observation et du rôle de chaque machine virtuelle. Un stockage presque plein, par exemple, peut signaler un besoin de capacité, mais aussi une rétention de journaux ou de sauvegardes à corriger.

Pour le dimensionnement, rapprochez les besoins mesurés des options effectivement proposées par votre fournisseur et de leurs limites de stockage et de mémoire. N’inférez pas la capacité utile à partir d’un nom de modèle ou d’une fiche commerciale seule. La comparaison doit aussi préciser si vous prévoyez une séparation des charges, une réserve pour les pointes et une capacité de croissance. Le guide sur la planification de la mémoire et du stockage peut aider à structurer cette vérification, mais il ne remplace pas l’inventaire de votre parc.

Compatibilité : vérifiez la plateforme et les dépendances, pas seulement l’installation

Proxmox VE peut être étudié comme plateforme candidate, mais sa possibilité d’installation ne prouve ni l’équivalence avec VMware ni la compatibilité de votre environnement. La documentation d’administration de Proxmox VE décrit les exigences et les fonctions du produit ; la documentation doit être recoupée avec votre matériel, vos intégrations et les procédures dont vous dépendez. Une version documentaire plus ancienne est également disponible dans le guide officiel de Proxmox VE 8.

Établissez une liste des dépendances à vérifier avant tout changement :

• fonctions d’hyperviseur effectivement utilisées, dont le déplacement de machines virtuelles ou les mécanismes de reprise ;
• outils de sauvegarde, restauration granulaire, conservation et vérification de l’intégrité ;
• réseaux virtuels, segmentation, règles de filtrage, interfaces et dépendances à des équipements externes ;
• scripts d’automatisation, supervision, collecte de journaux et intégrations d’authentification ;
• systèmes invités, pilotes, licences applicatives et contraintes des éditeurs.

Classez chaque élément en « testé », « confirmé par la documentation » ou « à valider auprès du fournisseur concerné ». Les fonctions présentes dans deux produits ne fonctionnent pas forcément de la même façon, et la conversion d’un disque virtuel ne transfère pas à elle seule les politiques réseau, les tâches de sauvegarde ou les règles d’exploitation. Pour les services dont l’arrêt aurait un impact important, réalisez un essai isolé avant de décider du calendrier de migration.

Ne confondez pas non plus les rôles des intervenants. Le fait qu’un serveur physique soit disponible ne signifie pas que le fournisseur de serveur installe ou prend en charge VMware, Proxmox VE, vos sauvegardes ou une architecture en cluster. Vérifiez les prestations réellement incluses et les opérations qui restent à votre équipe. Établissez cette répartition dans une procédure interne avant la mise en production, en nommant les personnes responsables de chaque tâche.

Questions fréquentes avant de décider

Faut-il migrer la plateforme avant de renouveler VMware ?

Pas sans avoir vérifié les fonctions utilisées et les droits de licence liés à votre contrat. Un renouvellement peut être préférable si l’environnement dépend d’intégrations difficiles à remplacer ou si l’équipe n’a pas encore de procédure d’exploitation alternative. À l’inverse, un essai limité peut justifier une migration progressive lorsque les charges sont stables et que les dépendances ont été validées.

Une petite équipe doit-elle louer un serveur dédié après VMware ?

La location est une option d’infrastructure, pas une obligation liée au changement d’hyperviseur. Elle peut convenir à des charges régulières si la capacité, la sauvegarde et les responsabilités sont maîtrisées. Certaines applications peuvent rester dans le cloud, tandis que d’autres sont déplacées. Prenez en compte l’effort de maintenance que l’équipe peut réellement assurer, et pas seulement le nombre de machines virtuelles.

Comment éviter une comparaison trompeuse des coûts ?

Utilisez le même périmètre et la même période pour chaque scénario. Ajoutez aux tarifs les tâches d’exploitation, les licences applicatives éventuellement concernées, les essais, la migration, les sauvegardes et le réseau. Distinguez les montants issus d’un devis, ceux tirés d’une facture et les estimations internes. Si une source ou une hypothèse manque, signalez-la plutôt que de présenter un total comme certain.

Une machine unique remplace-t-elle les fonctions d’un cluster ?

Une machine unique ne fournit pas, à elle seule, la tolérance aux pannes d’un cluster. Si elle tombe en panne, les machines virtuelles qu’elle héberge peuvent devenir indisponibles. La sauvegarde permet de restaurer des données ou des systèmes selon votre procédure, mais n’équivaut pas à un basculement automatique. Si votre exigence impose la continuité du service pendant une panne, conservez une architecture qui répond explicitement à cette exigence.

Exploitation : mesurez la charge que votre équipe devra reprendre

Une plateforme autogérée n’est pas gratuite au seul motif que son logiciel est disponible sans achat de licence. Vous devez attribuer le temps consacré aux correctifs, aux alertes, aux mises à niveau, à la capacité, aux comptes d’administration et au diagnostic des incidents. Ajoutez la formation nécessaire si les procédures actuelles reposent sur des outils ou des compétences propres à VMware.

Avant d’engager une migration, nommez un responsable principal et un remplaçant pour les tâches courantes. Documentez qui vérifie les mises à jour, qui traite une alerte de stockage, qui autorise un changement réseau et qui décide de revenir à l’ancienne plateforme en cas d’échec. Une équipe restreinte peut réussir une migration, mais elle doit pouvoir assurer la continuité des tâches pendant les congés, les incidents et les périodes de forte activité.

Évaluez aussi votre dépendance à l’assistance externe. Si une procédure essentielle ne peut être menée qu’avec un intervenant dont la disponibilité ou le contrat n’est pas établi, cette dépendance appartient au coût et au risque du scénario. À l’inverse, ne valorisez pas comme « assistance incluse » une prestation qui n’apparaît pas dans les conditions de service. La distinction entre logiciel, infrastructure louée et exploitation reste importante, même lorsque ces éléments sont achetés auprès du même fournisseur.

Récupération : distinguez sauvegarde et haute disponibilité

Une machine dédiée n’est pas automatiquement un cluster, et un système RAID ne remplace pas une sauvegarde. Évaluez séparément la panne d’un disque, la panne de l’hôte, une suppression accidentelle et une mise à jour défectueuse. Pour chacun de ces cas, identifiez les données disponibles, le matériel ou l’environnement de remplacement, la personne autorisée à intervenir et les étapes nécessaires pour restaurer le service.

Gardez les sauvegardes indépendantes de l’hôte de production et vérifiez que vous pouvez restaurer les systèmes, leurs configurations et leurs données. Un rapport indiquant qu’une tâche s’est terminée n’est pas une preuve de restauration : planifiez des essais de récupération, consignez les résultats et corrigez les procédures qui ne permettent pas d’atteindre vos objectifs métier. Si vous n’avez ni capacité de restauration vérifiée ni solution de remplacement en cas de panne de l’hôte, ne présentez pas une machine unique comme une architecture hautement disponible.

Une migration crée aussi un risque temporaire : durant la coexistence des plateformes, vous pouvez avoir des copies de données, des responsabilités partagées et des configurations qui ne sont pas synchronisées. Définissez à l’avance la source de vérité, les critères de validation et la condition de retour arrière. Si ces critères ne sont pas vérifiables, réduisez le périmètre du test au lieu de déplacer une application critique.

Conditions de choix : renouveler, migrer progressivement ou différer

Choisissez la branche correspondant à votre situation ; si un critère essentiel reste inconnu, revenez à l’étape de vérification plutôt que de traiter une hypothèse comme une décision acquise.

• Renouvelez si les fonctions VMware utilisées sont difficiles à remplacer, si les licences et le support sont compris dans l’offre reçue et si votre équipe ne peut pas encore prendre en charge une autre plateforme sans fragiliser l’exploitation.
• Migrez progressivement si la charge est stable, si les ressources ont été mesurées, si les dépendances ont été testées et si une équipe identifiée sait maintenir la plateforme cible. Commencez par une charge non critique avec des critères d’acceptation et de retour arrière documentés.
• Différez la migration si vous ne connaissez pas encore le coût contractuel, si les sauvegardes n’ont pas été restaurées à titre d’essai ou si les applications exigent des fonctions de cluster que votre architecture envisagée ne fournit pas.
• Ne remplacez pas un cluster par une seule machine lorsque l’indisponibilité d’un hôte est incompatible avec les exigences de service. Évaluez plutôt une architecture redondante ou maintenez le scénario actuel jusqu’à ce qu’une solution de reprise vérifiable soit définie.

Enfin, séparez les coûts d’infrastructure des coûts de virtualisation dans votre note budgétaire. Un serveur loué peut héberger une plateforme compatible, mais il ne transforme pas cette plateforme en produit fourni ou pris en charge par le loueur. OSFP Cloud peut être examiné pour des charges stables qui correspondent à ses options réelles ; vérifiez les systèmes, configurations et modalités de paiement disponibles dans les informations de OSFP Cloud avant de chiffrer votre scénario. Les tarifs et capacités doivent être relevés à la date où vous préparez votre budget, et non extrapolés à partir d’une offre non vérifiée.

Si votre solution actuelle repose sur des instances partagées ou une facturation cloud par ressource, vous pouvez aussi avoir à gérer une performance variable, des postes de facture séparés ou des limites de personnalisation. Ces inconvénients ne suffisent pas à justifier une migration à eux seuls : une machine dédiée vous transfère aussi davantage de responsabilités de capacité, de maintenance et de reprise. En revanche, pour une charge durable dont vous pouvez assumer l’exploitation, comparer cette option à votre renouvellement VMware est raisonnable. Consultez les configurations et conditions effectivement proposées par OSFP Cloud, puis ne retenez le serveur dédié que si la plateforme choisie, le budget complet et le plan de récupération répondent à vos exigences.

Questions

Faut-il changer de plateforme avant de renouveler VMware ?

Pas sur la seule base du montant du renouvellement. Vérifiez d’abord vos droits de licence, les fonctions réellement utilisées, les dépendances de sauvegarde et de réseau, puis la capacité de votre équipe à exploiter une autre plateforme. Si ces éléments restent inconnus, documentez-les et testez une charge non critique avant de modifier votre contrat ou de planifier une migration générale.

Après une migration depuis VMware, une petite équipe doit-elle encore louer un serveur dédié ?

La location d’un serveur dédié peut convenir si la charge est régulière, si une machine physique répond aux besoins mesurés et si l’équipe sait administrer l’hyperviseur, le stockage et les sauvegardes. Elle n’est pas obligatoire : certains services peuvent rester dans le cloud. Comparez le coût d’exploitation et les responsabilités, pas seulement le prix du matériel.

Comment comparer le coût d’un renouvellement VMware à celui d’une migration ?

Mettez les deux scénarios sur une même période et ajoutez les postes qui disparaissent souvent du premier calcul : plateforme, matériel ou location, stockage, sauvegarde, réseau, migration, formation et temps d’exploitation. Pour chaque montant, notez son origine et sa date de vérification. Sans offre de renouvellement et tarifs confirmés, n’inscrivez ni économie estimée ni pourcentage de réduction.

Une seule machine dédiée peut-elle remplacer un cluster VMware ?

Non, pas à elle seule lorsque le service dépend de la haute disponibilité du cluster. Une machine unique reste un point de défaillance, même si elle héberge plusieurs machines virtuelles. Il faut établir ce qui se passe lors d’une panne, prévoir des sauvegardes indépendantes et tester la restauration. Si l’interruption n’est pas acceptable, conservez une architecture redondante adaptée à cette exigence.