Migrer entre Google Workspace et Microsoft 365 (guide cross-platform 2026)

Les migrations cross-platform surviennent plus souvent qu'on ne le croit. D'après notre expérience chez AfricWebHosting, environ 5 à 10 % de nos clients passent d'un écosystème à l'autre dans les 2 premières années. Voici les cas typiques :

• Fusion ou rachat : l'entreprise A (sur Google) est rachetée par l'entreprise B (sur Microsoft, ou vice-versa). Le groupe décide d'unifier sur une seule plateforme. C'est le cas le plus courant et souvent le plus urgent.
• Changement de standard interne : une startup sur Google Workspace atteint 30-50 collaborateurs et son équipe finance/juridique exige Word, Excel avancé, Outlook et Conditional Access. Décision stratégique de basculer vers M365.
• Pression des clients : une agence dont tous les clients partagent des documents via SharePoint/Teams se retrouve à convertir en permanence depuis Google Docs. Le coût d'opportunité finit par justifier la migration.
• Réduction de coûts : plus rare, mais certaines PME passent de M365 Premium (22 €/u/mois) à Google Workspace Standard (14,90 €/u/mois) lors d'une restructuration budgétaire.

Quelle que soit la direction (Google → Microsoft ou Microsoft → Google), la logique reste la même : migrer les emails, les calendriers, les contacts, les fichiers et les configurations admin — dans cet ordre de priorité.

Ce guide couvre les deux sens. Les outils et la complexité sont légèrement différents selon la direction.

Avant de commencer, rassemblez ces éléments — sans eux, la migration sera chaotique :

1. Accès admin source ET cible : vous avez besoin d'un compte Super Admin sur le tenant source (Google ou Microsoft) ET d'un compte Global Admin sur le tenant de destination. Sans ça, les outils de migration ne peuvent pas s'authentifier.
2. Mapping des comptes : un utilisateur Google = un utilisateur Microsoft 365. Préparez un tableau CSV avec trois colonnes : email_source, email_cible, nom_affiche. Si des adresses changent pendant la migration (fusion avec changement de domaine), documentez-le explicitement. Un mapping incorrect = des emails livrés dans la mauvaise boîte.
3. Inventaire des ressources partagées :
   • Google → M365 : lister tous les Shared Drives, groupes Google, calendriers de ressources (salles de réunion), comptes de service.
   • M365 → Google : lister toutes les bibliothèques SharePoint, groupes Microsoft 365, calendriers Exchange de ressources, boîtes partagées (shared mailboxes).
4. Taille des données : mesurez la taille totale de chaque boîte (emails + Drive/OneDrive) avant de commencer. Google Workspace Admin Console → Reports → User usage donne la taille par utilisateur. M365 Admin Center → Active users → Export donne la même information. Les outils de migration limitent parfois le débit — connaître les volumes permet de planifier le timing.
5. Plan de rollback : gardez l'ancien tenant actif en lecture seule pendant 30 jours après la migration. Ne fermez pas les licences source immédiatement — vous pourriez avoir besoin de récupérer un email ou un fichier oublié.

C'est la partie la plus critique — et la plus outillée.

Direction Google Workspace → Microsoft 365

