Como migrar o e-mail da empresa para o Microsoft 365

Migrar o e-mail da empresa para o Microsoft 365 não é apenas copiar mensagens. O projeto envolve domínio, DNS, contas, licenças, senhas, aliases, grupos, dispositivos, sistemas que enviam e-mail e regras de segurança. Quando essas dependências são ignoradas, a troca pode causar mensagens perdidas, usuários sem acesso e falhas em aplicações.

Uma migração bem planejada prepara o ambiente novo enquanto o serviço antigo continua funcionando. As mensagens são transferidas previamente, um grupo piloto valida o processo e o registro MX só é alterado quando as caixas estão prontas. Depois da troca, a equipe acompanha o fluxo e mantém o provedor anterior ativo até confirmar que nada importante ficou para trás.

Este guia explica como organizar a migração para o Microsoft 365, escolher a forma de transferência, configurar o domínio e reduzir interrupções.

O que muda ao migrar para o Microsoft 365?

O endereço pode continuar igual, como nome@empresa.com.br. O que muda é o serviço responsável por receber, armazenar e entregar as mensagens. O Exchange Online passa a hospedar as caixas, enquanto o Microsoft 365 fornece administração de usuários, políticas, Outlook na Web e integração com outros recursos contratados.

Na prática, a migração precisa mover ou recriar:

• caixas de e-mail e suas pastas;
• aliases e endereços secundários;
• caixas compartilhadas, como financeiro@ e contato@;
• grupos e listas de distribuição;
• permissões de acesso e delegação;
• regras de encaminhamento;
• contatos e calendários, conforme o método;
• assinaturas e configurações locais, quando aplicável;
• integrações de ERP, CRM, site, impressoras e sistemas;
• registros DNS usados no recebimento e na autenticação do e-mail.

O projeto também é uma oportunidade para eliminar contas antigas, endereços duplicados, encaminhamentos sem responsável e acessos que não deveriam continuar ativos.

Antes de começar: faça um inventário

Comece listando todas as pessoas e recursos que usam o domínio. Não olhe apenas para as caixas mais conhecidas.

O inventário deve registrar:

• nome e endereço de cada usuário;
• tamanho da caixa e quantidade aproximada de itens;
• aliases;
• caixas compartilhadas;
• listas de distribuição e seus membros;
• calendários compartilhados;
• delegações, como acesso de assistente à agenda de gestor;
• encaminhamentos internos e externos;
• regras importantes;
• arquivos PST locais;
• contas suspensas ou de ex-colaboradores;
• sistemas e equipamentos que enviam e-mail;
• responsável pelo domínio e pelo DNS;
• dispositivos usados por cada pessoa;
• exigências de retenção, auditoria ou LGPD.

Inclua site, formulário de contato, ERP, CRM, emissão de notas, monitoramento, scanner, impressora, central de atendimento e qualquer aplicação que envie mensagens com o domínio da empresa. Esses sistemas podem parar de entregar e-mails se SPF, autenticação ou conectores forem alterados sem planejamento.

Também confirme quem possui acesso administrativo ao registrador do domínio e ao provedor de DNS. Descobrir no dia da troca que a credencial pertence a um ex-fornecedor é uma das formas mais comuns de atrasar o projeto.

Escolha a licença e prepare o tenant

Antes de transferir dados, a empresa precisa criar e configurar seu ambiente Microsoft 365, também chamado de tenant. A licença deve atender ao uso de e-mail, espaço da caixa, aplicativos, segurança, arquivamento e requisitos de conformidade.

Planos com nomes parecidos podem oferecer recursos diferentes. Compare pelo menos:

• Exchange Online e tamanho da caixa;
• aplicativos de desktop ou apenas versões web;
• Teams, OneDrive e SharePoint;
• arquivamento e retenção;
• recursos de proteção contra phishing e malware;
• gestão de dispositivos;
• identidade e políticas de acesso;
• necessidade de backup adicional.

Depois, crie os usuários, atribua licenças e monte aliases, grupos e caixas compartilhadas. Não altere o MX ainda. Segundo a documentação da Microsoft para domínios personalizados, as caixas devem existir antes de apontar o recebimento para o Microsoft 365.

Adicione e verifique o domínio sem trocar o e-mail

O domínio pode ser adicionado ao Microsoft 365 enquanto o provedor antigo continua recebendo mensagens. Para confirmar a propriedade, a Microsoft solicita normalmente um registro TXT no DNS.

Essa verificação não precisa mudar o fluxo de e-mail. Ela apenas prova que a empresa controla o domínio e permite preparar usuários e endereços no tenant.

O processo geral é:

1. adicionar o domínio no Centro de Administração do Microsoft 365;
2. criar o registro TXT de verificação no provedor de DNS;
3. aguardar a propagação e concluir a validação;
4. criar usuários, caixas, grupos e aliases;
5. manter o MX antigo até a etapa de corte.

