Exchange 2016 e 2019 sem suporte: como migrar para o Microsoft 365

📚 Continue aprendendo sobre este tema:

Fora de suporte não é fora do ar

Nenhum servidor Exchange desligou sozinho em 15 de outubro de 2025. É por isso que o tema é perigoso: o e-mail continua entrando e saindo, os usuários não reclamam, e a empresa segue meses sem perceber que passou a operar um serviço crítico sem rede de proteção.

O que muda com o fim do suporte é o seguinte:

Sem correção de segurança. Vulnerabilidade nova descoberta no produto não vira mais atualização. O servidor fica exposto de forma permanente.
Sem suporte do fabricante. Se algo quebrar em um cenário complexo, não existe mais um canal oficial para escalar o problema.
Efeito em auditoria e contrato. Cliente grande, seguradora de risco cibernético e auditoria de compliance perguntam se a empresa roda software fora de suporte. A resposta afirmativa costuma virar ressalva.

Servidor de e-mail é alvo preferido porque fica exposto à internet por definição e concentra dado sensível: contrato, proposta, dado pessoal de cliente, comunicação com banco. Vale ler nosso material sobre por que empresas médias também são alvo de ataque antes de tratar isso como assunto de baixa prioridade.

As rotas possíveis quando o Exchange sai de suporte

Existem basicamente três caminhos. A escolha depende menos de tecnologia e mais de restrição regulatória, orçamento e quanto a empresa quer continuar operando servidor próprio.

Rota	O que exige	Quando faz sentido	O que pesa contra
Migrar as caixas para o Microsoft 365	Licenciamento por usuário, preparo de identidade, migração de dados, corte de DNS	Maioria das médias empresas, principalmente as que já usam Office e Teams	Depende de link de internet estável e exige repensar backup e retenção
Continuar com servidor de e-mail próprio, em versão suportada	Projeto de servidor novo, licenças, migração interna e manutenção contínua	Exigência contratual ou regulatória de manter o dado dentro de um ambiente específico	Custo recorrente de operação, patch e disponibilidade continua com você
Modelo híbrido, parte na nuvem e parte local	Coexistência de diretório, roteamento de mensagens entre os dois lados	Migração longa, com muitos usuários ou sistemas legados que enviam e-mail	É o cenário mais complexo de operar. Só deve ser destino final se houver motivo real

Para a maioria das empresas de porte médio em São Paulo, o híbrido é uma fase de transição, não um destino. Ele existe para permitir que a migração aconteça em ondas, sem parar a operação. Se o projeto terminar e o servidor local continuar de pé sem função clara, você ficou com o pior dos dois mundos: pagou a nuvem e continuou mantendo servidor.

As fases de uma migração para o Microsoft 365

Migração de e-mail é um projeto com ordem obrigatória. Cada fase depende da anterior. Pular uma delas é a causa mais comum de mensagem perdida durante o corte.

Fase 1: inventário do que existe hoje

Antes de tocar em qualquer coisa, você precisa saber o que o servidor atual carrega. Levante e registre:

Quantidade de caixas de usuário, caixas compartilhadas, salas e recursos.
Volume total de dados e tamanho das maiores caixas, porque isso define quanto tempo a cópia leva.
Listas de distribuição e grupos, com seus donos.
Regras de encaminhamento e de fora do escritório, que se perdem com facilidade.
Todo sistema que envia e-mail pelo servidor: ERP, sistema de nota fiscal, impressora multifuncional, monitoramento, site.
Aparelhos e clientes de e-mail em uso, incluindo celulares e versões antigas de Outlook.

O último item da lista é o que mais derruba projeto. A migração acontece, o e-mail humano funciona, e três dias depois descobre-se que o sistema de faturamento parou de enviar boleto porque apontava para o servidor antigo. Se sua empresa ainda não mantém um levantamento vivo de ativos, comece pelo nosso guia de como fazer inventário de TI.

Fase 2: identidade e domínio

Antes de mover uma única mensagem, a nuvem precisa saber quem são seus usuários e que o domínio é seu. Nesta fase entram a verificação do domínio, a decisão sobre como as contas serão criadas e sincronizadas, e a definição de senha e autenticação.

É o momento certo para ativar autenticação multifator. Migrar caixas para a nuvem e deixar login só com usuário e senha é trocar um risco por outro: o e-mail passa a ser acessível de qualquer lugar do mundo com uma credencial vazada. Trate identidade como parte do escopo da migração, não como melhoria futura.

Fase 3: coexistência

Coexistência é o período em que parte dos usuários já está na nuvem e parte continua no servidor local. Nessa fase é preciso garantir que:

Mensagens entre os dois ambientes cheguem normalmente, sem cair em caixa de spam.
A agenda funcione dos dois lados, para que ninguém marque reunião em cima de horário ocupado.
A lista de endereços da empresa apareça completa para todo mundo.

Quanto maior o número de usuários, mais essa fase se justifica. Em empresas pequenas, é comum migrar tudo em um único final de semana e dispensar coexistência.

Fase 4: migração dos dados

A cópia das caixas costuma rodar em segundo plano, com os usuários trabalhando normalmente. Migre por ondas, e coloque na primeira onda um grupo pequeno e tolerante, que saiba avisar rápido se algo estranho aparecer. Diretoria e financeiro entram nas últimas ondas, não na primeira.

Antes de começar, defina o que fazer com arquivos de e-mail antigos que os usuários guardam no próprio computador. Eles não são migrados automaticamente e são a principal fonte de reclamação depois do corte.

Fase 5: corte de DNS e MX

