Vous remplacez un serveur et voulez réutiliser vos logiciels et licences sans risque d’audit ? Ce guide opérationnel, centré sur Windows Server/SQL Server et la virtualisation, détaille les droits de transfert, la procédure pas‑à‑pas, les pièges à éviter et des modèles prêts à l’emploi.
Vue d’ensemble de la question
Un administrateur remplace un serveur ancien par un nouveau et souhaite transférer les logiciels existants – ainsi que leurs licences – vers ce nouveau matériel. La faisabilité dépend d’abord des conditions contractuelles : certaines licences sont liées à l’appareil d’origine (OEM), d’autres sont transférables (Retail/FPP, Volume) sous conditions (désinstallation, réassignation, limite temporelle). À cela s’ajoutent les contraintes techniques (changement d’OS, de CPU, virtualisation, cluster, cores vs sockets) et opérationnelles (fenêtre de bascule, continuité de service, preuves pour un audit).
Réponse et solution
| Point clé | Explications et bonnes pratiques |
|---|---|
| Vérifier le contrat de licence | Les droits de transfert figurent toujours dans l’accord de licence (EULA, contrat de volume, Software Assurance, OEM, etc.). Recherchez spécifiquement les sections « Device‑based », « User‑based », « Transferability » ou « Reassignment ». |
| Identifier le type de licence | • OEM / licence liée au matériel : en général non transférable (elle disparaît avec l’ancien serveur). • Licence Retail (FPP) ou Volume (Open, Select, EA) : souvent transférable à condition de désinstaller/désactiver sur l’ancien serveur. • Licence par utilisateur / CAL ou SaaS : transférable tant que le nombre d’utilisateurs/accès reste identique. |
| Désactiver ou désinstaller sur l’ancien serveur | Si le contrat exige qu’une seule instance soit active, désactivez la clé (ou exécutez l’assistant de désactivation, selon l’éditeur) avant d’installer sur le nouveau serveur. Gardez un log ou une capture d’écran comme preuve en cas d’audit. |
| Contacter l’éditeur si nécessaire | Certains éditeurs demandent un re‑hosting (nouvelle clé, changement d’empreinte matérielle) ou un formulaire de cession. Préparez les N° de série, ID client, détails du nouveau serveur (CPU, carte mère, VM vs physique). |
| Documenter le transfert | Mettez à jour l’inventaire logiciel, conservez le mail d’approbation ou le ticket d’assistance, et archivez l’ancienne clé/licence comme preuve de conformité. |
| Risques à anticiper | • Audit éditeur : démontrez la désinstallation. • Incompatibilités techniques (nouvel OS, virtualisation). • Période de chevauchement : certains contrats autorisent X jours pour migrer ; sinon, planifiez un basculement rapide. |
Arbre de décision rapide
- La licence est‑elle OEM ? → Probablement non transférable. Envisager une nouvelle licence ou une licence Volume.
- La licence est‑elle Retail/Volume ? → Transférable si l’ancienne instance est supprimée et si la réaffectation respecte l’éventuelle période minimale.
- La licence est‑elle nominative (utilisateur/CAL/SaaS) ? → Transférez l’accès à l’utilisateur cible et maintenez le même périmètre d’usage.
- Le nouveau serveur est‑il virtualisé ou en cluster ? → Vérifiez la métrique de licence (cœurs, sockets, hôtes vs vCPU) et les droits spécifiques (mobilité, failover).
Procédure pas‑à‑pas recommandée
Préparation
- Rassembler les preuves d’achat : factures, contrats, clés, portails d’activation.
- Identifier la métrique de licence (par appareil, par utilisateur, par cœur, par socket, par VM).
- Contrôler la compatibilité : version de l’OS, dépendances (frameworks, runtimes), support en VM.
- Planifier la fenêtre de migration et définir si un chevauchement temporaire est autorisé par le contrat.
- Prévoir un plan de retour arrière (snapshot, sauvegarde complète, script d’installation) en cas d’échec.
Désactivation sur l’ancien serveur
- Exécuter l’outil de désactivation fourni par l’éditeur (ou l’uninstall key si applicable).
- Capturer des preuves : sorties de commandes, captures d’écran, journaux d’événements.
- Mettre à jour l’inventaire SCCM/Intune/GLPI ou équivalent pour marquer l’application comme retirée.
Installation sur le nouveau serveur
- Installer l’OS et les prérequis (patches, .NET, bibliothèques).
- Installer l’application et renseigner la clé ou l’ID de licence.
- Si nécessaire, demander un re‑hosting pour régénérer la licence liée à l’empreinte matérielle.
Activation et contrôle
- Activer en ligne ou hors ligne selon la politique de l’éditeur.
- Valider que une seule instance est active (ancien serveur arrêté ou application désinstallée).
- Exécuter des tests fonctionnels et de performance sur le nouveau serveur.
Documentation et conformité
- Archiver le dossier de transfert : demandes au support, numéro de cas, captures, inventaire.
- Mettre à jour la CMDB et le registre de licences (asset tag du nouveau serveur, numéro de série, VMID).
- Rédiger une attestation interne de désinstallation et de réaffectation signée par l’IT.
Tableau de synthèse par type de licence
| Type de licence | Transférabilité habituelle | Action requise | Points d’attention |
|---|---|---|---|
| OEM liée au matériel | Faible / non | Acquérir une nouvelle licence pour le nouveau serveur | La licence suit le serveur d’origine ; l’activation sur nouveau matériel est refusée dans la plupart des cas. |
| Retail (FPP) | Bonne | Désinstaller sur l’ancien, activer sur le nouveau | Conserver la preuve de désinstallation ; attention aux limites de nombre d’activations. |
| Volume (Open/Select/EA) | Très bonne | Réaffectation selon les règles du contrat | Souvent une période minimale entre deux réaffectations ; vérifier la métrique (core/socket/VM). |
| Utilisateur/CAL | Bonne | Réassigner l’utilisateur ou le dispositif | Le nombre de connexions simultanées et l’usage serveur peuvent rester limités par le contrat. |
| Abonnement/SaaS | Élevée | Mettre à jour l’appareil ou l’utilisateur associé | Penser aux modules ou add‑ons dont la facturation varie par ressource. |
| Licence liée à l’empreinte matérielle | Moyenne | Demander un re‑hosting à l’éditeur | Préparer les IDs matériels : UUID, carte mère, CPU, VMID/hyperviseur. |
Informations complémentaires utiles
Windows Server et SQL Server
- Les licences OEM sont généralement figées au matériel.
- Une licence Volume ou Retail permet la réaffectation (souvent avec une règle de délai de réassignation). Vérifiez vos termes précis.
- Avec Software Assurance, vous pouvez bénéficier de droits tels que la License Mobility (mobilité entre hôtes/VM) et des droits de failover pour un nœud passif en cluster.
- SQL Server est typiquement licencié par cœurs (physiques ou vCPU selon le mode), avec exigences minimales par serveur/VM.
Virtualisation
- Transférer une VM exige de respecter la même métrique sur l’hôte cible (même nombre de cœurs/vCPU licenciés au minimum).
- Certains éditeurs lient la licence au socket physique, d’autres comptent les vCPU ; ajustez la configuration de la VM si besoin pour rester conforme.
- En cluster, distinguez les droits de nœud passif (sans licence supplémentaire chez certains éditeurs) des nœuds actifs.
Sauvegarde et continuité
- Avant tout transfert, vérifiez que la clé d’activation et la méthode d’activation hors ligne sont disponibles.
- Testez l’application sur le nouveau serveur en environnement isolé (réseau privé, base de test) pour éviter une indisponibilité prolongée.
- Prévoyez un plan de bascule : réplication de données, dernière sauvegarde juste avant le changement de DNS/IP, validation par les utilisateurs.
Exemples de scénarios de migration
Physique vers physique
Ordinateurs dédiés de génération différente. Anticipez les changements de pilotes et d’architecture CPU. Les licences OEM resteront bloquées sur l’ancien serveur ; privilégiez des licences Volume pour le nouveau.
Physique vers virtuel (P2V)
Idéal pour moderniser tout en gardant une image logique identique. Vérifiez la compatibilité de l’application en VM, la prise en charge des horloges virtuelles et la métrique de licence (vCPU/cœurs alloués).
Virtuel vers virtuel (V2V) ou changement d’hyperviseur
Les empreintes matérielles changent ; il faut parfois un re‑hosting de la licence. Documentez l’ID de l’ancienne VM, la nouvelle VM, l’hôte source et l’hôte cible, ainsi que la date de bascule.
Migration avec période de chevauchement
Dans certains contrats, une période courte permet d’exécuter temporairement l’application sur les deux serveurs (tests et bascule). Si non prévu, limitez le chevauchement à une fenêtre de maintenance unique et consignez précisément les horodatages.
Check‑list de conformité prête à l’emploi
- 🔎 Contrat relu : transfert autorisé, métrique confirmée, éventuelle période minimale respectée.
- 🧾 Preuves d’achat et numéros de série regroupés.
- 🧰 Outils de désactivation/activation testés en amont.
- 🗂️ Inventaire et CMDB à jour (ancien ↔ nouveau serveur).
- 📸 Captures et exports des commandes clés conservés.
- 🧪 Tests fonctionnels validés sur le nouveau serveur.
- 📝 Attestation interne signée et dossier de transfert archivé.
Commandes et traces utiles côté Windows
Exécutez ces commandes en session administrateur et conservez les sorties dans votre dossier de transfert.
REM Afficher les informations de licence Windows
slmgr /dlv
REM Désinstaller la clé produit Windows (si requis par votre contrat)
slmgr /upk
REM Effacer la clé du registre (bonne pratique avant cession/recyclage)
slmgr /cpky
REM Afficher l’UUID matériel (utile pour les dossiers de preuve)
wmic csproduct get uuid Pour des produits Microsoft Office côté serveur (si présents) :
REM Vérifier l’état de licence Office
cscript "%ProgramFiles%\Microsoft Office\Office16\OSPP.VBS" /dstatus
Astuce : exportez les sorties vers des fichiers horodatés pour archivage :
slmgr /dlv > C:\Temp\pre-migration-slmgr-dlv.txt
wmic csproduct get uuid > C:\Temp\pre-migration-uuid.txt
Modèles prêts à copier
Demande de re‑hosting au support éditeur
Objet : Demande de re-hosting de licence <Produit>
Bonjour,
Nous remplaçons notre serveur par un nouveau matériel/VM.
Merci de régénérer/autoriser l’activation de la licence suivante :
* Produit :
* N° de série / clé :
* Client/Contrat :
* Ancien serveur :
* Nouveau serveur :
* Date de bascule prévue :
Nous attestons que l’ancienne instance sera désinstallée/neutralisée après la validation.
Cordialement,
Attestation interne de désinstallation
Attestation de réaffectation de licence
Je soussigné(e) , atteste avoir désinstallé/désactivé le logiciel
sur le serveur le .
Les preuves (captures/exports) sont archivées dans .
Signature : __________________________ Pièges fréquents et comment les éviter
- Confondre OEM et Retail/Volume : vérifiez la source d’achat. Une image d’usine ou un sticker COA est souvent synonyme d’OEM.
- Oublier la métrique exacte : passer d’un serveur 8 cœurs à une VM 4 vCPU peut sembler économique mais être non conforme si la licence exige de couvrir tous les cœurs de l’hôte.
- Chevauchement prolongé : sans droit explicite, deux instances actives exposent à un redressement en audit. Réduisez la fenêtre ou demandez une autorisation écrite.
- Changements d’hyperviseur : migration de VMware à Hyper‑V ou Proxmox : l’empreinte change, un re‑hosting peut être requis.
- Oublier de documenter : sans preuves, même un transfert conforme peut paraître litigieux. Automatisez les exports et les captures.
Bonnes pratiques d’inventaire et de gouvernance
- Maintenir un registre centralisé des clés, contrats, et attributions par serveur/VM.
- Mettre en place des étiquettes (tags) sur les VM : rôle, licence, dernière réaffectation, contrat.
- Automatiser l’audit technique : scripts de collecte (version, clé masquée, activation) exécutés périodiquement.
- Synchroniser l’inventaire CMDB avec l’outil de SAM (Software Asset Management) pour une visibilité temps réel.
- Former les équipes au cycle de vie des licences : acquisition → inventaire → utilisation → transfert → retraite.
Plan type de bascule avec risque minimal
- Construire la VM/le serveur cible et installer l’application en mode essai ou sans production.
- Réplication ou restauration de la base de données et des fichiers sur l’environnement cible.
- Tests fonctionnels complets avec un échantillon d’utilisateurs.
- Gel des changements sur l’ancien serveur, sauvegarde finale et désactivation de la licence.
- Activation sur le nouveau serveur, bascule DNS/IP, validation via un jeu de tests.
- Surveillance post‑bascule, fermeture du ticket et archivage des preuves.
FAQ rapide
Peut‑on réutiliser une licence serveur OEM ? Souvent non ; elle reste liée au matériel d’origine.
Une licence Retail/Volume peut‑elle être déplacée plusieurs fois ? Oui, si vous respectez les conditions (désinstallation, délai éventuel de réaffectation, même périmètre d’usage).
Faut‑il une licence supplémentaire pour un nœud de secours en cluster ? Parfois non avec des droits spécifiques de failover, parfois oui ; vérifiez votre contrat.
La virtualisation simplifie‑t‑elle la conformité ? Elle la rend plus flexible, mais pas plus simple : tenez compte des cœurs physiques de l’hôte, des vCPU et des mouvements de VM.
Résumé exécutable
La réutilisation de votre logiciel sur un nouveau serveur est possible si le contrat l’autorise et si vous suivez une méthode stricte : lecture attentive des termes, désactivation sur l’ancien, activation contrôlée sur le nouveau, traçabilité complète. Préparez vos preuves, automatisez les captures et sécurisez la fenêtre de bascule ; vous serez à la fois conforme et efficace.
Annexe : modèle de registre de transfert
| Produit | Version | Type de licence | Clé/ID (masqué) | Serveur source | Serveur cible | Date/heure désactivation | Date/heure activation | Preuves stockées | Référence ticket |
|---|---|---|---|---|---|---|---|---|---|
| Ex : Windows Server | 2022 | Volume + SA | XXXXX‑XXXXX‑XXXXX‑XXXXX | SRV‑OLD‑01 | SRV‑NEW‑01 | 2025‑10‑10 22:15 | 2025‑10‑10 22:35 | \\share\projets\migration\preuves | INC‑2025‑001234 |
Avertissement
Ce contenu est informatif et ne remplace pas un avis juridique. Les conditions varient selon l’éditeur, la version et le pays. Relisez toujours vos accords de licence et conservez une trace écrite des autorisations spécifiques obtenues auprès des éditeurs.