Alguns registradores suportam Domain Connect e conseguem criar registros automaticamente. Mesmo nesse caso, revise o que será alterado. Uma mudança automática de MX antes da hora pode direcionar mensagens para caixas ainda incompletas.

Escolha o método de migração

O método depende do serviço atual, da quantidade de usuários e dos dados que precisam ser preservados.

Migração IMAP

É comum quando a origem é uma hospedagem de e-mail, servidor compatível com IMAP ou serviço sem integração mais completa. O Microsoft 365 conecta-se às caixas antigas e copia mensagens e pastas.

Limitação importante: segundo a documentação oficial sobre migração IMAP, esse método transfere e-mails, mas não migra contatos, calendários e tarefas. Esses dados precisam de outro procedimento.

A Microsoft também documenta limites de quantidade de itens e tamanho de mensagem para a ferramenta IMAP. Como esses limites podem mudar, devem ser conferidos antes do projeto, especialmente em caixas antigas ou muito grandes.

Migração do Google Workspace

Existem procedimentos específicos para mover dados do Google Workspace ao Microsoft 365. Dependendo da abordagem escolhida, podem ser migrados e-mail, calendário e contatos, com configuração de permissões e APIs no ambiente Google.

O inventário precisa incluir grupos, aliases, agendas compartilhadas, Google Vault e formas de autenticação. Não presuma que tudo o que aparece no Gmail será transferido da mesma maneira.

Migração de Exchange Server

Ambientes com Exchange local podem usar migração cutover, Express ou híbrida, conforme versão, tamanho e estratégia. A visão geral de métodos de migração da Microsoft ajuda a diferenciar os cenários.

Projetos híbridos mantêm integração temporária entre ambiente local e Microsoft 365, permitindo mover caixas em lotes. São mais complexos, mas podem ser adequados quando a empresa não consegue migrar todos os usuários de uma vez.

Importação por PST

Arquivos PST podem ser usados em situações específicas, como dados armazenados somente no computador ou pequenas migrações manuais. Porém, depender de exportação e importação usuário por usuário aumenta trabalho, risco de duplicidade e dificuldade de conferência.

Quando existem muitos PSTs ou arquivos grandes, deve-se avaliar o serviço de importação da Microsoft ou uma ferramenta especializada.

Planeje a transferência das mensagens

Sempre que o método permitir, faça uma pré-migração. Ela copia o histórico enquanto usuários continuam trabalhando no serviço antigo. No dia da troca, resta transferir o volume recente e mudar o destino das novas mensagens.

Um plano prático separa as caixas em lotes:

• piloto interno;
• gestores e áreas críticas;
• usuários comuns;
• caixas compartilhadas;
• contas especiais e integrações.

Para cada lote, registre volume na origem, quantidade migrada, falhas, itens ignorados e horário da última sincronização. Caixas muito grandes podem ser iniciadas antes, mas precisam de atenção especial para limites, arquivamento e desempenho.

Não apague dados da origem durante a transferência. Políticas automáticas de arquivamento ou exclusão também devem ser avaliadas, pois podem mover itens enquanto a ferramenta tenta conferi-los.

Faça um piloto antes de envolver toda a empresa

Escolha usuários que representem situações diferentes:

• uma caixa pequena;
• uma caixa grande e antiga;
• usuário com calendário e contatos;
• pessoa com celular e Outlook no computador;
• usuário que acessa caixa compartilhada;
• gestor com delegação;
• sistema que envia mensagens pelo domínio.

O piloto deve validar login, envio, recebimento, pastas, busca, calendário, contatos, aliases, compartilhamentos e dispositivos. Também precisa medir quanto tempo suporte leva para preparar cada estação.

Problemas encontrados nessa fase viram checklist para o restante da empresa. Migrar cinco usuários e corrigir o método é muito menos arriscado que descobrir a mesma falha depois de trocar cem contas.

Prepare usuários, acessos e segurança

Senhas do provedor antigo normalmente não são migradas. Cada pessoa passa a usar uma identidade no Microsoft 365. Antes do corte, defina como as credenciais iniciais serão entregues e como a identidade será confirmada.

Cuidados recomendados:

• usar contas individuais, nunca login compartilhado;
• ativar autenticação multifator;
• manter contas administrativas separadas do uso diário;
• revisar administradores globais;
• configurar métodos de recuperação de acesso;
• limitar protocolos e autenticação legada;
• criar grupos e permissões conforme função;
• conferir caixas compartilhadas e delegações;
• documentar processo de entrada e saída de colaboradores;
• testar políticas em grupo piloto antes da aplicação geral.

MFA deve ser planejado junto com a comunicação. Se todos forem obrigados a cadastrar o segundo fator no primeiro acesso sem orientação, a fila de suporte cresce justamente durante a migração.

