Migration maîtrisée Windows Server 2012 R2/2019 → 2022 et SQL Server 2014 SP3 → 2022 avec SCCM : ordre, risques, checklists et scripts

Vous préparez une montée de version combinant Windows Server, SQL Server et SCCM ? Voici un guide terrain, structuré et opérationnel, pour décider de l’ordre, réduire les risques et dérouler la migration sans mauvaise surprise.

Sommaire

Contexte et objectif

L’administrateur souhaite enchaîner plusieurs opérations majeures : sauvegarder, mettre à jour SQL Server 2014 RTM vers SQL Server 2014 SP3, migrer l’OS de Windows Server 2012 R2 vers Windows Server 2019 Datacenter, mettre à jour les rôles/fichiers et SCCM, basculer SQL Server 2014 SP3 vers SQL Server 2022 Enterprise, passer l’OS en Windows Server 2022 Datacenter, réactualiser les rôles/SCCM et installer les dernières versions de SSMS/SSDT. L’auteur s’interroge sur la pertinence de cet enchaînement, les risques et les points d’attention.

Ce que l’échange initial ne fournissait pas

La discussion d’origine n’apportait pas de réponse technique concrète ; l’auteur a été redirigé vers un forum spécialisé. Vous trouverez ci‑dessous un plan d’action complet, des checklists, des scripts et des recommandations pratico‑pratiques pour mener la migration à bien.

Résumé exécutif de l’ordonnancement conseillé

Sauvegardes + tests de restauration → Passage SQL 2014 en SP3 → Option privilégiée : migration side‑by‑side vers de nouveaux serveurs Windows Server 2022 (installation propre) avec SQL Server 2022 → Mise à jour SSMS/SSDT → Mise à niveau de SCCM/roles → Validation → Décommissionnement des anciens serveurs.

Cette approche minimise l’indisponibilité, simplifie le rollback et s’aligne sur les chemins d’upgrade supportés. Si les contraintes imposent un in‑place, l’ordre reste : SQL 2014 → SP3, puis OS (2012 R2 → 2019 → 2022), puis SQL 2022, en prévoyant une fenêtre de maintenance plus longue.

Tableau de recommandations clés

Étape	Recommandations pratiques	Pourquoi ?
0. Sauvegardes + tests	Effectuez des sauvegardes complètes (fichiers OS critiques, bases, master/msdb, clés TDE) et un restore test isolé.	Valider le retour arrière réel, pas seulement théorique.
1. Patch SQL 2014 → SP3	Mettre à jour en SP3 avant toute montée vers 2022. Stopper/ordonner les jobs SQL Agent durant l’opération.	Chemin d’upgrade supporté vers 2022 à partir de 2014 SP3.
2. OS : stratégie	Préférer side‑by‑side sur serveurs Windows Server 2022 neufs. À défaut, procéder en in‑place 2012 R2→2019→2022, en mettant à jour drivers/antivirus.	Réduire le risque, accélérer le rollback, environnement propre.
3. SSMS/SSDT	Installer la dernière version dès que possible, indépendante du moteur.	Fonctionnalités récentes (meilleurs outils, T‑SQL moderne, prise en charge 2022).
4. SQL 2014 SP3 → SQL 2022	Upgrade direct supporté. Après migration, vérifier la compatibilité (niveau 120 → 160) et lever progressivement.	Conserver logins, jobs, opérateurs, et bénéfices du nouvel optimiseur.
5. Active Directory	Si DC impliqué, mettre à niveau le schéma AD avant d’introduire WS 2022 DC. Sauvegarde de l’état du système.	Éviter les incohérences de réplication/compatibilité.
6. SCCM	Valider la prise en charge de SQL 2022 + WS 2022 par votre version de Configuration Manager. Ajuster la compatibilité DB si requis.	SCCM impose des prérequis précis de version et de niveau de compatibilité.

Side‑by‑side ou in‑place : comment choisir ?

Critère	Side‑by‑side (recommandé)	In‑place (toléré)
Risque	Faible : environnement neuf, rollback simple.	Plus élevé : empilement d’historiques, drivers, dépendances.
Downtime	Minimisé : bascule orchestrée (log shipping/AG/backup‑restore final).	Élevé : redémarrages multiples OS + setup SQL.
Performance post‑migration	Propre ; alignement drivers/firmware et CU récents.	Potentiels artefacts (anciens drivers/services résiduels).
Effort initial	Plus de préparation (nouveaux serveurs, script de migration).	Moins de préparation mais plus de risques.
Rollback	Instantané : revenir à l’ancien serveur.	Complexe : restauration images/snapshots, allongement downtime.

