Estimer le volume et la durée

Mesurer, puis planifier

Le volume grâce à l'Analyse, la vitesse grâce au pilote, quatre tâches à la fois : le plan de chaque vague découle de ces trois éléments.

De quoi dépend la durée

Aucune migration ne se déroule à la même vitesse qu'une autre, car les facteurs qui la déterminent varient d'une organisation à l'autre :

Facteur	Pourquoi c'est important	Où le voir
Volume, versions comprises	La vitesse de migration se mesure par rapport à ce volume, et l'historique des versions peut représenter plusieurs fois la taille des fichiers actuels	L'Analyse, dans l'Historique d'exécution et le Rapport Power BI
Nombre de fichiers	Chaque fichier est traité individuellement : de nombreux petits fichiers prennent donc plus de temps que le même volume réparti en quelques gros fichiers	`File Count` d'une exécution
Portée de l'historique des versions	Moins de versions par fichier signifie moins de volume à transférer	Les paramètres de version de la tâche
Les filtres de fichiers	Le contenu exclu par date, taille ou type n'est pas transféré du tout	Les paramètres avancés de la tâche
Limitation de Microsoft 365	Microsoft 365 ralentit les lectures intensives ou fréquentes	`SPO Rate Limit Delay` dans les détails de l'exécution
Quatre tâches à la fois	Le serveur SMART Migration exécute au maximum quatre tâches simultanément	Les tâches en cours du Tableau de bord
L'édition	Enterprise+ migre jusqu'à trois fois plus vite qu'Enterprise	Votre licence

Étape 1 : mesurer le volume avec l'Analyse

Lancez Analyse sur tout le périmètre : une tâche d'importation crée les tâches pour un tenant entier, un site ou l'ensemble des OneDrive. Lisez ensuite le volume :

Par exécution, dans Historique d'exécution : Files, Volume, Versions et Version volume. Ces valeurs comptent les fichiers nouveaux et modifiés ; placez le pointeur sur le titre d'une exécution d'Analyse pour afficher sa fiche, dont le Total ajoute les fichiers inchangés, soit l'ensemble de la source telle que l'exécution l'a trouvée.
Par bibliothèque, site et vague, dans le Rapport Power BI, avec le volume incluant l'historique des versions et l'ancienneté du contenu.

Décidez de ce qui ne sera pas migré avant d'établir votre estimation : le contenu que personne n'a ouvert ni modifié depuis des années, les archives et les versions dont vous n'avez pas besoin. Chaque gigaoctet écarté représente du temps gagné à chaque vague.

Étape 2 : mesurer la vitesse avec une vague pilote

Lancez une vague pilote de bibliothèques représentatives du reste sous forme de tâches Migration. Pour chaque exécution, ouvrez ses détails :

Duration et Volume donnent la vitesse d'une tâche : le volume divisé par la durée, par exemple en gigaoctets par heure.
SPO Rate Limit Delay indique la part de la durée prise par la limitation de Microsoft 365.

Retenez la vitesse des exécutions les plus volumineuses du pilote : les petites exécutions consacrent une plus grande part de leur temps au démarrage et à la finalisation.

Étape 3 : calculer les vagues

Pour chaque vague, divisez son volume par la vitesse d'une tâche, puis divisez le résultat par quatre pour les tâches exécutées simultanément :

L'estimation pour une vague

Heures ≈ volume de la vague, versions comprises ÷ vitesse d'une tâche ÷ 4

Par exemple, un pilote dont les exécutions ont transféré 40 Go en 8 heures migre 5 Go par heure et par tâche. Une vague de 600 Go prend alors environ 600 ÷ 5 ÷ 4 = 30 heures. Ces chiffres ne sont qu'une illustration : utilisez ceux de votre propre pilote.

Ajoutez ensuite ce qui ne relève pas du temps de migration :

Vérification et validation. Les propriétaires vérifient chaque vague avant la suivante, généralement en quelques jours.
Une marge pour la limitation. Quatre grandes bibliothèques en même temps sollicitent davantage les lectures qu'une seule, et Microsoft 365 peut ralentir les quatre.
La synchronisation finale avant la bascule, qui ne copie que ce qui a changé et reste courte.
Une marge pour les interruptions. Coupures réseau, redémarrages et mises à jour du serveur, autorisations manquantes, fichiers en cours d'utilisation et identifiants expirés surviennent dans toute migration réelle, et chacun coûte le temps nécessaire pour que quelqu'un s'en aperçoive et relance la tâche. Dimensionnez cette marge à partir de votre pilote, mené sur des jours ouvrés ordinaires.

Les analyses prennent aussi du temps

Une analyse de tenant qui crée les tâches lit 30 à 50 sites par minute, soit environ 30 à 40 minutes pour 1 000 sites. Prévoyez-la avant l'Analyse, qui prend ensuite son propre temps par bibliothèque.

Raccourcir la migration

Excluez ce que personne n'utilise avec From Date, et les types de fichiers dont vous n'avez pas besoin avec Source File Type.
Limitez les versions avec Version History Scope.
Travaillez en continu : réglez Scheduled Date sur le soir ou le week-end, et attribuez aux tâches les plus volumineuses une Priority élevée pour qu'elles démarrent en premier.
Répartissez les plus grandes bibliothèques sur les vagues plutôt que de les exécuter côte à côte.
Maintenez la destination à jour avec des tâches récurrentes, afin que la dernière exécution avant la bascule soit courte.
Enterprise+ migre jusqu'à trois fois plus vite qu'Enterprise.

Confiez l'estimation à votre partenaire

Votre partenaire SMART Migration peut réaliser l'estimation avec vous à partir du rapport d'Analyse et du pilote, puis la traduire en calendrier et en offre.

Une fois la migration lancée, la Progression de la migration du Tableau de bord tient l'estimation à jour : elle calcule le temps restant et le débit à partir des exécutions elles-mêmes, en temps de travail, sans les heures où rien ne s'est exécuté. Consultez Ce qu'implique une migration, et ce qui détermine sa vitesse

Voir aussi