Migrer de Google Workspace vers Microsoft 365

Migrer de Google Workspace à Microsoft 365 mobilise deux outils distincts qu’il ne faut pas confondre. La messagerie, les calendriers et les contacts passent par l’assistant de migration Exchange Online (centre d’administration Exchange → Migration), qui s’authentifie côté Google avec un compte de service et une clé JSON générés depuis Google Cloud. Les fichiers Google Drive (My Drive et Shared Drives) passent par Microsoft Migration Manager, qui s’installe sous forme d’application OAuth depuis Google Workspace Marketplace et n’a pas besoin de compte de service. Ce tutoriel décrit chacune des deux voies, la bascule DNS qui sépare l’avant et l’après, et les vérifications à exécuter avant de couper Google Workspace définitivement.

Article principal : Microsoft 365 pour PME — architecture et gouvernance.

Prérequis

• Un locataire Microsoft 365 Business Standard ou Premium déjà créé, avec licences attribuées.
• Le domaine personnalisé vérifié dans le centre d’administration Microsoft 365 (mais sans avoir encore basculé les enregistrements MX).
• Un compte Super Admin Google Workspace.
• Un accès au DNS du domaine pour modifier les enregistrements MX, SPF, DKIM, autodiscover.
• L’inventaire des comptes (cf. tutoriel Adoption Microsoft 365 — embarquer une équipe en 8 semaines).
• Niveau attendu : administrateur Microsoft 365 confirmé.
• Temps : 4 à 8 heures de configuration, plus la durée de transfert qui dépend du volume (typiquement 24 à 72 heures pour 50 boîtes).

Étape 1 — Préparer Google Workspace côté source (pour la migration des boîtes mail)

La migration des boîtes Gmail via l’assistant Exchange exige un compte de service Google avec délégation à l’échelle du domaine. On le crée dans la console Google Cloud : un projet de service, l’API Gmail, l’API Calendar et l’API Contacts activées, une clé JSON générée pour le compte de service. La clé JSON sera ensuite injectée dans l’assistant Exchange Online, qui pourra alors lire les boîtes Gmail au nom des utilisateurs sans demander le mot de passe de chacun. Cette procédure n’est pas nécessaire pour la migration des fichiers Drive, qui suit une voie OAuth différente décrite à l’étape 4.

# Activation des API requises pour la migration des boîtes Exchange
gcloud auth login
gcloud projects create migration-m365-12345
gcloud config set project migration-m365-12345
gcloud services enable gmail.googleapis.com calendar-json.googleapis.com contacts.googleapis.com

Ces commandes activent les trois API que l’assistant Exchange utilise : Gmail pour les messages, Calendar pour les rendez-vous, People (contacts) pour le carnet d’adresses. La sortie attendue est une confirmation Operation finished successfully pour chacune. On vérifie ensuite dans la console Google Cloud que les trois API apparaissent en statut Activé dans API et services → Tableau de bord. Sans ces activations, la migration retourne une erreur d’autorisation peu explicite quelques heures plus tard.

Étape 2 — Connecter Exchange Online à Google Workspace (boîtes mail)

Dans le centre d’administration Exchange Online, on ouvre Migration → Nouveau lot de migration → Google Workspace (méthode automatisée). L’assistant demande l’adresse email du Super Admin Google et la clé JSON du compte de service générée à l’étape 1. Microsoft valide la connexion en lisant un compte test du domaine.

L’erreur la plus fréquente à ce stade est l’oubli d’autoriser le périmètre OAuth dans la console Google : dans Sécurité → Contrôles des API → Délégation à l’échelle du domaine, on enregistre l’identifiant client du compte de service avec les périmètres OAuth requis (lecture Gmail, lecture Calendar, lecture People). Sans cette délégation explicite, Microsoft peut s’authentifier mais ne peut pas accéder aux boîtes des utilisateurs. Le message d’erreur retourné est insufficient permissions : la résolution est de revérifier les périmètres délégués.

Étape 3 — Migrer la messagerie en mode test (un seul compte)

