Migrar do Google Workspace para o Microsoft 365

Uma migração pode parecer concluída no painel administrativo e falhar onde os colaboradores notam: desaparece uma caixa delegada, um disco partilhado chega à equipa errada, uma sala não pode ser reservada ou as ligações antigas deixam de ser úteis. Por isso, a forma mais segura de migrar do Google Workspace para o Microsoft 365 é tratar o projeto como uma transição empresarial, não uma cópia em massa.

O destino é mais do que aplicações substitutas. O Gmail dá lugar ao Exchange Online e Outlook; o Drive pessoal, ao OneDrive; e os discos partilhados exigem uma arquitetura deliberada no SharePoint ou Teams. As identidades Google passam para o Microsoft Entra ID, e os hábitos de etiquetas, partilha, reuniões e edição no browser têm de se adaptar a um novo modelo de trabalho.

Este guia segue uma sequência prática para PME e administradores de TI: levantar o ambiente, escolher subscrições, preparar identidades e coexistência, migrar correio e ficheiros, testar um piloto, alterar o DNS, validar e apoiar utilizadores. Como as ferramentas e experiências Microsoft evoluem, use a atual visão geral da migração da Microsoft como referência processual no início do projeto.

Índice

1. Porque migram as organizações e quando não devem fazê-lo
2. Mapa de cargas de trabalho do Google para a Microsoft
3. Fase 1: levantamento e caso de negócio
4. Fase 2: licenciamento e arquitetura de destino
5. Fase 3: identidade, domínios e coexistência
6. Fase 4: Gmail, calendário e contactos
7. Fase 5: Drive e discos partilhados
8. Piloto, transição, DNS e reversão
9. Validação e falhas frequentes
10. Adoção pelos utilizadores e gestão da mudança
11. Controlo de custos, riscos e prazos
12. Escolher o Microsoft 365 através da Licendi
13. Perguntas frequentes

Porque migram as organizações e quando não devem fazê-lo

As organizações raramente mudam porque uma suite vence todas as comparações. Mudam porque o Microsoft 365 se enquadra melhor no seu ambiente. A gestão de dispositivos Windows, as aplicações Office para computador, o Teams, o SharePoint, o Microsoft Entra ID e a segurança Microsoft podem formar um conjunto coerente numa empresa já assente nesta tecnologia. Uma fusão pode exigir um tenant único; um cliente ou regulador, controlos de dispositivos mais rigorosos; a área financeira, menos ferramentas sobrepostas. Os utilizadores podem também precisar de fluxos avançados no Excel, Word ou PowerPoint, pouco práticos numa colaboração centrada no browser.

Essas razões só valem se o destino resolver um problema definido. Uma empresa satisfeita com o Google Workspace, com pouca experiência Microsoft e dependente da colaboração Google pode sofrer perturbações sem benefício suficiente. O mesmo se aplica a projetos motivados pelo preço anunciado da subscrição, mas que ignoram o trabalho de migração, os custos de operar ambas as plataformas, a formação, as ferramentas de terceiros, as correções e o suporte adicional.

Adie a migração se o inventário da origem estiver incompleto, se aplicações essenciais dependerem de integrações Gmail ou Drive não testadas, se a responsabilidade pelas identidades for incerta ou se faltar um patrocinador executivo da mudança. Reconsidere também uma migração total quando retenções legais, dados regulados, discos partilhados complexos ou encaminhamento de correio crítico exigirem validação faseada. A decisão certa pode ser migrar por fases, manter coexistência limitada ou ainda não migrar.

Mapa de cargas de trabalho do Google para a Microsoft

A comparação direta esconde decisões importantes de arquitetura. Um disco partilhado do Google não deve tornar-se automaticamente num enorme site SharePoint, nem os espaços do Google Chat correspondem diretamente a todas as estruturas do Teams. Use a tabela como ponto de partida e desenhe o destino segundo a propriedade dos conteúdos e as formas de trabalho.

