Avant de commencer
Créez une sauvegarde complète datée et une copie indépendante. Arrêtez les écritures ou utilisez une sauvegarde cohérente avec l’application : copier un dossier actif ne garantit pas la cohérence SQL. Testez la restauration sur une destination isolée. Préservez l’original jusqu’à validation.
Relever édition Windows et conditions de licence
Relevez version, build et édition Windows Server, mode d’activation et de licence, architecture et dépendances applicatives. Une licence fournie par l’hébergeur n’est pas automatiquement transférable. Confirmez la licence de destination avant commande ; ce guide ne change aucune licence et ne transforme aucun média d’évaluation.
Relevez les versions exactes, le démarrage, le stockage réellement utilisé et les dépendances externes. Inventoriez comptes, permissions, tâches planifiées, bases, licences, certificats et services hors du dossier de fichiers. Vérifiez les possibilités d’export chez l’ancien prestataire avant toute résiliation.
- Windows Server version / edition / build
- licensing arrangement
- application requirements
Inventaire en lecture seule
Get-ComputerInfo | Select-Object WindowsProductName,WindowsVersion,OsBuildNumberCette page n’a effectué aucune migration, vérification de sauvegarde ou validation de compatibilité. Conservez la source et une récupération testée. Aucune garantie de zéro interruption, d’IP conservée, de licence transférable ou de restauration sans perte n’est donnée.
Choisir une restauration applicative ou compatible
Une reconstruction applicative propre sépare les données des pilotes et du réseau du prestataire. Une image Windows exige démarrage, pilotes de stockage, hyperviseur et récupération compatibles. Un VHD/VHDX ou snapshot ne démarre pas automatiquement sur tout KVM. Contrôleurs de domaine, clusters et chiffrement lié au TPM nécessitent un plan qualifié distinct.
Créez une sauvegarde complète datée et une copie indépendante. Arrêtez les écritures ou utilisez une sauvegarde cohérente avec l’application : copier un dossier actif ne garantit pas la cohérence SQL. Testez la restauration sur une destination isolée. Préservez l’original jusqu’à validation.
- application migration
- supported image restore
- boot / storage drivers
- AD / cluster / TPM constraints
Inventorier comptes, permissions et tâches
Relevez services et comptes associés, utilisateurs/groupes locaux, ACL NTFS, partages, tâches planifiées et dépendances pare-feu. Copier le contenu des fichiers ne conserve pas nécessairement droits, identités ou secrets applicatifs. Recréez les seuls accès utiles et testez aussi avec un compte ordinaire. Protégez exports de configuration et clés privées.
Préparez une destination compatible avec les logiciels, assez d’espace pour les données restaurées et les archives temporaires, les ports et les permissions nécessaires. Conservez les versions lors de la première restauration ; séparez les mises à niveau. Une quantité identique de RAM ou de vCPU ne prouve pas des performances équivalentes.
- local users / groups / NTFS ACLs
- Windows services
- Task Scheduler
- firewall / shares
Inventaire en lecture seule
Get-Service
Get-ScheduledTaskCette page n’a effectué aucune migration, vérification de sauvegarde ou validation de compatibilité. Conservez la source et une récupération testée. Aucune garantie de zéro interruption, d’IP conservée, de licence transférable ou de restauration sans perte n’est donnée.
Sauvegarder séparément IIS, SQL et certificats
Conservez fichiers des sites, pools applicatifs, bindings, configuration, dépendances .NET et sauvegardes SQL. N’exportez les certificats avec leurs clés privées que si autorisé, dans un stockage protégé, et vérifiez leur restauration. Le dossier d’un site n’est ni la configuration IIS ni une sauvegarde SQL cohérente.
Planifiez un gel des écritures et un export final cohérent. Transférez séparément fichiers et exports SQL lorsque nécessaire. Comparez nombres de fichiers, tailles et sommes de contrôle d’une même archive stable. Une somme identique prouve l’intégrité du transfert, pas la cohérence ni l’exhaustivité des données.
- IIS sites / application pools / bindings
- .NET / SQL Server or other SQL
- certificates + private keys
- application-consistent backup
Valider RDP et les applications en privé
Préparez restrictions d’accès et console de secours avant bascule. Utilisez adresse et port RDP réellement configurés sans règle publique ouverte à tous. Testez connexion applicative, droits NTFS/partages, HTTPS IIS, lectures/écritures SQL, tâches et redémarrage des services. Une somme de contrôle prouve l’identité des octets, pas la cohérence métier.
Testez en privé avant ouverture : journaux de démarrage, authentification, permissions, données représentatives, persistance après redémarrage propre et dépendances externes. Vérifiez certificats et ports TCP/UDP sans exposer publiquement les interfaces d’administration. Consignez les contrôles et les écarts restant à résoudre.
- RDP access policy
- IIS HTTPS
- SQL read + write
- service / task persistence
Inventaire en lecture seule
Get-FileHash -Algorithm SHA256 -LiteralPath 'C:\Backups\archive.zip'Cette page n’a effectué aucune migration, vérification de sauvegarde ou validation de compatibilité. Conservez la source et une récupération testée. Aucune garantie de zéro interruption, d’IP conservée, de licence transférable ou de restauration sans perte n’est donnée.
Basculer avec une décision de récupération
Planifiez exports finaux et gel des écritures, puis mettez à jour DNS et endpoints après validation. Surveillez erreurs, certificats, tâches et accès ; n’exécutez pas le même traitement sur les deux hôtes. Gardez sauvegardes protégées et ancien service jusqu’à acceptation. Réconciliez les données nouvelles avant retour arrière.
Ne basculez l’adresse publiée ou les DNS qu’après les tests privés. Tenez compte des TTL et caches ; un changement de prestataire implique généralement une nouvelle IP. Surveillez erreurs, ressources et nouvelles écritures. Fixez un point de décision de retour arrière : après de nouvelles écritures, il faut réconcilier les données, pas simplement rétablir les DNS.
- final backup
- DNS / endpoints
- avoid duplicate jobs
- recovery decision
Selon votre situation
| Situation | Prochaine vérification |
|---|---|
| Avant la migration | Ne commencez pas la bascule tant qu’une sauvegarde complète n’a pas été restaurée avec succès lors d’un test privé. |
| Pendant le transfert | Une copie à chaud peut manquer des changements simultanés. Préparez une réplication adaptée à l’application et une synchronisation finale avec un administrateur compétent ; aucune migration sans interruption n’est promise. |
| Après la bascule | Conservez l’ancien hébergeur et les sauvegardes originales jusqu’aux contrôles des données, connexions et sauvegardes. Définissez qui autorise la bascule et comment traiter les écritures créées après celle-ci. |
Sources officielles
Ces documents décrivent les protocoles et logiciels concernés. Les conditions de votre service et sa configuration restent à vérifier.