Utilisez le Microsoft Migration Manager (intégré au Centre d'administration M365, section Setup → Migration). Il supporte nativement la migration Gmail → Exchange Online via IMAP et via l'API Google Workspace. L'API Google est la méthode recommandée — elle est plus rapide et préserve mieux les dossiers. Étapes :

1. Dans Migration Manager, créez un projet "Google Workspace".
2. Connectez votre compte Super Admin Google (OAuth).
3. Uploadez votre CSV de mapping.
4. Lancez la pré-scan pour estimer les volumes.
5. Lancez la migration initiale (J-3 à J-5 avant cutover pour les gros volumes).
6. Le jour J, lancez la passe delta (emails des dernières 24h), puis basculez les MX.

Limites connues : ~30 Go/boîte par run (plusieurs runs possibles), les labels Gmail deviennent des dossiers Exchange (pas toujours proprement), les signatures HTML peuvent être perdues ou mal formatées. Les emails antérieurs à 2010 peuvent avoir des problèmes d'encodage.

Direction Microsoft 365 → Google Workspace

Utilisez le Google Workspace Migration Tool for Microsoft Exchange (GWMME), téléchargeable depuis la Google Workspace Admin Console. Il se connecte à Exchange Online via EWS (Exchange Web Services). Étapes similaires à ci-dessus mais depuis la console Google. Limites : même plafond de ~30 Go/boîte par run, certains types de réunions récurrentes Exchange peuvent être mal retranscrits dans Google Calendar.

Contacts : exportez en vCard (.vcf) ou CSV depuis le tenant source, importez dans le tenant cible. Simple mais manuel.

Calendriers : les événements récurrents complexes (réunions hebdomadaires avec des exceptions) ne migrent pas toujours parfaitement. Planifiez une vérification manuelle sur les 5 calendriers les plus actifs après migration.

La migration de fichiers est souvent plus longue que la migration email — et les erreurs sont moins visibles (un fichier mal placé peut passer inaperçu plusieurs semaines).

Google Drive → OneDrive / SharePoint

Microsoft propose Mover.io (intégré à Migration Manager) qui supporte nativement la migration Google Drive → OneDrive et Google Shared Drives → SharePoint. C'est l'outil recommandé :

• Connectez les deux tenants (OAuth).
• Mappez les utilisateurs (même CSV que pour les emails).
• Pour les Shared Drives, mappez vers des bibliothèques SharePoint de destination.
• Lancez la migration. Mover.io crée un rapport de migration avec les fichiers réussis/échoués.

Débit estimé : comptez 1 à 2 jours pour 100 Go par utilisateur, selon la connexion et le nombre de petits fichiers (les millions de petits fichiers < 1 Mo sont plus lents à migrer que quelques gros fichiers).

OneDrive / SharePoint → Google Drive

Moins outillé nativement. Options :

• Mover.io supporte aussi la direction M365 → Google Drive (via connecteur SharePoint/OneDrive).
• MultCloud (outil tiers, freemium) : connecte les deux clouds et transfère en arrière-plan. Simple pour les petits volumes (< 50 Go).
• Script PowerShell + rclone : pour les grandes migrations (500 Go+), rclone avec les connecteurs OneDrive et Google Drive est fiable et gratuit. Nécessite un technicien capable d'écrire et monitorer des scripts.

Points d'attention :

• Les permissions fine-grained (accès partagé avec des externes) ne migrent pas — elles doivent être recrées manuellement dans le tenant cible.
• Les fichiers Google Docs/Sheets/Slides natifs (format .gdoc) sont convertis en .docx/.xlsx/.pptx lors de la migration vers M365. La mise en page peut légèrement différer. Vérifiez les 20 fichiers les plus importants après migration.
• Les fichiers Word/Excel/PowerPoint migrent depuis M365 vers Google Drive sans conversion et s'ouvrent dans Google avec l'extension de compatibilité Office.

Voici ce que vous perdez dans une migration cross-platform — sans exception selon nos expériences terrain :

Élément	Google → M365	M365 → Google
Historique chats Teams / Google Chat	Perdu (pas migrable)	Perdu (pas migrable)
Enregistrements de réunions	Migrent comme fichiers vidéo	Migrent comme fichiers vidéo
Apps tierces connectées (Zapier, Slack, etc.)	À reconfigurer manuellement	À reconfigurer manuellement
Google Forms	Export PDF, recréer dans M365 Forms	N/A
Microsoft Forms	N/A	Export CSV des réponses, recréer dans Google Forms
Workflows Zapier sur comptes G/M	À reconfigurer avec nouveaux comptes	Idem
Signatures email HTML	Souvent perdues ou malformées	Idem
Règles de filtrage email	Non migrées, à recréer	Non migrées, à recréer
Google Sites / SharePoint Intranet	À reconstruire	À reconstruire
Macros VBA Excel	Fonctionnent en M365 (natif)	Non supportées dans Google Sheets

Les éléments les plus impactants pour la plupart des PME sont : la perte de l'historique des chats (Teams ↔ Chat), la nécessité de reconfigurer les apps tierces, et la recréation des signatures email. Prévenez votre équipe avant la migration — une communication transparente réduit les tickets de support post-migration de 50 %.

Voici le planning que nous suivons pour une migration cross-platform de 10 utilisateurs (données email + Drive/OneDrive) :

Phase	Durée	Actions
Préparation	5 jours ouvrés	Inventaire, CSV mapping, création tenant cible, configuration DNS test, audit des apps tierces
Pré-migration	J-3 à J-1	Migration email initiale (90 % des données), migration fichiers en arrière-plan, tests sur comptes pilotes
Cutover	2-4 heures	Passe delta emails, bascule MX, configuration SPF/DKIM/DMARC, test de livraison, notification équipe
Post-migration	5 jours ouvrés	Support utilisateurs, recréation signatures, reconnexion apps tierces, vérification fichiers critiques

Total pour 10 utilisateurs : environ 1 semaine de préparation + 2 jours de cutover + 1 semaine de post-migration.

Pour 50 utilisateurs, doublez la phase de préparation et ajoutez 1 journée de cutover.

Pour 100+ utilisateurs, comptez 3 à 4 semaines de préparation et un cutover en plusieurs vagues (par département).

Notre offre AfricWebHosting cross-platform

Nous proposons des forfaits de migration cross-platform clé en main :

• Starter (jusqu'à 10 users) : 590 € HT — inclut préparation, migration emails + fichiers, cutover, post-migration (5 jours de support)
• Standard (11 à 50 users) : 990 € HT — idem + formation équipe (2h visio) + rapport de migration
• Enterprise (51 users et plus) : sur devis — migration en vagues, coordination RH, support prioritaire 30 jours

Ces forfaits ne comprennent pas le coût des licences destination (Microsoft 365 ou Google Workspace). Contactez-nous pour un devis personnalisé — nous répondons sous 24 heures ouvrées.

Si vous êtes en train de préparer votre migration, lisez aussi nos guides connexes : Migrer vers Microsoft 365 depuis IONOS/OVH/Gandi et Microsoft 365 vs Google Workspace : comment choisir ?