Fase 1: levantamento e caso de negócio

Comece por dados concretos. Exporte utilizadores, grupos, aliases, contas suspensas e arquivadas, caixas partilhadas ou acessos delegados, recursos, regras de encaminhamento, domínios, dispositivos móveis, aplicações OAuth externas e funções administrativas. Nos ficheiros, inventarie O meu disco, discos partilhados, proprietários, partilha externa, tipos e contagens de ficheiros, volume total, ficheiros grandes, caminhos profundos e conteúdo sem proprietário claro. Inclua a retenção ou retenção legal do Google Vault; uma ferramenta de migração não substitui a análise de gestão documental.

Crie depois um registo de dependências. Que aplicações enviam pelo Gmail? Que scanners, sites e sistemas usam SMTP? Que fluxos utilizam Apps Script, Formulários Google, macros, atalhos do Drive ou URL fixos? Que equipas partilham documentos com clientes? Classifique por semáforo: verde para cargas padrão, amarelo para riscos de conversão ou permissões e vermelho para dependências não suportadas ou críticas, que exigem plano próprio.

Converta o inventário num caso de negócio mensurável: consolidar identidades, implementar aplicações geridas, melhorar a conformidade dos dispositivos, reduzir ferramentas duplicadas ou uniformizar a governação documental. Crie uma referência para custos de subscrição, suporte, armazenamento, segurança e experiência dos utilizadores. Inclua a operação paralela das plataformas e uma reserva para correções. Não anuncie poupanças antes de definir a arquitetura de destino e os perfis.

Atribua responsáveis pela identidade, correio, ficheiros, segurança, DNS, conformidade, aplicações, comunicações e aceitação pelo negócio. O gestor do projeto coordena essas pessoas; não pode absorver silenciosamente todas as decisões. Registe desde já os critérios para avançar ou parar, antes que a pressão do prazo faça parecer aceitáveis provas insuficientes.

Fase 2: licenciamento e arquitetura de destino

O licenciamento deve seguir perfis, não cargos. Um trabalhador de primeira linha no browser, um analista financeiro que usa o Excel no computador e um administrador de dados sensíveis podem precisar de planos diferentes. Confirme se cada pessoa necessita de email alojado, aplicações Office para computador, gestão de dispositivos, proteção avançada contra ameaças, funções de conformidade ou apenas direitos sobre aplicações. Verifique ainda os pré-requisitos das ferramentas de migração e o armazenamento de destino; ter conta não licencia todos os serviços ou controlos de segurança.

Em muitas pequenas organizações, o Microsoft 365 Business Basic serve utilizadores focados em serviços cloud e aplicações Web ou móveis. O Business Standard acrescenta aplicações para computador a quem precisa do Office instalado. O Business Premium combina produtividade com recursos adicionais de identidade, gestão de dispositivos e segurança; consulte os atuais recursos do Business Premium, sem presumir que todos os controlos estão incluídos ou configurados. Os nomes, direitos e disponibilidade podem mudar; valide as condições comerciais antes da compra.

Desenhe o destino antes da cópia. Defina domínios aceites, nomes principais de utilizador, aliases, destinatários Exchange, aprovisionamento do OneDrive, arquitetura SharePoint, nomenclatura do Teams, proprietários de grupos, partilha externa, etiquetas de retenção, controlos de confidencialidade e funções administrativas. Separe ficheiros de trabalho pessoais de registos da equipa. Mapear todos os discos partilhados para o OneDrive de uma pessoa pode concluir a migração tecnicamente, mas criar um problema de propriedade no primeiro dia.

Aplique o menor privilégio. Quando possível, separe operadores de migração de administradores globais, proteja contas de emergência e licencie o piloto a tempo de configurar políticas e testar cargas. A atual sequência orientada de configuração do Google Workspace pode simplificar o início em pequenas empresas elegíveis, mas deve integrar a arquitetura, não substituí-la.

Fase 3: identidades, domínios, segurança e coexistência