Este é o momento sensível. O registro MX é o que diz ao mundo onde entregar o e-mail do seu domínio. Enquanto ele apontar para o servidor antigo, é lá que a mensagem chega.

Boas práticas para o corte:

Reduza o tempo de vida do registro MX com antecedência, para que a mudança se propague rápido quando for feita.
Confira quem controla o DNS do domínio. Descobrir na hora do corte que a senha do painel está com um ex-fornecedor é um clássico.
Revise os registros de autenticação de remetente ao mesmo tempo. Se eles continuarem autorizando apenas o servidor antigo, seu e-mail passa a cair em spam nos destinatários.
Faça o corte em janela de baixa atividade e mantenha o servidor antigo ligado por um período, recebendo o que ainda chegar por lá.

Fase 6: desativação e limpeza

Depois que o fluxo estabiliza, apontar todos os sistemas internos para o novo caminho de envio, retirar o servidor antigo da exposição à internet e só então planejar o desligamento. Guarde uma cópia íntegra dos dados do servidor antes de destruir qualquer coisa, e registre por escrito a data em que ele saiu de operação.

O que fazer com o histórico de e-mail

Histórico é assunto jurídico antes de ser assunto técnico. Antes de decidir o que migrar, responda a três perguntas com quem cuida do jurídico e do fiscal na empresa:

Por quanto tempo a empresa precisa conseguir recuperar uma mensagem antiga?
Existe processo em curso que exija preservar a caixa de alguém específico?
Quem pode acessar a caixa de um funcionário que saiu, e sob qual autorização?

Do lado técnico, há dois pontos que geram surpresa. O primeiro: mover o e-mail para a nuvem não elimina a necessidade de backup próprio. Retenção de plataforma e backup são coisas diferentes, e a diferença aparece justamente no dia em que alguém apaga uma pasta inteira por engano. O segundo: caixas de gente que saiu da empresa consomem licença se continuarem como caixa de usuário comum, então trate esse caso na hora do planejamento e não depois da primeira fatura.

Onde as migrações dão errado

Nossa experiência de campo aponta sempre para os mesmos pontos:

Ninguém mapeou os sistemas que enviam e-mail. ERP, sistema de emissão fiscal e multifuncional param de enviar em silêncio.
Registro de autenticação de remetente esquecido. A empresa migra e passa a ser tratada como remetente suspeito.
Link de internet subdimensionado. Com o e-mail na nuvem, todo acesso passa a depender da conexão. Se o link já sofre no dia a dia, resolva antes.
Usuário sem aviso. A mudança de comportamento do Outlook e a nova tela de login precisam ser comunicadas antes, com instrução curta e objetiva.
Servidor antigo abandonado ligado. Fora de suporte, exposto e sem dono, ele vira porta de entrada.

Vale lembrar que 14 de outubro de 2025 não foi só a data do Exchange. Windows 10, Office 2016 e Office 2019 caíram junto. Se o seu parque ainda tem essas versões, você tem um problema de conjunto, não três problemas separados, e tratar tudo em um só plano de orçamento sai mais barato. Veja também as opções que sobraram para quem ainda usa Windows 10 e o guia sobre quando o Microsoft 365 vale o investimento.

Checklist antes de marcar a data do corte

Inventário de caixas, grupos, regras e sistemas emissores concluído e revisado.
Acesso ao painel de DNS confirmado, com senha em poder da empresa.
Licenciamento definido e contas criadas.
Autenticação multifator planejada, com procedimento para quem perder o celular.
Plano de backup do e-mail na nuvem definido antes da migração, não depois.
Onda piloto executada e validada por usuários reais.
Plano de retorno escrito: o que fazer se o corte falhar na madrugada.
Comunicado aos usuários enviado, com canal de suporte no dia seguinte ao corte.

Perguntas frequentes

Meu Exchange 2016 ainda funciona. Posso deixar como está por mais um ano?

Tecnicamente sim, ele continua entregando e-mail. O problema é que, desde 14 de outubro de 2025, nenhuma falha de segurança nova recebe correção, e servidor de e-mail é dos alvos mais visados porque fica exposto à internet. Cada mês adicional é risco acumulado sem contrapartida, e a conta costuma chegar de uma vez.

Vou perder e-mail durante a migração?

Não, se o projeto seguir a ordem correta. As mensagens são copiadas com o usuário trabalhando, e o servidor antigo é mantido ligado por um período depois do corte de DNS, justamente para receber o que ainda chegar por lá. Perda de mensagem quase sempre vem de corte apressado, sem redução prévia do tempo de vida do registro MX e sem período de convivência.

Preciso de backup se o e-mail está no Microsoft 365?

Sim. A plataforma cuida da disponibilidade do serviço, o que é diferente de proteger você contra exclusão acidental, contra saída de funcionário e contra necessidade de recuperar algo específico meses depois. Defina política de retenção e de backup na mesma fase em que define o licenciamento.

Como a BS IT Solutions conduz essa migração

A BS IT Solutions cuida do projeto de ponta a ponta: levantamento do ambiente atual, desenho da identidade, execução por ondas, corte de DNS em janela combinada e acompanhamento nos primeiros dias, quando aparecem os ajustes finos. Depois do corte, o ambiente entra no nosso monitoramento e na rotina de gestão de TI, para que o e-mail não volte a ser um assunto lembrado só quando quebra.

Se a sua empresa ainda opera Exchange 2016 ou 2019, o relógio já está correndo desde outubro de 2025. Fale com um especialista da BS IT Solutions e monte o plano de migração com data, ordem e responsáveis definidos.