On migre toujours un compte test avant de lancer le batch complet. Le compte test est typiquement celui d’un administrateur, parce qu’il contient un faisceau d’usages représentatif : des messages structurés en libellés Gmail, des pièces jointes, des invitations de calendrier acceptées, des contacts Google.

Dans l’assistant Exchange, on crée un lot avec un seul utilisateur en glissant son email vers la zone « Utilisateurs à migrer ». Microsoft estime alors la durée et lance le transfert. La progression apparaît dans Migration → Lots de migration avec le statut Synchronisation. Pour 5 Go de boîte mail typique, le transfert prend une à deux heures ; pour 25 Go, on prévoit huit à douze heures.

Une fois le statut Synchronisé atteint, on ouvre Outlook Web Access avec le compte Microsoft du collaborateur test et on contrôle : le nombre de messages dans la boîte de réception, la présence des libellés Gmail (convertis en dossiers Outlook), les pièces jointes lisibles, les invitations de calendrier qui apparaissent comme rendez-vous. Si tout est correct, on garde le test pendant 24 heures pour observer la synchronisation incrémentale (les nouveaux messages arrivés sur Gmail doivent réapparaître dans Outlook dans les 15 minutes).

Étape 4 — Migrer les fichiers Drive vers OneDrive et SharePoint

Les fichiers Drive se transfèrent avec Microsoft Migration Manager, intégré au centre d’administration Microsoft 365 (rubrique Configuration → Migrations et imports → Google Drive ou Google Workspace). Migration Manager est gratuit pour tous les locataires Microsoft 365. À la différence de la migration des boîtes mail, il n’utilise pas de compte de service Google : il s’installe sous forme d’application OAuth depuis Google Workspace Marketplace par un Super Admin Google. Pour les locataires de moins de 100 licences Microsoft 365, l’expérience Migration Manager Lite simplifie le parcours en un assistant unique. Pour les locataires plus grands, on bascule sur le parcours standard en six étapes (connexion, scan, copie, mappage des destinations, mappage des identités, migration et suivi).

# Parcours Migration Manager standard (≥ 100 licences) :
# 1. Centre d'administration Microsoft 365 → Configuration → Migrations et imports
# 2. Créer un projet "Google Workspace"
# 3. Connecter Google : installer l'app M365 migration depuis Google Workspace Marketplace
#    ("Domain install" en tant que Super Admin Google)
# 4. Scan : Migration Manager liste les My Drive et Shared Drives accessibles
# 5. Mapper les destinations :
#    - My Drive de user@gws.com  -->  OneDrive de user@m365.com
#    - Shared Drive "Ventes"     -->  https://exemple.sharepoint.com/sites/commercial/Documents
# 6. Mapper les identités (domaines, groupes, utilisateurs)
# 7. Lancer la migration et surveiller

# Parcours Migration Manager Lite (< 100 licences) :
# Un assistant unique guide les six étapes sans choix avancés ; activé par défaut.

Le bloc résume les deux scénarios principaux. Pour les Drive personnels, on mappe chaque utilisateur vers son compte Microsoft et l'outil dépose les fichiers dans le OneDrive correspondant. Pour les Shared Drives, on choisit la bibliothèque cible dans un site SharePoint pertinent. La sortie est un rapport CSV par lot avec, pour chaque fichier, son statut : migré, en doublon, échec. On exploite ce rapport pour relancer manuellement les échecs (typiquement des fichiers Google natifs — Docs, Sheets, Slides — qui sont automatiquement convertis en .docx, .xlsx, .pptx, mais peuvent échouer si trop volumineux).

Étape 5 — Convertir les fichiers Google natifs

Un Google Doc n'est pas un fichier Word. Il est stocké côté Google sous forme de structure propriétaire et n'a pas d'équivalent binaire local. Migration Manager le convertit automatiquement en .docx en perdant rarement de la structure ; les Sheets deviennent .xlsx, les Slides deviennent .pptx. Cette conversion préserve le texte et la mise en forme la plupart du temps, mais perd certains éléments avancés : scripts Apps Script, formulaires Google embarqués, formules Sheet utilisant des fonctions Google-only (GOOGLEFINANCE, IMPORTRANGE, QUERY).