O mapeamento de identidades liga correio e ficheiros. Antes da migração, normalize endereços principais, aliases, nomes duplicados e endereços de grupos. Decida se o nome principal de utilizador no Microsoft Entra coincidirá com o email principal. Crie um ficheiro controlado que associe cada utilizador e grupo Google a um único objeto de destino, incluindo antigos colaboradores cujos dados devam ser retidos. Teste carateres, utilizadores renomeados e vários domínios; endereços iguais não resolvem todos os casos.

A Microsoft disponibiliza o Google Identity Sync para tenants elegíveis. A documentação atual descreve a sincronização unidirecional de utilizadores e grupos do Google Workspace para o Microsoft 365, sujeita a condições de dimensão e mapeamento. Os utilizadores existentes no destino não são simplesmente substituídos; os arquivados diferem dos ativos ou suspensos; e membros externos ou com permissões personalizadas podem exigir tratamento próprio. Reveja a elegibilidade e os relatórios antes de preferir esta opção a scripts ou ferramentas externas.

Adicione e verifique o domínio no Microsoft 365 sem mover cedo o correio de produção. Antes de receber dados reais, configure MFA, Acesso Condicional quando licenciado, separação de funções, auditoria, proteção de dispositivos ou aplicações, partilha externa e contas de recuperação. Não aplique políticas não testadas a toda a empresa durante a transição. Use grupos-piloto e confirme que os administradores recuperam de bloqueios sem enfraquecer controlos.

A coexistência exige um fluxo de correio explícito. O método clássico do Exchange usa domínios de encaminhamento para os utilizadores trocarem mensagens entre plataformas durante lotes faseados. Os pré-requisitos de migração da Microsoft abrangem utilizadores de correio, subdomínios de encaminhamento e validação do reencaminhamento. A experiência consolidada do Microsoft 365 e a Migração Simplificada do Gmail podem automatizar passos diferentes; siga o método escolhido no tenant, sem misturar instruções de percursos distintos.

Mantenha uma única fonte para o estado das contas durante a coexistência. Defina onde criar utilizadores, alterar palavras-passe ou federação, desativar quem sai e gerir grupos. Suspenda mudanças de nome não essenciais perto da transição. Se as identidades divergirem durante o mapeamento de ficheiros e permissões, os erros podem parecer falhas aleatórias, embora resultem da governação.

Fase 4: migrar o Gmail, os calendários e os contactos

Escolha o método de correio após o levantamento. As ferramentas por lotes do Centro de Administração do Exchange transferem correio, regras, calendários e contactos. Permitem lotes faseados quando a empresa não pode mudar todos de uma vez. O Centro de Administração do Microsoft 365 também oferece uma experiência consolidada, enquanto a Migração Simplificada do Gmail usa uma aplicação Google Marketplace para orientar organizações menores. A disponibilidade e elegibilidade mudam; nenhum método é universal.

No método clássico, cumpra os pré-requisitos de conta de serviço, API, função administrativa, domínio de encaminhamento e destinatários. Crie lotes a partir de uma lista revista, não de uma folha improvisada no dia da transição. Pré-carregue o histórico enquanto os utilizadores continuam no Google. Analise erros de sincronização, corrija exceções e repita ou retome o processo quando permitido. Uma sincronização final perto da transição reduz a diferença, mas não permite prometer indisponibilidade zero.

A visão geral da migração automatizada por lotes documenta limites importantes. No percurso clássico, não migram calendários partilhados, cores de eventos, reservas de salas, definições de férias nem respostas automáticas; as etiquetas Gmail e alguns campos ou URL de contactos são limitados. São suportados até três endereços por contacto. O limite predefinido por mensagem é 35 MB, configurável até 150 MB. Trate estes pontos como testes e temas de comunicação, não como notas descobertas após a transição.

