Une migration réussie ne se mesure pas seulement au nombre de données transférées. Les employés doivent retrouver leurs courriels, leurs fichiers et leurs outils pour continuer à travailler. On ne peut pas garantir l’absence de toute interruption, mais une préparation structurée peut limiter les perturbations et rendre les imprévus plus faciles à gérer.

Faire un inventaire qui va au-delà des boîtes courriel

Documentez les utilisateurs, les alias, les boîtes partagées, les calendriers, les groupes et les délégations. Ajoutez les fichiers, les espaces partagés, les appareils et les applications qui utilisent les comptes existants.

Identifiez aussi les services qui envoient des courriels pour votre domaine : logiciel de facturation, site Web, imprimantes ou plateforme d’infolettre. Ils risquent d’être oubliés si le projet se concentre uniquement sur Outlook.

Pour chaque élément, précisez le propriétaire, le volume, la destination et la façon de vérifier le résultat. Les anciens comptes demandent une décision : migration, archivage ou suppression autorisée. Une migration n’est pas l’occasion d’effacer sans validation.

Si votre offre actuelle vient de GoDaddy, vérifiez d’abord le scénario de sortie de GoDaddy vers Microsoft 365 : conserver le tenant et changer de fournisseur n’est pas la même opération que migrer les données vers un autre tenant.

Définir la portée et préparer la destination

Créez les comptes, choisissez les licences adaptées et préparez les accès administratifs. Définissez ce qui appartient à OneDrive et ce qui doit être partagé dans SharePoint. Reproduire tous les anciens dossiers sans revoir leur usage peut conserver les problèmes existants.

Activez la MFA et préparez l’accompagnement nécessaire à l’inscription. Vérifiez que vous contrôlez le domaine et les DNS avant de planifier une bascule. La configuration et l’administration Microsoft 365 font partie de cette préparation.

Écrivez les limites : quelles données sont transférées, quels éléments sont exclus et quelles opérations restent manuelles. L’utilisateur ne devrait pas découvrir une exclusion après le changement.

Réaliser un pilote représentatif

Choisissez quelques utilisateurs dont les usages diffèrent. Incluez une boîte partagée, un calendrier délégué ou un fichier complexe si ces éléments existent dans l’organisation.

Testez le transfert, puis la reprise du travail : connexion, recherche de messages, accès aux pièces jointes, partage de fichiers, applications mobiles et envoi depuis les adresses habituelles. Un outil qui indique « terminé » ne remplace pas ces vérifications.

Le pilote sert aussi à estimer l’effort de soutien. Notez les étapes qui demandent une intervention sur chaque poste et ajustez le plan en conséquence.

Expliquer le changement aux employés

La communication doit répondre à des questions simples : quand le changement se produit, ce qui sera différent, ce que l’employé doit faire et qui contacter en cas de problème.

Préparez une courte fiche avec les nouvelles méthodes de connexion, la MFA, l’emplacement des fichiers et les réglages à vérifier. N’envoyez pas de mots de passe dans une communication collective. Prévoyez un canal de soutien qui ne dépend pas uniquement de la messagerie en cours de migration.

Préparer la bascule et les solutions de repli

Conservez un relevé de la configuration initiale. Planifiez la synchronisation finale, les modifications DNS et les tests d’envoi et de réception. Vérifiez SPF, DKIM et DMARC pour l’ensemble des expéditeurs autorisés.

Une politique DMARC stricte ne doit pas être activée sans connaître les sources d’envoi légitimes. Observez et validez les résultats avant de durcir la politique.

Définissez des critères de décision : qu’est-ce qui permet de poursuivre, de retarder ou d’activer une mesure de repli? Un retour arrière n’est pas toujours instantané, particulièrement lorsque les utilisateurs ont commencé à modifier des données dans le nouvel environnement. Gardez l’accès à la source selon un plan de conservation convenu.

Vérifier après le transfert

Contrôlez les volumes, les erreurs remontées, les accès et un échantillon de données. Demandez aux utilisateurs pilotes de confirmer leurs scénarios de travail. Documentez les écarts et traitez-les avant la fermeture définitive de l’ancien service.

Une migration depuis Google demande aussi des décisions sur les formats de documents et les permissions : consultez le guide Google Workspace vers Microsoft 365.

Questions fréquentes

Faut-il faire la bascule pendant la fin de semaine?

Cela dépend des activités et de la disponibilité du soutien. Une plage moins occupée peut aider, mais une bascule sans les personnes nécessaires pour tester peut retarder la détection des problèmes.

Peut-on supprimer l’ancien environnement dès la copie terminée?

Non, pas sans validation du résultat et des obligations de conservation. La fermeture doit suivre des critères convenus, une revue des écarts et l’autorisation de la personne responsable.

Vous pouvez discuter de votre migration avec NetBLB pour préciser le périmètre et préparer les étapes avec votre équipe.