Pré‑requis et contrôles avant migration

Gel des changements : freeze de déploiements applicatifs et de modifications de schéma 2 semaines avant bascule.
Capacité : RAM/CPU/disque/IOPS ; prévoir +20 % de marge.
Drivers & firmware : HBA/NIC/RAID à jour, antivirus compatible Windows Server 2022.
Réseau & DNS : SPN des comptes de service, enregistrements DNS, règles firewall, MTU/Jumbo Frames si utilisés.
Inventaire SQL : logins, permissions, linked servers, credentials, proxies, jobs, SSIS/SSRS, collation, TDE, endpoints, CLR.
Anomalies à corriger avant : DB suspectes, CHECKDB en échec, erreurs récurrentes dans SQL Errorlog/Windows Event Log.
Compatibilité applicative : pilotes ODBC/OLE DB récents, clients .NET, TLS durci ; valider que toutes les apps supportent SQL 2022.
Plan test : scénarios fonctionnels, non‑régression perf, KPIs, critères de Go/NoGo.

Playbook détaillé – scénario in‑place

Préparation

Mettre SQL 2014 en SP3. Vérifier l’état des jobs et agents, désactiver les tâches non critiques.
Exécuter une analyse de compatibilité (ex. Data Migration Assistant) pour identifier fonctionnalités dépréciées/breaking changes.
Exécuter DBCC CHECKDB sur toutes les bases et corriger avant upgrade.
Assurer des sauvegardes complètes + journaux + tail‑log juste avant la fenêtre.

Mise à niveau de l’OS

Montée 2012 R2 → 2019 (in‑place), redémarrage, vérifications drivers/services.
Montée 2019 → 2022 (in‑place), redémarrage, post‑checks (Event Logs, NIC/HBA, antivirus).
Réappliquer paramètres OS (pagefile, TCP KeepAlive, plan d’alimentation, antivirus exclusions SQL).

Mise à niveau SQL Server

Stopper les services applicatifs dépendants, désactiver alertes/moniteurs qui pourraient interrompre le setup.
Lancer setup.exe /Action=Upgrade sur l’instance, avec logs détaillés (paramètre /INDICATEPROGRESS et /QUIET selon politique).
Après upgrade : appliquer le dernier Cumulative Update, reconfigurer max server memory, MAXDOP, cost threshold for parallelism, tempdb (fichiers multiples si besoin).

Validation et remise en service

Exécuter DBCC CHECKDB, sp_updatestats, reconstruire les index critiques.
Laisser les bases en niveau de compatibilité d’origine (120) pour redémarrer rapidement. Activer Query Store « Read Write » pour capter les régressions.
Remettre en service les jobs, contrôler l’Errorlog et l’Event Log, exécuter les tests applicatifs.
Augmenter progressivement la compatibilité vers 160 (SQL 2022) après validation.

Playbook détaillé – scénario side‑by‑side (recommandé)

Construction de la nouvelle plateforme

Déployer des serveurs Windows Server 2022 (idéalement virtualisés, CPU/NUMA adaptés).
Installer SQL Server 2022 (Enterprise/Standard selon licence), collation identique à la source, répliquer la structure tempdb, configurer max server memory, MAXDOP, cost threshold.
Appliquer le dernier CU et paramétrer les exclusions antivirus pour SQL (données, journaux, backups, filestream éventuel).
Restaurer logins, credentials, linked servers, operators, DBMail, jobs, alerts ; revalider les SID/UID.

Méthode de bascule

Backup/Restore + log shipping : restaurations en NORECOVERY, rattrapage des logs, coupure courte au switch.
AG temporaire (si Enterprise) : rattacher la nouvelle instance comme réplica, puis basculer le primaire.

Après la bascule

Exécuter DBCC CHECKDB, sp_updatestats, reconstruire les index critiques.
Activer Query Store, démarrer en compatibilité 120 puis monter vers 160 après validation.
Réorienter les connexions applicatives (aliases, chaînes de connexion, balancers/NLB si utilisés).

Spécificités SQL Server à ne pas oublier

Niveaux de compatibilité et régressions

La montée en version peut modifier le comportement de l’optimiseur. Stratégie recommandée : garder la compatibilité initiale au go‑live, activer Query Store, surveiller les plans, puis élever le niveau.

-- Lister les niveaux de compatibilité
SELECT name, compatibility_level 
FROM sys.databases 
ORDER BY name;