Reconstrua o que não migra corretamente. Crie caixas de sala e equipamento no Exchange, defina políticas de reserva, recrie calendários partilhados, documente delegações e peça a revisão das reuniões recorrentes. As etiquetas Gmail não equivalem às pastas ou categorias do Outlook, sobretudo com várias etiquetas por mensagem. Teste exemplos e explique o resultado antes de os utilizadores julgarem que faltam dados.

Siga o procedimento atual do Centro de Administração do Exchange para o percurso escolhido. Monitorize contagens, itens ignorados, causas das falhas e última sincronização. Quando exigido, desative ou ajuste as políticas de retenção e arquivo do destino: itens movidos ou eliminados por política podem parecer ausentes na verificação. Não elimine o correio Google perante um painel verde; preserve a origem durante o período acordado de validação e retenção.

Fase 5: migrar o Drive e os discos partilhados

A migração de ficheiros é arquitetura de informação disfarçada de cópia. O conteúdo pessoal passa normalmente de O meu disco para o OneDrive; os discos das equipas, para sites SharePoint, muitas vezes através do Teams. Antes das tarefas, defina limites dos sites, proprietários, membros, partilha externa, confidencialidade, retenção e nomes. Divida discos demasiado grandes quando departamentos, níveis de confidencialidade ou ciclos de vida distintos tornarem inadequado um só destino.

O Microsoft Migration Manager para Google Workspace segue uma sequência prática: ligar, analisar e avaliar, adicionar as origens prontas à lista de migração, rever os caminhos de destino, mapear identidades e, por fim, migrar e monitorizar. Use o fluxo completo quando a complexidade o justificar. Pode estar disponível uma experiência mais simples para tenants de PME elegíveis, mas uma interface simplificada não elimina a necessidade de saber onde cada conteúdo deve ficar.

Analise primeiro os relatórios. Procure ficheiros não suportados, itens restritos, caminhos longos, nomes inválidos, problemas de propriedade, itens grandes e volumes que ameacem o prazo. Reveja o destino em vez de aceitar todas as correspondências automáticas. Mapeie utilizadores e grupos antes das permissões e metadados. Teste um piloto com ficheiros nativos Google, pastas externas, permissões herdadas, grandes estruturas e conteúdo de antigos colaboradores.

A conversão altera o ficheiro, não só a localização. As atuais orientações da Microsoft sobre ficheiros não suportados indicam que Documentos, Folhas de cálculo e Apresentações Google são convertidos pela API Google Export em DOCX, XLSX e PPTX, mantendo-se os originais no Google. Os Desenhos tornam-se PNG. O Google Sites e o Google Maps não migram. Os atalhos são ignorados; ficheiros desorganizados ou órfãos não são analisados nem reportados. O comportamento de formulários e outros itens pode mudar: consulte a documentação ao criar o projeto.

A conversão pode alterar fórmulas, scripts, paginação, comentários, objetos incorporados e ligações. Teste documentos complexos e obtenha a aprovação dos seus proprietários. Verifique também permissões por amostragem: utilizadores internos, grupos, convidados, ligações anónimas e acessos personalizados não são traduzidos da mesma forma. Registe ficheiros que exijam exportação manual, reformulação, arquivo ou eliminação. O Migration Manager copia conteúdo, mas não remove os originais Google; desativar a origem é uma ação separada e governada.

Piloto, transição, DNS e reversão

Um piloto credível representa as dificuldades da empresa, não só utilizadores de TI cooperantes. Inclua departamentos diversos, executivos ou assistentes com delegações, trabalhadores remotos, utilizadores móveis, proprietários de discos partilhados, externos, pessoas que reservam salas e uma caixa de correio grande ou invulgar. Defina critérios de sucesso para fluxo de correio, início de sessão, Outlook, acesso móvel, reuniões, permissões, conversão e suporte.

Execute o piloto como em produção, com as subscrições, políticas, DNS e dispositivos previstos. Registe contagens na origem e destino, exclusões, aceitação e tempo de correção. Se 5% dos ficheiros exigirem tratamento manual, inclua esse trabalho no calendário; não declare sucesso apenas porque 95% foram copiados.