Envie instruções antes da troca com data, horário, nova forma de login, procedimento para celular, canal de suporte e o que o usuário deve conferir. Evite distribuir senhas em grupos ou mensagens abertas.

Prepare o DNS e a autenticação do domínio

DNS informa à internet onde entregar mensagens e quais serviços podem enviar em nome do domínio. Os principais registros são:

• MX: direciona mensagens recebidas para o Exchange Online;
• Autodiscover: ajuda Outlook e dispositivos a localizar o serviço;
• SPF: lista fontes autorizadas a enviar em nome do domínio;
• DKIM: adiciona assinatura criptográfica às mensagens;
• DMARC: define política e relatórios para falhas de autenticação.

O Centro de Administração fornece os valores específicos do tenant. Não copie registros de um tutorial sem conferir o domínio e o ambiente.

SPF exige cuidado especial. Só pode existir um registro SPF por domínio. Se site, ERP, CRM ou plataforma de marketing também enviam mensagens, suas fontes precisam ser combinadas corretamente. Criar um segundo registro SPF pode invalidar a configuração.

A documentação de SPF da Microsoft explica como autorizar o Microsoft 365 e tratar outras origens. DKIM e DMARC devem completar a proteção, mas a política DMARC não deve ser endurecida sem observar relatórios e confirmar todas as fontes legítimas.

Reduza o TTL antes da troca

TTL define por quanto tempo resolvedores podem guardar um registro DNS em cache. Reduzir o TTL do MX antes do corte pode acelerar a propagação da mudança.

Faça isso com antecedência suficiente para o valor antigo expirar, normalmente pelo menos 24 a 48 horas antes, conforme o provedor. Diminuir o TTL cinco minutos antes não elimina caches que já guardaram a configuração anterior.

Depois que o ambiente estiver estável, o TTL pode voltar a um valor normal. Registre os valores anteriores para facilitar revisão ou contingência.

Dia da migração: como fazer o corte

Escolha período de menor movimento, mas garanta equipe disponível para testar e atender usuários. Uma madrugada sem suporte no início do expediente pode ser pior que uma troca organizada no fim do dia.

Checklist de corte:

1. confirmar que usuários, licenças e caixas estão ativos;
2. verificar resultado da pré-migração;
3. executar última sincronização disponível;
4. registrar configuração DNS atual;
5. alterar MX e demais registros planejados;
6. confirmar propagação em resolvedores diferentes;
7. testar envio externo para o domínio;
8. testar envio do Microsoft 365 para destinatários externos;
9. validar SPF, DKIM e DMARC;
10. conferir filas, mensagens devolvidas e alertas;
11. orientar usuários a entrar no novo ambiente;
12. manter serviço antigo acessível durante a estabilização.

Durante a propagação, algumas mensagens podem chegar ao provedor antigo e outras ao Microsoft 365. Por isso, não desative a origem imediatamente. Continue sincronizando quando o método permitir ou monitore as duas caixas até o fluxo convergir.

Tenha plano de contingência com responsáveis, credenciais, registros anteriores e critérios claros para interromper ou reverter uma etapa. Mudanças de DNS devem ser feitas por pessoa autorizada e conferidas por outra quando possível.

Configure Outlook, celulares e aplicações

Depois do corte, Outlook pode localizar o novo serviço por Autodiscover, mas alguns computadores exigem um novo perfil. Celulares podem precisar remover a conta antiga e adicionar a conta corporativa novamente.

Prepare instruções para:

• Outlook no Windows e no macOS;
• Outlook na Web;
• aplicativo Outlook em Android e iPhone;
• calendários e contatos;
• caixas compartilhadas;
• assinaturas;
• aplicativos que usam SMTP;
• multifator e recuperação de senha.

Sistemas, scanners e impressoras merecem tratamento separado. Aplicações antigas podem usar autenticação incompatível ou depender de IP liberado. Em vez de enfraquecer a segurança geral para fazê-las funcionar, avalie conector, retransmissão SMTP apropriada, conta dedicada ou atualização do sistema.

Como validar se a migração terminou corretamente

Não use apenas a mensagem “lote concluído” como prova. Compare origem e destino por amostragem e pelos relatórios disponíveis.

Verifique:

• tamanho das caixas;
• quantidade de itens e pastas;
• falhas e itens ignorados;
• mensagens recentes e antigas;
• anexos importantes;
• calendários e contatos, quando incluídos;
• aliases e grupos;
• permissões e caixas compartilhadas;
• regras e encaminhamentos autorizados;
• envio e recebimento externo;
• entregabilidade em diferentes provedores;
• sistemas que enviam e-mail;
• acesso por computador, navegador e celular.

