Migrer de Google Workspace vers Microsoft 365 sans casser la productivité

Les migrations Google Workspace → Microsoft 365 reviennent souvent : une PME a démarré historiquement sur Google Apps for Your Domain (l’ancêtre de Workspace), a grandi, intègre maintenant des outils Microsoft (Teams, SharePoint, Power Platform, ou simplement la suite Office native pour les financiers et juridiques), et finit par poser la question du basculement complet. Voici la méthode que nous appliquons quand le déclic est pris.

La question préalable : faut-il vraiment migrer ?

Avant de migrer, on prend le temps de poser la question. Google Workspace est un produit excellent, particulièrement pour les équipes collaboratives et les workflows web. Migrer vers Microsoft 365 a un sens dans plusieurs cas : besoin de la suite Office complète en client lourd (Excel pour les financiers est incomparable à Sheets), intégration avec des outils métier Microsoft (Dynamics 365, Power BI, Power Platform), exigence de conformité (Purview pour la classification de données, Sensitivity Labels), ou tout simplement choix stratégique aligné avec la pile technique du groupe.

Si aucun de ces critères ne s’applique fortement, rester sur Workspace et investir dans son outillage est souvent la meilleure décision. La migration n’est pas une fin en soi.

Le calendrier réaliste

Pour une PME de 50 utilisateurs, une migration complète Workspace → M365 prend 6 à 10 semaines chez nous. Voici la décomposition :

• Semaines 1-2 : audit + préparation. Inventaire des utilisateurs, des partages Drive, des calendriers, des labels Gmail, des intégrations tierces. Création du tenant M365, configuration du domaine en pré-coexistence (les MX restent sur Google le temps de la migration), mise en place des politiques de sécurité (MFA, Conditional Access, DLP), création des comptes M365.
• Semaines 3-4 : migration des données. Bascule des emails par vagues (groupes de 10-15 utilisateurs), migration du Drive vers OneDrive et SharePoint avec conservation de l’arborescence, basculement des calendriers et des contacts.
• Semaines 5-6 : bascule MX + finalisation. Cut-over DNS (les emails arrivent désormais dans M365), nettoyage Workspace, formation utilisateurs sur Outlook + Teams + OneDrive.
• Semaines 7-10 (selon complexité) : décommissionnement. Période de coexistence prolongée pour récupérer les rares emails arrivés en retard sur Google, désactivation finale des licences Workspace, archivage des données nécessaires (obligations comptables, RH).

Les outils qu’on utilise

Trois familles d’outils selon la complexité :

• BitTitan MigrationWiz : la référence pour les grosses migrations, prix à l’utilisateur, supporte tous les types de données (mail, drive, contacts, calendriers, sites SharePoint cibles). Fiabilité industrielle.
• SkyKick Migration Suites : alternative bien intégrée pour les partenaires Microsoft, plus orientée PME, interface plus accessible.
• Outils Microsoft natifs : Microsoft Migration Manager pour Drive → OneDrive/SharePoint, IMAP migration intégrée à Exchange Online pour les emails. Suffisant pour les petites migrations (<20 utilisateurs) où l’on accepte des limites (pas de migration des labels Gmail en dossiers Outlook, etc.).

Notre choix par défaut sur les migrations 30-150 utilisateurs : BitTitan, qui justifie son coût par la prévisibilité.

Les pièges récurrents

Le Drive partagé. Sur Google Workspace, un dossier partagé peut appartenir à un utilisateur (et disparaître quand il part) ou à un Drive partagé d’équipe. Les deux cas se migrent différemment vers SharePoint. Cartographier finement avant migration évite des découvertes désagréables une semaine après le cut-over.

Les automatisations Google Apps Script. Beaucoup d’organisations ont accumulé des scripts qui automatisent des tâches dans Sheets ou Forms. Aucun ne migre automatiquement. Il faut décider lesquels recréer en Power Automate ou en Office Scripts, et lesquels abandonner.

Les intégrations tierces. Slack, Asana, Notion, Zoom : presque tous ces outils ont une intégration SSO Google et une intégration SSO Microsoft, mais chaque connecteur doit être reconnecté manuellement après la bascule. Prévoir une vague de re-authentification dans les 48h post-cut-over.

Les groupes Google. Les groups@example.com doivent devenir des Microsoft 365 Groups ou des distribution lists Exchange. Le mapping n’est pas trivial selon l’usage (liste de diffusion vs collaboration vs droits sur des dossiers).

La sécurité, le moment d’élever le niveau

Une migration est l’occasion de remettre le niveau de sécurité au standard. Sur tous nos projets Workspace → M365, nous activons systématiquement : MFA obligatoire pour tous les comptes (avec Authenticator + passkeys pour les administrateurs), Conditional Access basé sur la conformité de l’appareil (couplage MDM Intune ou Kandji), Microsoft Defender for Office 365 pour la protection email, audit logs activés et supervisés, et Sensitivity Labels Purview pour les données sensibles.

C’est aussi le moment de retirer les comptes dormants accumulés dans Workspace (en règle générale 10 à 20% des comptes d’une PME mature) et de réviser les groupes.

Le jour de la bascule MX

Le moment le plus stressant est le cut-over DNS — la modification des enregistrements MX qui fait que les emails entrants vont désormais vers M365 au lieu de Google. Quelques règles : faire la bascule un jeudi soir (jamais un vendredi, pour avoir un jour ouvré complet pour réagir), réduire le TTL DNS à 5 minutes 24h avant pour faciliter les retours en arrière, prévenir les utilisateurs qu’ils peuvent recevoir quelques emails en retard sur Google pendant 24-48h après la bascule, monitorer activement la file d’envoi M365.

Si vous envisagez une migration cloud à courte échéance, un audit IT initial gratuit chez Macinwork dimensionne le projet et identifie les pièges spécifiques à votre contexte. Le formulaire en bas de la home est fait pour ça.