Comment migrer et transférer SQL Server d’un Windows Server à un autre, y compris Server 2003, Server 2008, Server 2012

Dans ce tutoriel, nous allons apprendre comment copier ou déplacer un SQL Server d’un serveur à un autre. Contrairement aux options de migration manuelle, nous effectuerons la migration automatiquement, et transférerons non seulement le serveur SQL lui-même, mais aussi toutes les configurations, schémas, bases de données – et les applications proprement dites que le serveur exécute (et que vous devez exécuter sur le nouveau serveur).

Ce tutoriel fonctionne pour Server 2003, Server 2008, Server 2012, Server 2016 et même Server 2019. Le transfert peut être de physique à physique (P2P), de physique à virtuel (P2V), de virtuel à virtuel (V2V), ainsi que vers des serveurs Cloud.

L’objectif de ce tutoriel est de copier les applications du serveur vers le nouveau serveur de manière complète et générique : toute application, même les applications personnalisées ou internes, sera déplacée vers le nouveau serveur, y compris ses configurations, ses bases de données et bien sûr ses fichiers.

Notez que le transfert que nous effectuons est un transfert natif. Les applications sont réellement transférées vers le nouveau serveur, s’y installant, et conservant leurs configurations. Cela ne repose sur aucun processus de conteneurisation ou de virtualisation des applications, et offre une véritable migration native.

Le tutoriel se trouve ci-dessous, et avant cela – un tutoriel vidéo et quelques questions courantes sur la migration de Windows Server.

Tutoriel vidéo – Migration de SQL Server, y compris les applications

Comment effectuer la migration d’un serveur SQL vers un nouveau serveur Windows

Avant la migration

Auditez vos serveurs : Assurez-vous de savoir ce dont le serveur est responsable et quelles sont les applications qui y sont exécutées. Assurez-vous de savoir comment vérifier qu’une application a bien été transférée avec succès vers un serveur de remplacement, et que les utilisateurs peuvent travailler avec comme auparavant.

Conseil : Si votre organisation n’utilise pas d’outil de gestion centralisée (par exemple Microsoft SCCM) pour surveiller vos serveurs, vous pouvez télécharger gratuitement Microsoft Assessment and Planning (MAP) Toolkit ici. Vous pouvez également utiliser le diagnostic de serveur gratuit de Zinstall en cliquant sur ce lien.

Planifiez votre créneau de migration : Les migrations prennent du temps, et pendant ce temps, vos utilisateurs peuvent être affectés dans une certaine mesure. Essayez si possible de programmer la migration proprement dite en dehors des heures de bureau ou pendant un week-end. Notez que vous n’êtes pas obligé de rester sur place à ce moment-là : la migration des applications peut être effectuée à distance ou lancée à l’avance en mode sans surveillance.
Vérifiez que vos sauvegardes sont à jour et qu’elles sont effectivement restaurables : Toute mise à niveau importante peut mal tourner et sans une sauvegarde valide et à jour, vous risquez de perdre tout ce que vous aviez sur le serveur. Assurez-vous que la sauvegarde que vous avez n’est pas endommagée et qu’elle est prête à être restaurée si nécessaire !
Décidez du type de remplacement : Une fois que vous avez décidé de remplacer un serveur, vous avez plusieurs options concernant le type de remplacement. Il peut s’agir d’un serveur physique Windows 2012 ou 2016, d’un serveur virtuel fonctionnant sur site, ou même d’un serveur basé sur le Cloud fonctionnant hors site. WinServ prend en charge tous ces transferts, de sorte que la difficulté de migration ne varie pas de manière significative en fonction de votre choix.

Migration d’applications, de profils, de partages et de données

Voici la procédure à suivre pour effectuer une migration d’un serveur Windows vers un autre :

Mettez à jour et réparez complètement le serveur cible.
Ajoutez le serveur cible au domaine.
Lancez WinServ sur le serveur source et sur le serveur cible.
À ce stade, vous pouvez soit transférer directement sur le réseau, soit effectuer une migration indirecte – en capturant le serveur source dans un conteneur sur un stockage réseau / stockage sur le Cloud, puis en déployant à partir de ce conteneur sur le nouveau serveur.
Avant de commencer le transfert, vous avez également la possibilité de choisir les applications et les données que vous souhaitez transférer. Ou bien, vous pouvez simplement lancer le transfert pour tout migrer.
Appuyez sur “Go” sur le serveur cible afin de démarrer le transfert.

Selon la quantité de données et d’applications transférées, le transfert proprement dit peut prendre plusieurs heures. Vous verrez une indication de la progression tout au long du processus.

Gérer les applications incompatibles

Certaines vieilles applications tierces fonctionnant sur Windows Server 2003 peuvent être incompatibles avec Windows Server 2008 ou Windows Server 2012. Ces applications sont généralement d’anciens logiciels DOS, 16-bit ou 32-bit uniquement, qui n’ont pas été mis à jour pour les nouvelles versions du système d’exploitation. Il est fortement recommandé d’éliminer ces applications de l’environnement de production dès que possible.

Si ces applications ne peuvent pas être éliminées immédiatement et qu’elles sont essentielles à la poursuite des activités de l’organisation, l’option recommandée pour préserver leur fonctionnement est d’effectuer une migration virtualisée de ces applications, vers une instance virtuelle de Server 2003 fonctionnant sur un serveur de remplacement plus récent. Continuez ensuite à prendre les mesures nécessaires pour retirer progressivement ces applications et arrêter d’exécuter les instances 2003 virtualisées.

Une telle migration P2V (physique vers virtuel) peut également être effectuée à l’aide de WinServ.

Après la migration

Une fois le processus de migration terminé, il est temps de vérifier les résultats.

Il se peut que vous deviez ajuster le DNS de votre domaine pour qu’il soit orienté vers le nouveau serveur si nécessaire. Par exemple, en changeant l’entrée DNS CRM-SERVER par l’adresse du nouveau serveur.
Il en va de même pour les scripts de connexion et la stratégie de groupe (GPO policy).
Lancez chaque application et console que vous utilisez, et vérifiez qu’elles se chargent correctement.
En utilisant un poste de travail client, vérifiez que les clients peuvent accéder correctement au serveur migré et que leurs applications s’exécutent sans problème.

Félicitations ! La migration de votre serveur SQL est maintenant terminée.