Registre as exceções e peça validação dos responsáveis de cada área. Financeiro, comercial e atendimento costumam conhecer mensagens e caixas que não aparecem no checklist técnico.

Quando desligar o provedor antigo?

Somente depois de confirmar que:

• todo conteúdo previsto foi transferido;
• mensagens deixaram de chegar na origem;
• usuários e sistemas usam o Microsoft 365;
• contatos, calendários e PSTs receberam tratamento;
• retenção necessária foi preservada;
• não existem falhas pendentes;
• há cópia ou exportação dos dados que precisam ser mantidos;
• o cancelamento e a eliminação dos dados estão documentados.

O prazo varia conforme contrato, volume e risco. Manter a origem por alguns dias ou semanas pode facilitar conferência, desde que acessos permaneçam protegidos e o custo esteja previsto.

Antes do cancelamento, entenda como o antigo provedor elimina as caixas e se há prazo de recuperação. Depois da exclusão, um erro de inventário pode ser irreversível.

12 cuidados para reduzir interrupções

1. Garantir acesso ao domínio e DNS antes de marcar a data.
2. Inventariar caixas, aliases, grupos, delegações e sistemas remetentes.
3. Criar e licenciar usuários antes de alterar o MX.
4. Fazer pré-migração do histórico sempre que possível.
5. Testar com um grupo piloto representativo.
6. Reduzir TTL com antecedência, não no momento do corte.
7. Programar a troca em período de menor movimento com suporte disponível.
8. Manter o provedor antigo ativo durante a propagação e conferência.
9. Comunicar usuários com instruções simples e canal de ajuda.
10. Testar envio, recebimento e autenticação com domínios externos.
11. Monitorar falhas, devoluções e itens não migrados.
12. Só cancelar a origem após validação técnica e das áreas de negócio.

Não é possível prometer ausência total de impacto em qualquer ambiente. O objetivo do planejamento é reduzir a janela de transição, antecipar falhas e impedir que uma ocorrência pequena se transforme em parada prolongada.

Erros comuns na migração de e-mail

Os problemas mais frequentes incluem:

• trocar MX antes de criar todas as caixas;
• esquecer endereços usados por sistemas;
• acreditar que IMAP transfere agenda e contatos;
• não migrar aliases e caixas compartilhadas;
• alterar SPF sem incluir outras fontes legítimas;
• criar dois registros SPF;
• aplicar MFA sem orientar usuários;
• cancelar a hospedagem antiga no mesmo dia;
• ignorar arquivos PST locais;
• não validar itens com erro;
• misturar contas pessoais e corporativas;
• não definir responsável pela administração futura.

Perguntas frequentes

Quanto tempo leva uma migração para Microsoft 365?

Pode variar de algumas horas a várias semanas. Quantidade e tamanho das caixas, velocidade da origem, limite de conexões, método e necessidade de migrar calendários ou arquivos locais influenciam o prazo. A transferência prévia reduz pressão no dia do corte.

O endereço de e-mail precisa mudar?

Não. A empresa pode adicionar o domínio atual ao Microsoft 365 e manter os endereços. O DNS passa a apontar o recebimento para o Exchange Online.

Mensagens antigas são transferidas?

Sim, desde que estejam acessíveis na origem e sejam compatíveis com o método escolhido. Limites de item, falhas, arquivos locais e políticas de arquivamento precisam ser analisados.

IMAP migra contatos e calendário?

Não. A migração IMAP da Microsoft copia itens das pastas de e-mail, mas não contatos, calendários e tarefas. Esses dados exigem procedimento complementar.

A empresa ficará sem e-mail?

Planejamento correto pode reduzir bastante a interrupção. Pré-cópia, piloto, TTL ajustado e manutenção do serviço antigo permitem atravessar a propagação do DNS com menor risco. Ainda assim, a janela deve ter suporte e plano de contingência.

Microsoft 365 já é backup?

Microsoft 365 oferece disponibilidade, retenção e recursos de recuperação, mas isso não substitui automaticamente uma estratégia de backup adequada ao negócio. Veja por que OneDrive e SharePoint não devem ser tratados como único backup.

Migração de Microsoft 365 com planejamento e suporte

A Mira Sistemas ajuda empresas a planejar e executar migrações de e-mail para o Microsoft 365. O trabalho pode incluir inventário, criação do tenant, licenciamento, domínio, DNS, transferência de mensagens, configuração de Outlook e celulares, MFA, políticas de segurança, testes e documentação.

Também apoiamos a administração posterior de usuários, grupos, caixas compartilhadas, permissões, backup e integrações. Conheça nossa atuação com Microsoft 365 para empresas.

Sua empresa quer migrar o e-mail sem improvisar no dia da troca? Fale com a Mira Sistemas. Avaliamos o serviço atual, volume de dados, domínio e dependências para definir método, cronograma e plano de transição.