Antes da transição, reduza o TTL dos registos DNS se o fornecedor e a política o permitirem, com antecedência para o valor anterior expirar. Confirme o acesso ao alojamento DNS, documente os registos atuais e prepare os valores exatos do Centro de Administração do Microsoft 365. Reveja MX, Autodiscover, SPF, DKIM e DMARC. O SPF deve ser um único registo válido com todos os remetentes autorizados; adicionar um segundo TXT de SPF pode impedir a avaliação correta. Teste separadamente aplicações empresariais e gateways externos.

Ordene o evento: suspenda alterações evitáveis em contas e estruturas, conclua as passagens finais ou incrementais suportadas, verifique os lotes, altere os registos de correio, confirme entregas de entrada e saída, ative ou valide a segurança do domínio e liberte os utilizadores por vaga. A Microsoft coloca a ligação do domínio após a migração de correio e calendário porque alterar o MX é uma transição de serviço, não uma mera tarefa de preparação.

Escreva o plano de reversão antes de avançar. Defina quem pode parar a vaga, o último momento seguro para decidir, como restaurar MX ou encaminhamento, como tratar novo correio já entregue no Microsoft 365 e se é permitida edição nos dois sistemas. Reverter o DNS não é imediato devido às caches. Inverter o fluxo de correio também não reúne automaticamente dados criados dos dois lados. Perante muitas falhas, costuma ser mais seguro suspender a vaga seguinte e corrigir do que fazer regressar quem já trabalha com êxito.

Crie um canal de comando com responsáveis técnicos e empresariais. Registe alterações e horas. Prepare o guião do service desk, as comunicações aos utilizadores e os dados para escalar problemas aos fornecedores. Não marque a primeira grande vaga antes do processamento salarial, fecho trimestral, lançamento público ou feriado, salvo aceitação explícita do risco.

Lista de validação e falhas frequentes

Um estado de conclusão não equivale à aceitação pelo negócio. As orientações da Microsoft sobre ficheiros indicam que as tarefas podem aparecer como prontas ou concluídas mesmo quando itens não suportados falharam individualmente. Valide por carga de trabalho, utilizador e categoria de exceção.

• Identidade: os utilizadores iniciam sessão, a MFA funciona, as licenças estão atribuídas, os aliases são resolvidos, os grupos têm os proprietários certos e as contas desativadas mantêm-se inativas.
• Correio: funciona a entrega externa e interna; compreende-se o resultado de pastas ou etiquetas históricas; verificam-se delegados, aliases, regras e mensagens grandes.
• Calendário: testam-se reuniões recorrentes, fusos horários, organizadores, salas, calendários partilhados e sincronização móvel.
• Ficheiros: conciliam-se contagens e tamanhos considerando conversões conhecidas; aprovam-se proprietários, permissões, acessos externos e documentos de amostra.
• Clientes: Outlook, Teams, OneDrive e ativação do Office funcionam em dispositivos Windows, macOS e móveis representativos.
• Segurança: recebem-se eventos de auditoria, o Acesso Condicional funciona, aplicam-se controlos de partilha, testa-se a retenção e preserva-se o acesso de emergência.
• Operações: os processos de entrada, mudança e saída de colaboradores, restauro, suporte e escalamento funcionam na nova plataforma.

As falhas comuns são previsíveis: identidades sem correspondência perdem permissões; OneDrive ou sites não aprovisionados bloqueiam destinos; aliases antigos criam conflitos; permissões OAuth ou API expiram; certos caminhos ou ficheiros não são suportados; convidados externos ficam sem mapeamento; e políticas de retenção movem itens durante a verificação. Também é errado comparar contagens brutas sem considerar formatos Google convertidos ou atalhos ignorados. Classifique cada diferença como esperada, corrigida, aceite ou impeditiva.