-- Activer Query Store (exemple)
ALTER DATABASE MaBase SET QUERY_STORE = ON;
ALTER DATABASE MaBase SET QUERY_STORE (OPERATION_MODE = READ_WRITE);

-- Monter progressivement la compatibilité (exemple)
ALTER DATABASE MaBase SET COMPATIBILITY_LEVEL = 130; -- puis 140, 150, 160

TempDB, MAXDOP, mémoire

tempdb : plusieurs fichiers de même taille, autogrowth mesuré ; placer sur stockage rapide.
MAXDOP : ajuster selon cores/NUMA ; commencer par un réglage conservateur et mesurer.
Cost Threshold : valeur par défaut souvent trop basse pour des charges modernes.

Logins et mappages

Sauvegardez/restaurez les logins en conservant les SID ; vérifiez les utilisateurs « orphelins » après migration.

-- Exemple : logins SQL (hors Windows) avec hash
SELECT sp.name, sl.sid, sl.password_hash
FROM sys.sql_logins sl
JOIN sys.server_principals sp ON sp.sid = sl.sid
WHERE sp.type_desc = 'SQL_LOGIN';

-- Utilisateurs orphelins
EXEC sp_change_users_login 'Report'; -- (versions récentes : ALTER USER ... WITH LOGIN = ...)

TDE et clés

Exporter les certificats/master keys et tester la restauration sur la nouvelle instance avant toute bascule.

SSIS / SSRS

SSIS : réimporter vers le Catalog 2022 et tester l’exécution. Certains packages nécessitent un upgrade du projet.
SSRS : produit autonome ; planifier la migration/upgrade SSRS indépendamment du moteur de base de données.

Maintenance post‑upgrade

-- Statistiques
EXEC sp_updatestats;

-- Intégrité
DBCC CHECKDB WITH NO_INFOMSGS;

-- Trace flags actifs
DBCC TRACESTATUS(-1);

-- Paramètres instance
SELECT name, value_in_use FROM sys.configurations ORDER BY name;

Windows Server et Active Directory

AD : si vous introduisez un DC WS 2022, mettez d’abord à niveau le schéma (et sauvegardez l’état du système). Vérifiez la réplication avant promotion/demotion.
Rôles : bien identifier ce qui cohabite avec SQL (IIS, MSMQ, rôles de fichiers). Éviter les serveurs « fourre‑tout ».
Exclusions AV : bases, journaux, tempdb, dossiers backup/filestream.
Durcissement TLS : exiger des pilotes clients récents (ODBC/OLE DB modernes) pour éviter les ruptures.

SCCM (Configuration Manager) : points d’attention

Compatibilité : votre build SCCM doit explicitement supporter Windows Server 2022 et SQL Server 2022. Si nécessaire, montez SCCM d’abord (Current Branch récente) avant de basculer la base sur SQL 2022.
Niveau de compatibilité base SCCM : certaines versions exigent de rester en compatibilité 150 (équivalent SQL 2019) même si le moteur est 2022 ; ajustez le compatibility level de la base CM si requis par votre build.
Chaînes de connexion : si vous changez d’instance/serveur, mettez à jour les paramètres de site et contrôlez les rôles (Management Point, Distribution Point, SUP, etc.).

Fenêtre de maintenance et gestion du risque

Principaux risques et parades

Risque	Impact	Prévention / Remède
Régression de performances	Ralentissements, timeouts	Query Store, compatibilité initiale conservée, plans figés temporaires, index/stats à jour.
Incompatibilité clients/ODBC	Connexions refusées	Mettre à jour pilotes, durcissement TLS, tests applicatifs anticipés.
Erreur de restauration TDE	Indisponibilité des bases chiffrées	Export/test des certificats/master keys en amont.
Drivers OS obsolètes	Crash/perfs instables	Side‑by‑side, drivers/firmware à jour, plan de retour rapide.
Version SCCM non compatible	Rôles SCCM KO	Mettre SCCM à une build supportant WS 2022 + SQL 2022, ajuster compatibilité DB.

Critères de succès (acceptance)

Intégrité bases : CHECKDB ok, sauvegardes relancées et vérifiées.
KPIs : latence requêtes/transactions dans ±10 % de la baseline initiale (ou meilleure).
Zero erreurs critiques dans SQL Errorlog et Event Logs sur 24–48 h.
Jobs SQL Agent, plans de maintenance et alerting opérationnels.
Applications métiers validées par les équipes fonctionnelles.

Rollback immédiat

