A migração do Google Workspace para o Microsoft 365 exige executar sete blocos em sequência: inventário, provisionamento de identidades, escolha do método, preparação de domínio e DNS, cópia dos dados, janela de corte e validação. A ordem reduz falhas de acesso, roteamento de e-mail, permissões e continuidade durante a transição entre as plataformas.
A migração do Google Workspace para o Microsoft 365 começa antes da transferência de e-mails e arquivos. O primeiro passo é conhecer o ambiente de origem, identificar usuários, volumes, grupos, integrações e permissões e, a partir desse inventário, definir como identidades, dados e roteamento serão preparados no destino.
Cada etapa depende da anterior. As identidades precisam existir antes dos lotes, domínio e DNS devem seguir uma sequência controlada, e a mudança do MX ocorre somente quando as caixas estiverem preparadas. Durante a cópia, também é necessário considerar o que será convertido, o que exige mapeamento e o que não acompanha a migração.
Este guia parte de uma decisão já tomada e detalha a execução em sete blocos, da preparação ao aceite pós-migração. O foco é realizar a transição com ordem, critérios de validação e uma janela de corte planejada.
1. Inventário: o levantamento que define método, prazo e risco
Migrar sem inventário é migrar no escuro: o número de caixas define o método, e o volume por caixa define a janela. São quatro frentes, nenhuma delas a um clique no Google Admin Console.
Nas caixas, interessam quantidade, volume total, volume da maior caixa e quantas contas seguem ativas. Nos arquivos, separe o Google Drive pessoal dos Drives compartilhados: são objetos diferentes no destino, o pessoal vai para o OneDrive for Business e o compartilhado para um site do SharePoint Online. Arquivo sem dono definido não é varrido pela ferramenta.
A terceira frente costuma faltar na planilha: grupos, aliases, contas genéricas do tipo `financeiro@` ou `loja12@` e calendários de recurso, as salas de reunião. A quarta são as integrações que hoje autenticam ou disparam e-mail pelo domínio.
O que não vai junto entra aqui como decisão consciente. Google Sites e Google Maps não são migrados, conforme a documentação de arquivos não suportados. Caminho de destino acima de 400 caracteres também falha.
Inventário não é burocracia de abertura de projeto. É o que impede a surpresa de escopo no meio do caminho, e não se confunde com as diferenças entre as duas plataformas: aqui só se conta o que existe.
2. Identidade: os usuários existem antes de qualquer transferência
A ordem deste bloco é contraintuitiva para quem acha que migração começa copiando dado. Os usuários são provisionados no Microsoft Entra ID fora do processo de migração, antes do primeiro lote.
A documentação de pré-requisitos é direta: os destinatários precisam existir como mail users antes de o lote rodar, com o `ExternalEmailAddress` apontando para a origem e com o endereço primário coincidindo dos dois lados. Endereço primário divergente é o defeito clássico. Não gera erro na criação, gera item faltando no relatório.
E o `financeiro@`? Conta genérica pede decisão de arquitetura: costuma virar caixa compartilhada com delegação, não usuário provisionado.
Senha inicial e método de MFA entram no plano de comunicação desde já, porque o usuário precisa dos dois na janela de corte. E quem tem Active Directory local sincronizado precisa saber de antemão: o Microsoft Entra Connect pode precisar ser desativado para permitir que o processo converta esses usuários em caixas.
Identidade errada é o defeito que só aparece no dia do corte, quando não sobra tempo.
3. Escolha do método: lote único ou ondas com coexistência
Lote único ou ondas? Não existe método universal, existe critério. Três variáveis decidem: número de caixas, tolerância a indisponibilidade e prazo disponível.
A migração acontece em lotes, e o desenho em lotes existe para permitir que o projeto seja feito em estágios. Empresa com poucas caixas e volume baixo aceita um corte único no fim de semana. Acima disso vêm as ondas com coexistência: os departamentos migram em sequência, e os subdomínios de roteamento mantêm quem já migrou conversando com quem ainda não migrou.
A documentação da migração do Google Workspace descreve três caminhos para o e-mail: automatizado pelo Exchange admin center, manual pelo mesmo console e por Exchange Online PowerShell. Do lado do Google, o caminho automatizado exige projeto no Google Cloud Console, conta de serviço com chave e as APIs de Gmail, Agenda e Contatos habilitadas.
Existe um atalho, e ele cobra caro: a migração IMAP leva apenas e-mail, não leva agenda nem contatos.
Para os arquivos, a ferramenta é o Migration Manager, e o modo Lite vem habilitado por padrão em tenants com menos de 300 licenças quando o projeto é criado.
Sobre prazo, uma honestidade que o mercado evita: a documentação oficial não publica duração típica por número de caixas, e o que ela recomenda é rodar um lote de teste e medir. Prazo prometido sem lote de teste é chute com data, e o método escolhido define quantos dias a empresa sustenta dois ambientes pagos. Essa duração faz parte do escopo de uma consultoria de migração, e se decide aqui.
4. Domínio, DNS e MX: a sequência que não pode ser invertida
Aqui o erro fica visível para o cliente da empresa, não para o time de TI. São quatro passos, nenhum opcional.
Primeiro, reduza o TTL do registro MX para 3.600 segundos ou menos antes de começar. O Exchange Online só aceita TTL abaixo de 6 horas, ou 21.600 segundos, e TTL alto no dia da virada significa provedor de terceiro entregando no destino antigo horas depois do corte.
Segundo, verifique o domínio com o registro TXT indicado; enquanto ele não está pronto, a operação roda no domínio temporário `onmicrosoft.com`.
Terceiro, configure os subdomínios de roteamento dos dois lados, tipicamente `o365.` e `gsuite.`, registrados como domínio de alias de usuário. Domínio de roteamento não verificado impede a conclusão do processo.
Quarto, e só então, vire o registro MX. A regra está na documentação de registros DNS: adicione os usuários antes de atualizar o MX. O MX só muda depois que todos já existem no Microsoft 365 com caixa criada. Feita a troca, todo e-mail novo passa a ser entregue no Microsoft 365, e o que já havia chegado permanece no provedor anterior. O MX antigo é removido ou rebaixado na prioridade em seguida.
Falta o item que mais gente esquece: entregabilidade. O SPF precisa continuar sendo um registro TXT único, com `v=spf1 include:spf.protection.outlook.com -all` somado ao que já era legítimo, nunca um segundo registro paralelo. O DKIM usa os seletores `selector1` e `selector2._domainkey`, e o DMARC entra depois do SPF publicado.
E-mail que não chega ao cliente não é incidente de TI. É receita parada, e ninguém percebe no primeiro dia.
Executar essa sequência com a operação em pé é diferente de conhecê-la, e é o que o assessment de migração da Qualiserve dimensiona antes do primeiro lote.
5. Migração dos dados: e-mail, arquivos, agenda, contatos e grupos
Com identidade provisionada e DNS preparado, a cópia é a parte mecânica do projeto, e é onde aparecem os limites do que a ferramenta faz. E do que ela não faz.
E-mail, regras, agenda e contatos
O que vem do Gmail para o Exchange Online é e-mail e regras, Agenda e Contatos. As regras chegam desativadas por padrão, o que vira tarefa de reativação por usuário no dia seguinte. O limite padrão para mensagem individual é de 35 MB.
Antes de iniciar, desative políticas de MRM e de arquivamento na origem, recomendação explícita da Microsoft: mensagem arquivada aparece como faltando no relatório e produz perda percebida onde não houve perda. Escritório de advocacia com retenção longa sente isso primeiro.
Reserva de sala não é migrada, agenda compartilhada e cor de evento também não, e cada contato leva no máximo três endereços.
Drive, OneDrive e SharePoint em seis passos
O Migration Manager organiza os arquivos em seis passos, segundo a documentação da migração do Google Drive: conectar a origem, varrer e avaliar, copiar para a lista, revisar os destinos, mapear as identidades e migrar com monitoramento. O acesso fica em Configuração > Migração e importações.
O quinto passo decide se a segunda-feira vai ser tranquila. Com as identidades totalmente mapeadas, o conteúdo é recompartilhado automaticamente após a migração. Sem mapeamento, o arquivo chega ao destino sem a permissão que tinha na origem.
Dois limites merecem aviso antes, não depois. Links de compartilhamento externo não são recriados: precisam ser definidos manualmente no destino. Para Drive compartilhado, o grupo do Microsoft 365 correspondente precisa ser criado antes da migração.
O que muda de formato e o que fica para trás
Arquivos nativos do Google são convertidos: documentos viram `.docx`, planilhas viram `.xlsx` e apresentações viram `.pptx`, pela API de exportação do Google. Os originais no Google Drive permanecem intactos, porque a ferramenta copia, não move. Desenhos viram PNG, e formulários migram com destino designado. O histórico de versões é preservado.
Permissão não mapeada é equipe sem acesso ao arquivo compartilhado na segunda-feira. Isso é problema de operação, não de TI.
6. A janela de corte: comunicação, congelamento e reversão
A janela de corte é um evento coordenado, não um botão. Três coisas acontecem em paralelo: comunicação ao usuário, congelamento de mudanças na origem e o passe final de sincronização.
O congelamento existe por um motivo pouco divulgado: se alguém renomear uma pasta no meio do projeto, a sincronização incremental trata o item como objeto novo e duplica o conteúdo no destino. Arrumar as pastas durante a migração parece zelo. É trabalho dobrado.
O passe incremental trata o delta, o que mudou entre o primeiro passe e a virada. O lote precisa continuar rodando por pelo menos 72 horas depois da mudança do MX, porque a sincronização acontece uma vez por dia. Encerrar antes é abrir mão do e-mail que chegou na janela. Do lado de fora o prazo é o mesmo: pode levar até 72 horas para que os sistemas de clientes e parceiros reconheçam o novo registro MX.
Como a ferramenta copia e não apaga a origem, existe uma janela real de volta atrás, desde que MX antigo, contas e roteamento estejam documentados antes. Rollback não é excesso de zelo, é seguro de continuidade. Equipe interna ou quem executa a migração todo mês? Outra discussão.
7. Validação e pós-migração: aceite, reconfiguração e desligamento
Quando a migração termina? No aceite formal, não no fim da barra de progresso. O checklist mínimo tem seis itens verificáveis por usuário ou por amostra.
Envio e recebimento externo nos dois sentidos, agenda com compromissos futuros no lugar, contatos acessíveis, arquivo compartilhado abrindo para quem tinha permissão antes, Outlook reconfigurado no desktop e cliente móvel reconfigurado com o novo método de MFA.
O item do celular consome mais suporte que todos os outros: em empresa com equipe de campo, no agronegócio ou em logística, o gargalo da janela está aí, não na cópia dos dados.
O ambiente duplo é o custo que ninguém gosta de nomear, e um período pagando as duas plataformas é inevitável quando a migração é em ondas. O que se controla é a data em que ele termina.
O dia seguinte tem agenda própria: governança de Teams e SharePoint Online, política de retenção, backup e gestão dos dispositivos que acessam a plataforma Microsoft 365. Quem trata isso como fase separada acumula dívida operacional.
8. Os erros que mais aparecem e como cada um é evitado
Nenhum dos erros abaixo é exótico. Todos vêm da mesma causa: inverter a ordem dos blocos ou pular uma pré-condição.
| Erro | O que causa | Como evitar |
|---|---|---|
| Virar o MX antes de criar as caixas. | E-mail chega a destinatário inexistente | Provisionar as caixas antes da virada. |
| TTL alto no dia da virada. | Provedores entregam no destino antigo | Reduzir o TTL para 3.600 segundos. |
| Criar um segundo registro SPF. | Autenticação falha e mensagem cai em spam | Manter um registro TXT único. |
| Esquecer DKIM e DMARC. | Queda de entregabilidade após o corte | Publicar seletores e DMARC depois do SPF. |
| Não desativar arquivamento na origem. | Mensagens marcadas como faltando no relatório | Desativar MRM e arquivamento antes do lote. |
| Reorganizar pastas durante o projeto. | Conteúdo duplicado no destino | Congelar mudanças até o aceite. |
| Não mapear identidades antes do Drive. | Arquivo sem a permissão original | Concluir o mapeamento antes da cópia. |
| Supor que link externo continua válido. | Parceiro sem acesso ao arquivo | Recriar os compartilhamentos à mão. |
| Encerrar o lote antes de 72 horas. | Perda do delta pós-corte | Manter o lote ativo por esse período. |
Nenhum deles é caro de prevenir. Todos são caros de corrigir depois do corte.
Como conduzimos essa migração na Qualiserve
A migração do Google Workspace para o Microsoft 365 é a oferta estratégica declarada da Qualiserve, com metodologia de transição transparente ao usuário e sem parar a operação. Não vendemos a plataforma. Entregamos o projeto que faz a virada acontecer sem que o comercial descubra pelo telefone que o e-mail parou.
O direito de falar em janela de corte e em plano de reversão vem de operar ambiente em produção todo dia: 20 anos de mercado, a virada de 2019 de break-fix para serviços gerenciados e um NOC próprio que monitora mais de 20.000 dispositivos, com mais de 50.000 usuários atendidos.
Perguntas frequentes sobre a migração para o Microsoft 365
As dúvidas abaixo se repetem em quase todo projeto, e as respostas seguem a documentação oficial.
Quanto tempo demora a migração do Google Workspace para o Microsoft 365?
Não existe prazo publicado por número de caixas, e quem promete um está estimando sem base documental. A documentação recomenda rodar um lote de teste e medir a vazão real do ambiente, porque volume por caixa, quantidade de arquivos e cota da conta de serviço mudam o resultado do projeto.
É possível migrar sem parar o e-mail da empresa?
Sim, e é para isso que existe a migração em ondas com coexistência. Os subdomínios de roteamento mantêm quem já migrou trocando mensagem com quem ainda não migrou, e o corte do MX acontece com todas as caixas já criadas no destino. O usuário percebe a troca do cliente de e-mail, não uma interrupção.
O que não é migrado do Google Workspace?
Google Sites e Google Maps não são migrados. Também ficam para trás reservas de sala, agendas compartilhadas, cores de evento e os links de compartilhamento externo, que precisam ser recriados manualmente no destino. Mensagem acima do limite padrão de 35 MB não passa, e cada contato leva três endereços.
Os arquivos do Google Docs e do Sheets continuam funcionando depois da migração?
Sim, em formato convertido. Documentos, planilhas e apresentações viram `.docx`, `.xlsx` e `.pptx` pela API de exportação do Google, e os originais no Google Drive permanecem intactos, já que a ferramenta copia em vez de mover. Desenhos são convertidos em PNG e formulários migram com destino designado.
O que acontece com os arquivos do Drive compartilhado?
O conteúdo vai para um site do SharePoint Online, e o grupo do Microsoft 365 correspondente precisa ser criado antes da migração. As permissões só são recriadas automaticamente quando o mapeamento de identidades está completo, então esse passo antecede a cópia. Sem ele, o arquivo chega ao destino sem quem tinha acesso.
Em que momento o registro MX deve ser alterado?
Depois que todos os usuários já existem no Microsoft 365 com caixa criada, nunca antes. A documentação orienta adicionar os usuários antes de atualizar o registro, e a razão é direta: com o MX virado, todo e-mail novo passa a ser entregue no destino. O TTL precisa estar reduzido antes disso.
Preciso manter as duas plataformas ativas ao mesmo tempo?
Por um período, sim, e fingir o contrário atrapalha o planejamento. Migração em ondas implica coexistência, então existe uma janela em que a empresa sustenta os dois ambientes. O que se controla é a duração: data de desligamento no plano, responsável nomeado e critério de aceite cumprido antes de encerrar a origem.
O que separa uma migração invisível de uma parada de operação
Nenhum dos sete blocos é difícil isoladamente. O que derruba projeto de migração é a ordem: identidade provisionada depois do MX, corte executado sem inventário, DNS trocado antes de as caixas existirem. A ferramenta nativa cobre a cópia dos dados; ela não cobre inventário, mapeamento de identidade, sequência de DNS, comunicação e reversão.
Executar na sequência certa transforma a migração em evento invisível para quem usa o e-mail, e devolve uma data para encerrar o ambiente duplo.
Se a sua empresa já decidiu migrar, levante o ambiente antes de tocar em qualquer registro. Prefere falar direto? WhatsApp (11) 4941-1500.