Conserve provas: relatórios de migração, erros, ficheiros de mapeamento, registos DNS, aceitações e decisões de correção. Analise amostras de utilizadores de alto risco, não apenas médias. Mantenha acesso controlado ou só de leitura à origem durante a validação aprovada, respeitando requisitos legais e de segurança. Depois, remova aplicações de migração, contas de serviço, privilégios temporários, regras e domínios de encaminhamento quando já não forem necessários.

Adoção pelos utilizadores e gestão da mudança

Os utilizadores não precisam de conhecer todo o Microsoft 365, mas de saber como muda o trabalho diário. Dê orientações breves por função: pastas e categorias do Outlook face às etiquetas Gmail; partilha OneDrive face ao Drive; canais Teams face a conversas informais; propriedade de equipas no SharePoint; reuniões; reservas de salas; ficheiros offline; e pedidos de acesso. Mostre as diferenças que causam erros, não só as semelhanças que facilitam a formação.

Recrute promotores no piloto, dê aos gestores uma lista para a transição e divulgue um canal de suporte claro. Envie credenciais e instruções por um canal disponível mesmo se o email falhar. Ofereça sessões abertas nas primeiras vagas e agrupe perguntas por tema. Dúvidas repetidas informam o desenho: podem revelar nomes confusos, permissões em falta, sites demasiado complexos ou políticas não documentadas.

Meça a adoção após o lançamento: inícios de sessão, utilização, suporte, pedidos de partilha pendentes, crescimento do armazenamento e trabalho duplicado no Google. Não cancele a origem só porque terminou o prazo. Desative-a após validar dados, retenção, aceitação empresarial e pré-avisos contratuais.

Controlo dos custos, riscos e prazos realistas

Nenhum guia responsável promete duração ou preço fixos. Uma empresa com 50 utilizadores, Gmail padrão e Drives organizados pode ser mais simples do que um estúdio com 20 utilizadores, terabytes de multimédia, muita partilha externa e automações Apps Script. O prazo depende do volume e número de itens, limites das API, tamanho das caixas, conteúdo não suportado, qualidade das identidades, domínios, coexistência, retenções legais, preparação dos dispositivos, calendário empresarial e rapidez das decisões.

Controle custos com vagas e pontos de decisão. Quando adequado, licencie primeiro o piloto; não compre software antes de confirmar que as ferramentas nativas são insuficientes; e preveja subscrições duplicadas. Priorize correções pelo impacto empresarial, não por diferenças inofensivas nas contagens. Registe probabilidade, impacto, responsável, mitigação e condição de ativação de cada risco. Reserve margem para documentos complexos, permissões partilhadas e integrações.

Apresente o calendário por fases, não como promessa: levantamento; arquitetura e aquisição; preparação do tenant e identidades; piloto; correções; pré-cópia; vagas; validação; e desativação da origem. Termine cada fase com provas. Se o levantamento ampliar o âmbito, atualize o calendário. Reduzir testes não elimina o risco: transfere-o para os colaboradores e o service desk.

Escolha o plano Microsoft 365 adequado à migração

O marketplace da Licendi inclui planos Microsoft 365 e outras opções de licenciamento. Escolha subscrições segundo os utilizadores, aplicações, controlos de segurança e requisitos de conformidade do destino. Não presuma que todas são licenças perpétuas usadas e transferíveis: o Microsoft 365 usa geralmente subscrições contínuas, enquanto outro software do marketplace pode ter modelos e condições de transferência diferentes.

Conclusão

O sucesso de uma migração Google Workspace não se mede pela rapidez da saída dos dados. Mede-se pela capacidade de comunicar, encontrar informação, preservar registos e trabalhar em segurança no Microsoft 365 após desativar a origem. O levantamento e o mapeamento de identidades evitam a maioria das surpresas; os pilotos revelam as restantes enquanto a reversão é viável.

Use as ferramentas atuais da Microsoft para as cargas de trabalho que realmente suportam, documente todas as limitações conhecidas e permita que os responsáveis do negócio aceitem os documentos convertidos e as permissões. Com passagens faseadas, alterações controladas ao DNS, validação mensurável e formação orientada, a mudança pode ser previsível sem fingir que será perfeita ou invisível.