L'audit qu'on lance avant de couper Google Workspace consiste à parcourir un échantillon de Docs et Sheets critiques après conversion et à valider qu'ils restent fonctionnels. Pour une PME qui automatise des feuilles Sheets avec Apps Script, il faut prévoir une conversion manuelle vers Power Automate (tutoriel Power Automate associé) ou vers Office Scripts pour Excel.

Étape 6 — Basculer les enregistrements DNS

La bascule DNS est l'opération qui interrompt physiquement Google Workspace pour rediriger le mail vers Microsoft 365. On la lance le vendredi soir pour minimiser l'impact d'éventuels couacs. Avant la bascule, on s'assure que la migration des messageries est synchronisée à 100 %, et on lance une dernière synchronisation incrémentale.

Les enregistrements à modifier dans le DNS du domaine : les MX pointent désormais vers les MX Microsoft (typiquement exemple-com.mail.protection.outlook.com), le SPF intègre include:spf.protection.outlook.com, le DKIM est généré côté Microsoft 365 dans Defender → Politiques → Authentification email, le DMARC reste comme avant (généralement v=DMARC1; p=quarantine; rua=mailto:dmarc@exemple.com), un nouveau CNAME autodiscover pointe vers autodiscover.outlook.com.

La propagation DNS prend de quelques minutes à 48 heures selon les TTL configurés. Pour minimiser le risque, on baisse les TTL à 300 secondes 24 heures avant la bascule, on bascule, on vérifie que les nouveaux courriels arrivent dans Microsoft 365, et on remonte les TTL à leur valeur d'origine 48 heures plus tard.

Étape 7 — Migrer les contacts et agendas

Le lot de migration Exchange Online inclut, par défaut, les calendriers et les contacts en plus des messages. Une fois la migration messagerie complète, les rendez-vous des collaborateurs apparaissent dans Outlook avec leurs participants, leurs récurrences, leurs pièces jointes. Les contacts personnels apparaissent dans Personnes.

Les agendas partagés Google (calendriers d'équipe ou de salle) sont une exception : ils ne sont pas migrés automatiquement et doivent être recréés côté Microsoft 365 sous forme de calendriers de groupe ou de salles dans le centre Exchange. On exporte chaque agenda Google au format ICS depuis l'interface Google Calendar, on importe l'ICS dans le calendrier de groupe Microsoft cible, et on désactive l'agenda Google source pour éviter les rendez-vous résiduels.

Étape 8 — Vérifier et désactiver Google Workspace

Une semaine après la bascule DNS, on contrôle plusieurs points avant de désabonner Google Workspace.

# Test 1 : envoi externe -> arrivée dans Microsoft 365
# Depuis un compte Gmail ou Outlook personnel, envoyer un mail au domaine migré
# Vérifier l'arrivée dans Outlook côté Microsoft, contrôler en-têtes
# Le X-MS-Exchange-Organization doit être présent

# Test 2 : autodiscover
nslookup -type=CNAME autodiscover.exemple.com
# Doit retourner : autodiscover.outlook.com

# Test 3 : SPF / DKIM
# Sur https://mxtoolbox.com/spf.aspx, entrer le domaine
# Le record SPF doit inclure spf.protection.outlook.com

Ces trois vérifications confirment que la propagation DNS est complète, que l'autodiscover Outlook fonctionne pour la configuration automatique des clients, et que l'authentification email (SPF, DKIM) protège les envois sortants. Si un test échoue, on remonte au registrar DNS et on revoit l'enregistrement concerné. Tant que tous ne sont pas verts, on ne désactive pas Google Workspace.

La désactivation de Google Workspace se fait en deux temps. Premier : dans le centre d'administration Google, on suspend chaque compte utilisateur (cela coupe l'accès individuel sans supprimer les données — on garde 30 jours de filet de sécurité). Deuxième : après 30 jours sans incident, on résilie l'abonnement Google Workspace, ce qui purge définitivement les données. Avant la résiliation, on télécharge un export Google Takeout par compte au cas où l'on aurait besoin de retrouver un fichier rare non migré.

