Business Digital

Migrer de Microsoft 365 vers Google Workspace : tutoriel pas-à-pas

9 min de lecture

📍 Article principal : Google Workspace pour PME : architecture et gouvernance
Ce tutoriel détaille la migration depuis Microsoft 365 vers Google Workspace : Data Migration Service, cohabitation MX, Workspace Migrate pour Drive/SharePoint, GWSMO pour Outlook.

Objectif

Migrer les boîtes mail, calendriers, contacts, fichiers OneDrive et SharePoint d’une organisation Microsoft 365 vers Google Workspace, avec cohabitation MX pour préserver le flux mail entrant pendant la transition.

Outils officiels

  • Data Migration Service (DMS) — intégré à la console d’administration Workspace, sans agent local. Source : Microsoft 365, Exchange, IMAP. Périmètre : mail, calendrier, contacts. Adapté aux migrations jusqu’à environ 100 Go par boîte.
  • Google Workspace Migrate — installeur Windows, requiert serveur Windows dédié. Source : Microsoft 365, Exchange, OneDrive, SharePoint, fichiers de partage Windows. Adapté aux volumes Drive supérieurs au téraoctet et aux migrations multi-services.
  • Google Workspace Sync for Microsoft Outlook (GWSMO) — agent client Windows. Permet à Outlook de se connecter à un backend Workspace pour mail, calendrier, contacts. Toujours supporté en 2026 (mises à jour janvier 2026 dans les release notes officielles).

Prérequis

  • Tenant Microsoft 365 source avec compte Global Admin opérationnel.
  • Tenant Workspace cible créé et domaine vérifié.
  • Compte super-administrateur Workspace avec 2SV activée.
  • Accès administrateur à la zone DNS du domaine principal.
  • Pour Workspace Migrate (configuration platform server officielle) : Windows Server 2016 ou 2019, .NET Framework 4.5+, au moins 4 cœurs, 16 Go RAM, 200 Go SSD. Pour les déploiements importants, des serveurs node additionnels avec 32 Go RAM sont documentés.
  • Niveau : avancé.
  • Calendrier : 14 jours en cohabitation pour 30 utilisateurs ; 4 à 8 semaines pour des volumes Drive supérieurs au téraoctet.

Étape 1 — Inventaire de la source

Sur admin.microsoft.com, documenter dans un Sheets de pilotage :

  • Liste des utilisateurs actifs avec adresse principale et alias.
  • Taille de boîte mail par utilisateur (centre Exchange admin → Recipients → Mailboxes).
  • Boîtes partagées et propriétaires.
  • Groupes de distribution avec leurs membres.
  • Salles et ressources de réservation.
  • Volumétrie OneDrive par utilisateur, sites SharePoint actifs.
  • Comptes service utilisés par des intégrations (CRM, ERP, scanners).

Pour les règles Outlook côté client, demander aux utilisateurs clés un export via Outlook : Fichier → Règles → Gérer les règles → Exporter. Les règles Outlook ne migrent pas automatiquement.

Étape 2 — Provisioning des comptes Workspace en miroir

Dans la console Workspace : Annuaire → Utilisateurs → Importer. Télécharger le modèle CSV, remplir avec les utilisateurs source. Colonnes : First Name, Last Name, Email Address, Password, Org Unit Path. Les adresses doivent être identiques aux adresses Microsoft 365 pour que le mapping de Data Migration Service soit automatique.

Recréer côté Workspace les groupes Google équivalents aux groupes de distribution Microsoft 365. Pour les boîtes partagées Microsoft 365, deux options selon l’usage :

  • Délégation Gmail : un compte Workspace principal partage sa boîte avec des collègues délégués. Adapté aux boîtes type contact@.
  • Boîte de réception collaborative dans Google Groups : adapté aux listes type support@ avec gestion d’attribution et statut.

Étape 3 — Configuration de Data Migration Service

Dans la console Workspace : Compte → Migration de données → Définir la migration. Source : Microsoft Office 365. Authentification via le compte Global Admin Microsoft 365 et accord des autorisations OAuth.

Périmètre Email en première migration. Plage de dates : tous les emails ou les 12 derniers mois selon la stratégie. Exclure les dossiers Spam et Corbeille pour ne pas migrer du bruit.

Mapping utilisateurs : automatique si les adresses sont identiques de chaque côté ; sinon CSV de mapping.

Étape 4 — Pilote (2-3 utilisateurs représentatifs)

Lancer la migration pour 2 ou 3 utilisateurs pilotes : un avec beaucoup d’emails, un avec un calendrier dense, un avec règles Outlook complexes.

Une fois la migration mail terminée, vérification utilisateur :

  • Nombre d’emails dans la boîte de réception comparable au compte source.
  • Dossiers Outlook devenus libellés Gmail.
  • Pièces jointes lisibles.
  • Encodage des accents préservé.

Lancer ensuite les périmètres calendrier et contacts pour les pilotes via la même interface.

Étape 5 — Cohabitation MX (routage à double remise)

Source officielle : Configurer le routage à double remise.

Côté Workspace, dans Applications → Google Workspace → Gmail → Routage, ajouter une règle Recevoir le courrier des serveurs externes avec le serveur SMTP Microsoft 365 comme source autorisée.

Côté Microsoft 365, configurer un connecteur sortant qui pousse les messages vers smtp.google.com en plus de la livraison locale Microsoft.

Test : envoi d’un mail externe vers un utilisateur — réception attendue dans Gmail Workspace (en plus de la boîte Microsoft) en moins de 2 minutes. Si l’un des côtés ne reçoit pas, ajuster avant de poursuivre.

Étape 6 — Migration de masse et bascule MX