Perguntas frequentes

A Microsoft consegue migrar o Gmail, os calendários e os contactos?

Sim. As experiências de migração do Google Workspace disponibilizadas pela Microsoft conseguem transferir dados do Gmail e conteúdos suportados de calendários e contactos para o Exchange Online. Os dados que podem ser selecionados e a configuração exata dependem do método disponível no tenant. Os calendários partilhados, reservas de salas, cores de eventos, etiquetas do Gmail e alguns campos de contacto têm limitações no percurso automatizado clássico por lotes, pelo que deve testar e comunicar o âmbito atual do método escolhido.

O Google Drive é migrado diretamente para o OneDrive?

O conteúdo pessoal de O meu disco é normalmente mapeado para o OneDrive, enquanto os discos partilhados devem, em regra, ser mapeados para sites SharePoint governados ou associados ao Teams. O Migration Manager copia os conteúdos, metadados e permissões suportados de acordo com a configuração. A arquitetura de destino, o mapeamento de identidades e a correção de itens não suportados continuam a exigir decisões dos administradores.

Os ficheiros Google são convertidos em ficheiros do Microsoft Office?

Sim. O Migration Manager usa a API Google Export para converter Documentos, Folhas de cálculo e Apresentações Google em DOCX, XLSX e PPTX. A conversão pode alterar fórmulas, scripts, disposição, comentários, conteúdo incorporado ou ligações, pelo que os proprietários devem validar os ficheiros complexos. Os ficheiros Google originais permanecem na origem, a menos que a organização os remova posteriormente.

Todas as permissões e ligações de partilha continuarão a funcionar?

Não é possível dar essa garantia. O mapeamento de identidades pode preservar permissões suportadas, mas os acessos personalizados, utilizadores externos, ligações anónimas, atalhos, propriedade dos conteúdos e políticas do destino podem alterar o resultado. Teste padrões de partilha representativos, publique novas ligações quando necessário e mantenha um registo de correções para as exceções.

Quanto tempo de indisponibilidade deve exigir uma migração?

Não existe um valor universal. O pré-carregamento e a coexistência faseada podem reduzir a perturbação, mas a sincronização final, a propagação do DNS, a reconfiguração dos clientes e os problemas de suporte continuam a criar risco. Planeie uma janela de serviço controlada e evite prometer indisponibilidade zero.

O Google Workspace e o Microsoft 365 podem coexistir durante a migração?

Sim. Os métodos de correio faseados suportados podem usar domínios de encaminhamento e destinatários aprovisionados para que os utilizadores já migrados e ainda não migrados troquem mensagens. No entanto, a coexistência acrescenta complexidade: a responsabilidade pelas identidades, o reencaminhamento, as alterações aos grupos, o comportamento dos calendários e os limites do suporte têm de ser documentados e testados.

Quando pode ser cancelada a subscrição do Google Workspace?

Cancele apenas depois de validar o correio e os ficheiros, concluir a análise jurídica e de retenção, obter a aceitação dos responsáveis do negócio, terminar o período de reversão e remover ou exportar tudo o que não será migrado. Confirme primeiro as disposições relativas ao domínio e ao alojamento DNS. As ferramentas de migração copiam dados suportados; não tomam pela organização as decisões de desativação da origem.

Qual é o melhor plano Microsoft 365 depois do Google Workspace?

O melhor plano depende do perfil de cada utilizador. O Business Basic pode ser adequado a utilizadores centrados na nuvem, o Business Standard acrescenta aplicações de produtividade para ambiente de trabalho e o Business Premium oferece recursos adicionais de identidade, gestão de dispositivos e segurança. Confirme os direitos de utilização atuais, as necessidades de conformidade, os limites de utilizadores e os pré-requisitos de migração, em vez de escolher por defeito um único plano para todos.