Como Migrar de Google Workspace para Microsoft 365 (e Vice-Versa) em 2026

Google Workspace · Microsoft 365 · Migração · OAuth 2.0 · BitTitan · MigrationWiz · Cloudiway  |  ✎ Duarte Spínola  |  13 de Junho de 2026

A migração entre Google Workspace e Microsoft 365 é cada vez mais comum em 2026 – 30% das empresas mid-market consideram mudar de fornecedor a cada 2-3 anos (Gartner, 2024). Razões: consolidação de produtividade (Teams vs Meet), preço (Google é mais barato para SMB), integração com AD on-prem (Microsoft), apps de negócio (Microsoft Lists, Loop, Google Sites), e compliance (Microsoft tem mais certificações). Em 2024, a Google descontinuou Basic Auth em IMAP/SMTP (Set-2024) – qualquer migração em 2026+ exige OAuth 2.0. Este artigo cobre 4 cenários (Google -> M365, M365 -> Google, hybrid, parcial), OAuth 2.0 + Modern Authentication, 5 fases de migração (pré-planeamento, cutover, validação, decommission), 3 ferramentas oficiais (BitTitan, Cloudiway, manual PowerShell+GAM), coexistência híbrida durante 3-6 meses, e os 10 problemas mais comuns.

1. Os 4 cenários de migração

2. O que muda em 2026: OAuth 2.0 obrigatório

Desde Set-2024, a Google descontinuou Basic Auth em IMAP/SMTP para Gmail/Workspace. O que significa:

• Basic Auth (legacy): username + password – não funciona mais em 2026.
• OAuth 2.0 (moderno): tokens scoped, expiração curta, MFA obrigatória – única forma suportada.

Microsoft 365 usa Modern Authentication (OAuth 2.0 + ADAL/MSAL) desde 2019. Para ambos os lados, a migração exige:

1. App registration no Azure AD / Google Cloud Console.
2. OAuth consent do admin tenant.
3. Refresh tokens em vez de passwords.
4. Scopes granulares (mail.read, mail.write, calendar.read, etc.).

3. Cenários onde se aplica

• [T] PME 5-50 employees a migrar de Google Workspace para Microsoft 365.
• [T] Empresa 50-5000 employees com Google Workspace a consolidar para M365.
• [T] Migração M365 para Google Workspace (custo, simplicidade).
• [T] Híbrido permanente (multinacional ou compliance regional).
• [D] Migração selectiva de 1 equipa como piloto.
• [D] Migração após aquisição (consolidação de IT).
• [D] Migração em phases (1 departamento por mês).

4. Diagnóstico prévio

4.1 Inventário do ambiente actual

Google Workspace (origem):

• Número de utilizadores: Admin Console -> Users.
• Espaço total usado: Admin Console -> Reports -> Storage.
• Apps usadas: Gmail, Calendar, Drive, Meet, Chat, Sites.
• Grupos e shared drives: Admin Console -> Groups for Business.

Microsoft 365 (origem):

• Utilizadores activos: Entra admin center -> Users.
• Mailboxes totais: Get-Mailbox -ResultSize Unlimited | Measure-Object.
• OneDrive total: Get-SPOTenant | Select StorageUsage.
• Teams, SharePoint, Planner, Loop.

4.2 Validações técnicas ANTES de iniciar

• DNS: registos MX, SPF, DKIM, DMARC prontos para domínio de destino.
• OAuth 2.0: app registration criada com scopes correctos.
• Licenças: licenças M365 (ou Google Workspace) suficientes para todos os utilizadores.
• MFA: forçar MFA antes da migração (evita lockout).
• Ferramenta escolhida: BitTitan / Cloudiway / manual testado em 2-3 mailboxes.

5. Solução: 5 fases de migração

5.1 Fase 1: Pré-planeamento (2-4 semanas)

1. Definir scope: todos os utilizadores ou piloto de 5?
2. Escolher ferramenta: BitTitan (€3-7/mailbox), Cloudiway, manual.
3. Criar destination tenant: configurar Microsoft 365 ou Google Workspace.
4. Configurar DNS secundário (apontar MX para destination com TTL baixo 5min).
5. Inventário: mapear todos os utilizadores origem -> destino (incluindo aliases, grupos, DLs, recursos).
6. Comunicação: e-mail aos utilizadores + reuniões + IT helpdesk preparado.
7. Validar licenças: comprar M365 E3/E5 ou Workspace Enterprise.
8. Testar com 2-3 mailboxes (pessoas com tempo, IT team).

5.2 Fase 2: Configurar OAuth 2.0

#### Para Google (origem do caso 1, ou destino do caso 2):

1. Google Cloud Console -> https://console.cloud.google.com -> API & Services -> Credentials -> Create OAuth 2.0 Client ID.
2. Application type: Web application.
3. Authorized redirect URIs: https://app.bittitan.com/oauth/callback (ou URL do seu migration tool).
4. Scopes: https://mail.google.com/, https://www.googleapis.com/auth/calendar, https://www.googleapis.com/auth/drive.
5. OAuth consent screen: definir Scopes e Test users (adicionar todas as contas a migrar).
6. Criar Service Account com Domain-wide Delegation (se usar GAM ou Cloudiway).