Étape 9 — Vérification finale

Pour clôturer le projet, on documente l'état final dans un livrable consultable par la direction.

# Comparaison des volumétries avant/après
Connect-MgGraph -Scopes "Reports.Read.All","User.Read.All"
$rapport = @()
$users = Get-MgUser -All -Filter "accountEnabled eq true"
foreach ($u in $users) {
  $stats = Get-MgUserMailboxStatistics -UserId $u.Id -ErrorAction SilentlyContinue
  $rapport += [PSCustomObject]@{
    UPN = $u.UserPrincipalName
    BoiteMo = if ($stats) { [math]::Round($stats.TotalItemSize.Value / 1MB, 0) } else { 0 }
    Messages = if ($stats) { $stats.ItemCount } else { 0 }
  }
}
$rapport | Export-Csv -Path .\bilan-migration-gws.csv -NoTypeInformation -Encoding UTF8

Le fichier exporté liste, pour chaque compte, la taille de la boîte aux lettres et le nombre de messages côté Microsoft. On le compare au tableau de l'étape 1 (volumétries Gmail estimées) pour valider la complétude. Un écart inférieur à 5 % est attendu (différences d'index, libellés multiples comptés une seule fois côté Outlook). Un écart supérieur à 10 % signale une boîte qui n'a pas migré entièrement ; on la relance via un nouveau lot ciblé sur ce compte.

Erreurs fréquentes

FAQ

Combien de temps prend la migration complète ?

Pour 30 boîtes de 5 Go en moyenne, la fenêtre standard est de 4 à 7 jours : 1 jour de préparation, 24 à 48 heures de transfert messagerie, 2 à 3 jours de migration des fichiers Drive (selon volumétrie), 1 jour de bascule DNS et de validation. Pour 100 boîtes ou plus, on planifie deux à trois semaines.

Faut-il migrer avant ou après la formation des utilisateurs ?

La formation se fait après la bascule DNS pour éviter de former des utilisateurs sur un environnement qu'ils n'utilisent pas encore. Mais la communication interne commence avant : deux semaines avant la bascule, une note explique le calendrier et les changements visibles (nouvelle interface Outlook, OneDrive au lieu de Drive). Le tutoriel Adoption Microsoft 365 détaille la séquence complète.

Que faire des comptes Google Workspace après migration ?

On les suspend pendant 30 jours (filet de sécurité), on télécharge un export Google Takeout par compte, puis on résilie l'abonnement Google Workspace. Cette séquence évite la double facturation tout en préservant la possibilité de retrouver un document oublié pendant la fenêtre de transition.

La migration préserve-t-elle les permissions de partage Google Drive ?

Partiellement. Les permissions internes (entre comptes du domaine migré) sont reconstruites côté Microsoft à partir de l'annuaire commun. Les permissions externes (avec des comptes Gmail externes au domaine) ne sont pas reportées ; il faut les recréer manuellement côté SharePoint via une invitation nominative — ce qui est une bonne occasion de revoir si ces partages externes restent légitimes.

Peut-on migrer en deux temps (un service à la fois) ?

Oui, c'est même recommandé pour les organisations supérieures à 100 collaborateurs. On migre par service (Comptabilité d'abord, Commercial ensuite, Production en dernier) avec une bascule DNS unique mais des activations Microsoft 365 progressives. Pendant cette période hybride, on configure le routage Exchange pour que les comptes non encore migrés reçoivent leur mail sur Google. Cette configuration s'appelle un connecteur dans le centre Exchange.

Tutoriels associés

• Adoption Microsoft 365 — embarquer une équipe en 8 semaines
• Structurer SharePoint Online — sites et bibliothèques
• Retour au guide : Microsoft 365 pour PME — architecture et gouvernance

Ressources officielles

• Migrer les boîtes Gmail vers Exchange Online — Microsoft Learn
• Migration Manager — migration Google Drive
• Ajouter un domaine personnalisé à Microsoft 365
• Délégation à l'échelle du domaine — Google Workspace
• Configurer les enregistrements DNS Microsoft 365