Lancer la migration mail pour l’ensemble des utilisateurs depuis Data Migration Service. Selon volume et threads concurrents Microsoft (typiquement 4 à 8), la migration prend de 12 heures à plusieurs jours.

Préparation de la bascule MX :

  • J-2 : baisser le TTL des MX à 300 secondes pour accélérer la propagation.
  • J-0 (de préférence vendredi soir) : modifier le MX pour pointer uniquement vers smtp.google.com avec priorité 1, supprimer l’ancien MX Microsoft 365.

Vérification :

dig +short MX mondomaine.tld
# Résultat attendu : 1 smtp.google.com.

Maintenir la cohabitation côté Microsoft (recevoir + transférer vers Workspace) pendant 7 à 14 jours pour absorber les emails encore livrés à l’ancien serveur par des relais à cache long.

Étape 7 — Migration Drive avec Google Workspace Migrate

Pour les volumes OneDrive et SharePoint significatifs.

Téléchargement et installation de l’outil sur la VM Windows Server depuis la console Workspace : Compte → Migrate → Download. Configuration des credentials : compte Global Admin Microsoft 365 côté source, super-admin Workspace côté cible. Lancer le scanner d’inventaire qui répertorie les contenus.

Création des jobs :

  • OneDrive vers Drive personnel — un job par utilisateur ou batch CSV.
  • SharePoint vers Drive partagé — un job par site SharePoint mappé vers un Drive partagé Workspace.

Options à activer : préserver les permissions, préserver les versions pour les documents critiques. Lancer un site à la fois pour suivre la progression. Les fichiers protégés par mot de passe et les types métiers propriétaires (Forms, Lists complexes) ne migrent pas et nécessitent une approche manuelle.

Étape 8 — GWSMO pour utilisateurs Outlook

Pour les utilisateurs qui souhaitent conserver Outlook : téléchargement sur tools.google.com/dlpage/gssmo. Installation sur le poste Windows. Au premier lancement, GWSMO demande l’authentification au compte Workspace (avec 2SV) et propose de créer un nouveau profil Outlook.

Choisir une migration partielle (3 ou 12 mois) pour limiter le temps d’initialisation. GWSMO ne supporte pas tous les usages avancés de Gmail (libellés multiples sur un même message, certaines fonctionnalités Gemini) — solution transitoire pour absorber la résistance au changement.

Vérification finale

Au J+14, contrôles :

  • Rapport Data Migration Service : 100 % d’emails transférés pour tous les utilisateurs.
  • Rapport Workspace Migrate : 100 % de fichiers Drive copiés.
  • Test envoi externe (compte Yahoo ou Gmail personnel) → 3 utilisateurs migrés : réception attendue dans Gmail Workspace en moins de 2 minutes.
  • Test création de réunion calendrier avec 5 invités : invitations reçues côté invités.
  • Test partage d’un document Drive avec un externe : accès opérationnel.

Une fois validé, déclencher la fermeture progressive du tenant Microsoft 365. Le conserver actif 30 jours en mode lecture seule (suspension des comptes) avant résiliation. Conserver un export PST des boîtes critiques sur Drive pour archive.

Erreurs fréquentes

Erreur Cause Solution
Emails livrés deux fois Ancien MX non supprimé après bascule Supprimer tous les autres MX, ne conserver que 1 smtp.google.com
Emails perdus à la bascule TTL DNS trop long, propagation lente TTL à 300s 48 h avant la bascule
Réunions calendrier dédoublonnées Migration calendrier relancée sur boîte déjà migrée Suivre la progression, ne pas relancer un job 100 % achevé
Permissions SharePoint non préservées Mapping de groupes manquant côté Workspace Recréer les groupes Workspace équivalents avant migration Drive
Boîtes partagées non migrées Non identifiées dans l’inventaire Audit complet à l’étape 1, créer des délégations ou groupes collaboratifs
Règles Outlook perdues Règles côté client, non migrées par DMS Export avant migration, recréation manuelle dans Gmail comme filtres
Comptes service M365 inopérants après bascule Credentials Microsoft Graph non transposés Réécriture en Apps Script ou Gmail API selon le besoin

Tutoriels associés

Références officielles

FAQ

Durée d’une migration complète ?
Pour 30 utilisateurs avec 5 Go de mail moyen et 50 Go de OneDrive moyen : 14 jours calendaires en cohabitation. Pour 100+ utilisateurs ou plus d’1 To de Drive : 4 à 8 semaines.

Migration Teams vers Meet ?
Pas d’outil officiel pour les conversations Teams. Le calendrier migre via Data Migration Service (les réunions Teams récurrentes sont reproduites manuellement en Meet). Les fichiers stockés dans SharePoint via Teams migrent via Workspace Migrate.

Que faire des PST locaux ?
Data Migration Service ne lit pas les PST. Deux options : importer les PST dans la boîte Microsoft source via AzCopy ou Outlook avant la migration ; importer dans Outlook après installation de GWSMO côté client.

Annulation immédiate de Microsoft 365 ?
Non recommandée. Conserver Microsoft 365 actif 30 jours après la bascule en mode lecture seule (suspension des comptes), pour récupérer un détail oublié. Au-delà, résiliation et archive PST sur Drive.

Migration des signatures Outlook ?
Les signatures sont locales au client Outlook. Les utilisateurs les exportent (texte + image) et les recréent dans Gmail via Paramètres → Signature. Pour standardisation centralisée, l’admin Workspace utilise Apps → Gmail → Paramètres utilisateur → Signature.

2SV Microsoft transférée à Workspace ?
Non. Les méthodes de second facteur Microsoft sont liées au tenant M365. Chaque utilisateur réenrôle ses méthodes côté Workspace. Profiter de la migration pour standardiser sur Authenticator app et clés FIDO2.

Partager