#### Para Microsoft 365 (origem do caso 2, ou destino do caso 1):

1. Entra admin center -> App registrations -> New registration.
2. Name: "Migration-Tool" (ou nome da ferramenta).
3. Supported account types: "Accounts in this organizational directory only".
4. Redirect URI: https://app.bittitan.com/oauth/callback.
5. API permissions -> Microsoft Graph -> Application permissions:

– Mail.ReadWrite.All – Mail.Send – Calendars.ReadWrite.All – Contacts.ReadWrite.All – Files.ReadWrite.All

1. Grant admin consent for tenant.

5.3 Fase 3: Migração (1-3 dias para PME)

Comando típico (BitTitan):

# BitTitan PowerShell — criar Mailbox Migration Project
$project = New-MigrationProject -Name "Google-to-M365" -Type "Mailbox"

# Adicionar utilizadores (CSV: SourceEmail, DestinationEmail)
$users = Import-Csv "users.csv"
foreach ($u in $users) {
    Add-MigrationUser -Project $project -SourceEmail $u.SourceEmail -DestinationEmail $u.DestinationEmail
}

# Iniciar migração
Start-MigrationProject -Project $project -Schedule (Get-Date)

Manual PowerShell (para 1-5 mailboxes):

# Microsoft Graph — Connect
Connect-MgGraph -Scopes "Mail.ReadWrite", "Mail.Send", "Calendars.ReadWrite"

# IMAP migration (origem Google, destino M365)
$mailbox = Get-MgUser -UserId "[email protected]"
$params = @{
    SourceFolder = "Inbox"
    MigrationSource = $googleSourceId
    DestinationFolder = "Inbox"
}
New-MgUserMailFolder -UserId $mailbox.Id -DisplayName "Migrated-Inbox"
# ... usar IMAP via OAuth 2.0

5.4 Fase 4: Validação e coexistence

Após cutover inicial:

1. Validar emails enviados/recebidos em 5-10 mailboxes (especialmente pessoas com regras/assinaturas).
2. Validar calendar: eventos importados, recorrências, convidados.
3. Validar contactos: listas de distribuição, GAL.
4. Validar ficheiros: OneDrive, SharePoint (M365) ou Google Drive (Workspace).
5. Monitor durante 7 dias o fluxo de email (deve cair 0% após cutover).
6. Rollback preparado: manter origem activa durante 7-14 dias.

Hybrid coexistence (cenário 3):

• Google Workspace Add-on for Outlook (até 2026-12-31 free): sincroniza Calendar, Contacts.
• M365 + Google Workspace Directory Sync (Cloudiway, BitTitan): sincroniza utilizadores.
• Free/Busy lookups bidireccionais: Outlook consulta Google Calendar via iCal/Exchange.

5.5 Fase 5: Decommission (após 30-90 dias)

1. Manter backup do tenant origem durante 90 dias (cloud backup Veeam/Acronis).
2. Desactivar accounts origem (soft delete, 30 dias de retenção).
3. Apagar domínio origem (se aplicável).
4. Cancelar licenças origem.

6. BitTitan MigrationWiz (recomendado)

BitTitan é a ferramenta #1 para migração entre Google Workspace e Microsoft 365 (e entre outros 50+ sistemas).

6.1 Fluxo típico

1. Create project no BitTitan portal.
2. Connect source (Google Workspace via OAuth 2.0).
3. Connect destination (Microsoft 365 via Modern Auth).
4. Map users (CSV ou auto-discovery).
5. Run migration (1-3 horas por mailbox de 30 GB).
6. Delta sync (corre de hora em hora, 7-14 dias).
7. Final cutover com MX swap.

7. Cloudiway (alternativa europeia)

Cloudiway é uma empresa francesa com forte foco em compliance europeia (RGPD, ISO 27001). Plano Standard: €4/mailbox, Enterprise: €8/mailbox.

Vantagens vs BitTitan:

• Multi-tenant SaaS (sem infra para gerir).
• Google -> Microsoft e Microsoft -> Google em ambos sentidos.
• Migração de Teams com canais e mensagens (única ferramenta que faz).
• RGPD-compliant (data centers UE).

8. Migração manual PowerShell + GAM (grátis, complexo)

Para 5-10 mailboxes ou quando orçamento é limitado:

8.1 Google (origem) -> Microsoft 365 (destino) com IMAP + OAuth 2.0

Passo 1: gerar OAuth 2.0 access token em Google:

# Python — Google OAuth 2.0 flow
from google_auth_oauthlib.flow import InstalledAppFlow

flow = InstalledAppFlow.from_client_secrets_file(
    "client_secret.json",
    scopes=["https://mail.google.com/"]
)
creds = flow.run_local_server(port=0)
print(creds.token)  # access token

Passo 2: IMAP sync para M365:

import imaplib
import smtplib