Side‑by‑side : revenir au serveur source (remettre la lecture/écriture sur l’ancienne instance). Purger la réplication/log shipping mis en place pour ne pas repartager des données en sens inverse.
In‑place : restauration image/snapshot (hyperviseur), ou restauration backups complets + tail‑log sur la machine d’origine. Anticiper que le rollback prendra plus de temps qu’un retour side‑by‑side.

Exemples de commandes & scripts utiles

Windows Server : inventaire rapide

# Version et build
[System.Environment]::OSVersion.Version
(Get-ComputerInfo).WindowsProductName
(Get-ComputerInfo).OsHardwareAbstractionLayer

# Cartes réseau actives

Get-NetAdapter | Where-Object {$_.Status -eq 'Up'} | Format-Table -Auto

# Services SQL

Get-Service *SQL* | Sort-Object Status, Name | Format-Table -Auto

SQL Server : photographie de l’instance

-- Principaux paramètres d'instance
SELECT name, value_in_use 
FROM sys.configurations 
WHERE name IN ('max server memory (MB)','max degree of parallelism','cost threshold for parallelism')
ORDER BY name;

-- Bases et compatibilité
SELECT d.name, d.compatibility_level, d.recovery_model_desc, s.name AS owner_name
FROM sys.databases d
LEFT JOIN sys.sql_logins s ON s.sid = d.owner_sid
ORDER BY d.name;

-- Agents : jobs désactivés/ratés récemment
SELECT j.name, h.run_date, h.run_time, h.run_status
FROM msdb.dbo.sysjobhistory h
JOIN msdb.dbo.sysjobs j ON j.job_id = h.job_id
WHERE h.run_date >= CONVERT(INT, CONVERT(VARCHAR(8), GETDATE()-7, 112))
AND h.step_id = 0
AND h.run_status <> 1
ORDER BY h.run_date DESC, h.run_time DESC;

Après bascule

-- Mise à jour des stats
EXEC sp_updatestats;

-- Vérification d'intégrité
DBCC CHECKDB WITH NO_INFOMSGS;

-- Monter la compatibilité quand prêt
ALTER DATABASE MaBase SET COMPATIBILITY_LEVEL = 160;

FAQ opérationnelle

Puis‑je faire SQL 2014 → SQL 2022 en un seul saut ?
Oui, à condition d’être en SQL 2014 SP3 au préalable. Démarrez ensuite en compatibilité d’origine et montez après validation.

Dois‑je d’abord mettre l’OS à jour ou SQL Server ?
En side‑by‑side, construisez directement des serveurs Windows Server 2022 et installez SQL 2022. En in‑place, mettez SQL 2014 à SP3, puis montez l’OS (2012 R2→2019→2022), puis SQL 2022.

Et SCCM dans tout ça ?
Vérifiez que votre build supporte WS 2022 et SQL 2022. Certaines versions exigent que la compatibility level de la base SCCM reste temporairement à 150 ; adaptez‑vous à la matrice de support de votre environnement.

SSMS/SSDT : quand ?
Vous pouvez installer la dernière version à tout moment ; ces outils sont indépendants du moteur et utiles pour piloter la migration.

Checklist finale de mise en production

Sauvegardes + restore test validés, certificats TDE restaurés à blanc avec succès.
SQL source en SP3, DMA/analyses corrigées, CHECKDB ok.
Plateforme cible WS 2022 + SQL 2022 prête, CU appliqué, config serveur alignée.
Objets serveur migrés : logins/SID, jobs, linked servers, credentials, DBMail, opérateurs.
Plan de bascule validé (backup‑restore/log shipping/AG) et exécuté sur un environnement de pré‑prod.
Monitoring et alerting actifs (perfmon, XEvent/Query Store, supervision applicative).
Plan de rollback documenté et testé.

Conclusion

Réussir une migration Windows Server/SQL Server/SCCM ne tient pas qu’à l’ordre des actions : il faut surtout préparer, tester, sécuriser et mesurer. L’approche side‑by‑side (serveurs Windows Server 2022 neufs + SQL Server 2022) offre le meilleur compromis risque/downtime/rollback. Si vous êtes contraints à l’in‑place, cadrez une fenêtre plus large et redoublez de validations. Dans tous les cas, commencez par des sauvegardes solides, passez SQL 2014 en SP3, montez l’OS prudemment, puis basculez vers SQL 2022, mettez à niveau SSMS/SSDT et adaptez SCCM au bon niveau de compatibilité. Vos utilisateurs ne verront que l’essentiel : une plateforme plus sûre, plus performante, et prête pour les années à venir.