Migration vers SharePoint Subscription Edition (SE)

SharePoint Server Subscription Edition (SE) représente un tournant dans l'histoire des environnements On-Premise de Microsoft. Fini les versions figées tous les trois ans (2013, 2016, 2019). SE introduit un modèle de mises à jour continues (Continuous Updates). Mais avant de profiter de cette nouvelle flexibilité, il faut passer par l'étape critique de la migration.

Contrairement aux idées reçues, on ne met pas à jour un serveur SharePoint comme on met à jour un logiciel classique. La méthode de mise à niveau sur place (In-Place Upgrade) n'existe pas. Tout repose sur la migration des données sous-jacentes. Voici une analyse technique approfondie des chemins supportés et de la méthodologie officielle.

1. Chemins de migration (Upgrade Paths) : L'avantage du N-2

La grande nouveauté architecturale avec SharePoint SE réside dans les chemins de migration supportés. Historiquement, Microsoft imposait une migration "N-1" (version par version). Pour passer de 2010 à 2016, il fallait obligatoirement transiter par une ferme 2013 temporaire.

Avec SharePoint SE, Microsoft autorise le N-2.

• Chemins directs supportés : Vous pouvez migrer directement vers SharePoint SE depuis SharePoint 2016 OU SharePoint 2019. C'est un gain de temps et d'infrastructure massif pour les entreprises encore sous 2016, qui peuvent ainsi sauter l'étape 2019.

• Chemin indirect : Si vous êtes encore sur SharePoint 2013, vous n'avez pas le choix. Vous devez d'abord migrer vos bases vers une ferme intermédiaire (2016 ou 2019), les mettre à niveau, puis les migrer à nouveau vers SE.

2. Deep Dive : La méthode "Database Attach"

La seule et unique méthode supportée par Microsoft pour migrer vers SharePoint SE est la méthode Database Attach (Attachement de base de données).

Le concept est simple : on ne migre pas les serveurs, on migre uniquement les données contenues dans SQL Server. L'infrastructure (les serveurs IIS, la topologie, la configuration de la ferme) doit être entièrement reconstruite à neuf.

Les 3 phases de la migration "Database Attach" :

1. Création de la nouvelle ferme (Build) : Vous déployez une toute nouvelle ferme SharePoint SE (idéalement via AutoSPInstaller comme vu dans nos précédents articles). Vous y déployez vos solutions personnalisées (fichiers .wsp), vos configurations d'authentification (OIDC/SAML,NTLM,Kerberos) et vous créez des Web Applications vides.

2. Copie des bases de données SQL (Copy) : Sur l'ancienne ferme (2016/2019), vous passez les bases de données de contenu (Content Databases) et certaines bases de services (Search, User Profile, Managed Metadata) en "Lecture Seule". Vous effectuez un Backup SQL, puis un Restore SQL sur la nouvelle instance SQL Server rattachée à SharePoint SE.

3. Attachement et Mise à niveau (Attach & Upgrade) : Via PowerShell, vous attachez les bases restaurées à vos nouvelles Web Applications SharePoint SE. C'est à cet instant précis que le moteur SharePoint lit l'ancien schéma de la base, le met à jour vers le schéma SE, et rend les données disponibles.

3. Les pièges classiques de la migration

Migrer une base de données ne suffit pas toujours à retrouver un site fonctionnel. Voici ce que vous devez auditer avant de lancer l'attachement :

• Les solutions spécifiques (WSP) : Si votre ancienne ferme utilisait des WebParts développées en interne, des Master Pages personnalisées ou des Event Receivers, vous DEVEZ recompiler et redéployer ces paquets WSP sur la ferme SE avant d'attacher les bases. Sinon, les pages s'afficheront avec des erreurs.

• Le mode d'authentification : Bien que le protocole NTLM soit toujours techniquement présent et supporté dans SharePoint SE, sa suppression annoncée dans les nouvelles versions de Windows Server change la donne. L'écosystème est désormais résolument tourné vers l'authentification moderne. Il est donc fortement préférable de privilégier Kerberos (ou d'autres standards comme OpenID Connect / OIDC, SAML, WS-Fed) pour pérenniser et sécuriser votre infrastructure. Si vos anciennes Web Applications utilisaient le mode Windows Classique (NTLM direct), une conversion de vos utilisateurs vers ces protocoles plus récents sera nécessaire.

4. Scripts PowerShell de migration

L'attachement de base de données ne se fait jamais à l'aveugle. Vous devez d'abord "simuler" l'attachement pour détecter les dépendances manquantes (WSP, Features orphelines, etc.).

Script 1 : Audit pré-migration (Test d'attachement)

Une fois votre base SQL restaurée sur le nouveau serveur, exécutez ce script sur la ferme SE. Il ne modifie rien, mais génère un rapport des erreurs potentielles.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

$WebAppUrl = "https://intranet.votre-entreprise.com"
$DatabaseName = "WSS_Content_Intranet_Migrated"
$SQLServer = "SQL-PROD-SE"

Write-Host "Lancement de l'audit de la base de données..." -ForegroundColor Cyan

# Test de la base de données sans l'attacher
$TestResults = Test-SPContentDatabase -Name $DatabaseName -WebApplication $WebAppUrl -ServerInstance $SQLServer

if ($TestResults.Count -gt 0) {
    Write-Warning "Des anomalies ont été détectées. Veuillez analyser les erreurs suivantes :"
    $TestResults | Format-Table Category, Message, UpgradeBlocking -AutoSize
} else {
    Write-Host "Test réussi : Aucune erreur bloquante détectée. Prêt pour l'attachement." -ForegroundColor Green
}

Note : Portez une attention particulière à la colonne UpgradeBlocking. Si elle est à True, la migration échouera.

Script 2 : L'attachement et la mise à niveau

Une fois les erreurs bloquantes résolues (en déployant les WSP manquants par exemple), vous déclenchez la migration réelle :

Write-Host "Attachement et mise à niveau du schéma de la base..." -ForegroundColor Yellow

# Cette commande lance le processus d'upgrade SQL (peut prendre plusieurs heures selon la taille)
Mount-SPContentDatabase -Name $DatabaseName -WebApplication $WebAppUrl -ServerInstance $SQLServer

Write-Host "Migration de la base terminée." -ForegroundColor Green

5. Références officielles Microsoft

Pour valider votre matrice de compatibilité et suivre la documentation de référence pas à pas :

• Mise à niveau vers SharePoint Server Subscription Edition

• Vue d'ensemble du processus de mise à niveau (Database Attach)

Conclusion

Migrer vers SharePoint SE est un projet d'infrastructure complet qui demande de la rigueur. L'autorisation du chemin direct depuis SharePoint 2016 est une excellente nouvelle, mais elle ne vous dispense pas d'un audit approfondi de vos WebParts, de votre authentification et de l'état de santé de vos bases de données via Test-SPContentDatabase. Prenez le temps de bâtir une ferme SE saine et propre avant d'y injecter votre historique.