# Conectar a Gmail via XOAUTH2
mail = imaplib.IMAP4_SSL("imap.gmail.com")
mail.authenticate("[email protected]", "\0".join(["[email protected]", oauth_token]))
mail.select("INBOX")

# Fetch e enviar para M365 via Microsoft Graph
typ, data = mail.search(None, "ALL")
for num in data[0].split():
    typ, msg_data = mail.fetch(num, "(RFC822)")
    # ... usar Microsoft Graph para upload para M365 mailbox

8.2 GAM (Google Apps Manager)

GAM é uma CLI para Google Workspace que suporta migração via IMAP:

# Export mailbox to PST-like format
gam user [email protected] show imap

# Migrar para IMAP destination (M365 IMAP endpoint)
gam user [email protected] imap imap.gmail.com username [email protected] oauth_token xxx \\
    destination imap.outlook.com username [email protected] password xxx

9. O que migra (e o que NÃO migra)

10. Verificação

10.1 Confirmar migração completa

# Microsoft 365 — comparar origens
$source = Get-Mailbox -ResultSize Unlimited -RecipientTypeDetails UserMailbox
$migrated = Get-MigrationUser | Where-Object { $_.Status -eq "Completed" }

Write-Host "Total mailboxes: $($source.Count)"
Write-Host "Migrated: $($migrated.Count)"

# Verificar % migration success
$success = Get-MigrationStatistics | Where-Object { $_.Status -eq "Completed" } | Measure-Object
Write-Host "Success rate: $($success.Count / $source.Count * 100)%"

10.2 Validar email flow

# Verificar MX records
dig MX empresa.pt

# Verificar SPF, DKIM, DMARC
dig TXT empresa.pt
dig TXT _dmarc.empresa.pt

10.3 Validar calendar

• Criar evento de teste no destino.
• Convidar 3 pessoas da origem (que ainda têm conta origem).
• Verificar se aparece no calendar origem (via free/busy).

10.4 Validar OAuth tokens

# Microsoft Graph — verificar token de app
curl -X GET "https://graph.microsoft.com/v1.0/users" \
    -H "Authorization: Bearer $access_token"

11. Outras causas comuns (10 problemas)

1. "Authentication failed" durante migração – Basic Auth foi desactivado em Set-2024 pela Google. Solução: usar OAuth 2.0 com XOAUTH2 ou ferramenta com Modern Auth (BitTitan, Cloudiway).
2. Calendar não importa recorrências complexas – recorrências com exceptions (reuniões canceladas, modificadas) podem perder. Solução: mapear manualmente ou usar Cloudiway.
3. Permissões de Drive/OneDrive não migram – partilhas com "Anyone with link" e "Domain" perdem-se. Solução: mapear ACLs manualmente ou usar Cloudiway SharePoint module.
4. Emails duplicados em delta sync – ferramenta corre delta sync e duplica emails que já foram migrados. Solução: verificar migration state antes de cada delta run; usar item ID para deduplicação.
5. OAuth consent flow bloqueado – admin não concedeu consent ao app registration. Solução: Grant admin consent no Entra admin center ou Workspace admin.
6. Bounces após cutover – DNS ainda aponta para origem. Solução: aguardar propagação DNS (24-48h com TTL 5min), ou forçar DNS flush local.
7. Shared mailboxes não migram – em M365, shared mailboxes têm tipo RecipientTypeDetails: SharedMailbox. Solução: converter para user mailbox antes, migrar, depois converter de volta.
8. Distribution lists (DLs) sem membros – ferramenta migra DL mas perde membros. Solução: usar M365 Exchange Admin para Add-Recipient em batch via CSV.
9. Time zone do calendar errado – eventos Google usam fuso origem do utilizador; Outlook assume fuso do PC. Solução: validar TimeZone em todos os eventos durante migração; ferramentas profissionais ajustam.
10. Apps Script e Power Automate param – workflows de Google Workspace Apps Script ou Power Automate M365 param de funcionar. Solução: inventário de automações ANTES de migrar; rewrite manual de Apps Script para Power Automate (ou vice-versa).

12. Como evitar (boas práticas)

1. Piloto de 5-10 mailboxes (IT team + champions) durante 2-4 semanas antes de expansão.
2. OAuth 2.0 obrigatório desde Set-2024 (Google) – validar que ferramentas suportam.
3. Inventário completo pré-migração: utilizadores, aliases, grupos, shared mailboxes, recursos, permissões, automações.
4. Backup de ambas as origens e destinos (Veeam for M365, Google Vault export) durante 90 dias.
5. Manter origem activa 7-14 dias após cutover para rollback rápido.
6. DNS TTL baixo (5min) durante 2 semanas antes do cutover MX.
7. Comunicação clara aos utilizadores: e-mail + reuniões + helpdesk staffed.
8. Testar email flow bidireccional após cutover (enviar de origem -> destino, e vice-versa).
9. Validar calendar com utilizadores reais (reuniões recorrentes, salas).
10. Decidir hybrid vs cutover com base em compliance regional (RGPD, NIS2, etc.).