Migrei uma empresa inteira para o Microsoft 365 Business Premium: o que deu certo e o que eu faria diferente

Este texto não é um tutorial genérico. É o registro do que aconteceu quando assumi, sozinho, a migração de uma empresa inteira para o Microsoft 365 Business Premium, incluindo identidade, dispositivos, segurança e comunicação interna. Escrevo aqui porque quase tudo que li antes de começar assumia um cenário que não é o de uma empresa brasileira de porte médio: sem equipe de TI dedicada, com máquinas compradas em momentos diferentes e com gente que nunca ouviu falar em autenticação multifator.

O ponto de partida era pior do que parecia

Quando cheguei, o cenário era o clássico: contas de e-mail pessoais usadas para assunto de trabalho, arquivos espalhados entre pendrives, WhatsApp e uma pasta compartilhada sem controle de permissão, notebooks com contas locais de administrador e nenhum inventário confiável de dispositivos. Não existia backup formal. Se um notebook fosse roubado, o dado ia junto.

O primeiro trabalho não foi técnico, foi de levantamento. Passei os primeiros dias mapeando três coisas: quem usa o quê, onde o dado realmente mora e quais processos param se algo sair do ar. Esse mapa virou o roadmap. Sem ele, qualquer migração vira apagar incêndio.

Por que Business Premium e não a versão mais barata

A diferença entre os planos básicos e o Business Premium não está no Word ou no Excel. Está em Intune, Entra ID com acesso condicional, Defender e as ferramentas de conformidade. Sem esse pacote, você tem e-mail na nuvem e continua sem governança de dispositivo. Em uma empresa que trata dado de cliente, isso é uma dívida técnica com prazo de vencimento.

A conta que apresentei à diretoria foi simples: o custo mensal adicional por usuário era menor que uma hora de trabalho de um advogado tratando de um incidente de vazamento. A decisão foi aprovada na primeira reunião.

A ordem que funcionou

Migração é sequência. A ordem errada gera retrabalho. A que usei foi esta:

1. Identidade primeiro. Criação do tenant, domínio verificado, usuários e grupos no Entra ID. Nada de dispositivo antes de identidade estar limpa.
2. Estrutura de dados. Definição dos sites do SharePoint por área, com permissão por grupo, antes de qualquer arquivo subir. Migrar bagunça só gera bagunça na nuvem.
3. Dispositivos. Inscrição no Intune, perfis de configuração, BitLocker, remoção das contas locais de administrador.
4. Segurança condicional. MFA obrigatório, políticas de acesso condicional por contexto e bloqueio de protocolos legados.
5. Comunicação e adoção. Só depois de tudo funcionando é que o usuário final foi acionado.

Intune: onde eu subestimei o esforço

Escrever a política é rápido. Aplicar em máquinas heterogêneas, não. Encontrei notebooks com versões de Windows diferentes, alguns em edição Home, que simplesmente não aceitam ingresso corporativo nem BitLocker gerenciado. A solução foi padronizar em Windows 11 Pro, e isso virou uma linha de orçamento que não estava prevista.

A lição prática: faça o inventário de edição do sistema operacional antes de prometer prazo. Uma planilha com modelo, edição, ano de compra e usuário responsável teria me poupado duas semanas.

Outro ponto: perfis de configuração devem ser aplicados a um grupo piloto de três a cinco pessoas por no mínimo uma semana. Fiz isso e evitei um desastre, porque uma política de restrição de USB pegava também os teclados sem fio de um setor inteiro.

Acesso condicional é onde a segurança acontece de verdade

MFA sozinho ajuda, mas o ganho real veio das regras de contexto: bloquear acesso de fora do país, exigir dispositivo em conformidade para abrir dados sensíveis e barrar autenticação legada, que é o vetor mais explorado em ataques de força bruta contra o Microsoft 365.

Aqui vai o aviso que ninguém dá: sempre mantenha uma conta de emergência excluída das políticas, guardada em cofre físico. Se você se trancar para fora do próprio tenant com uma regra mal escrita, é essa conta que salva a operação.

Adoção: a parte que quase derrubou o projeto

Tecnicamente, o ambiente ficou pronto antes do prazo. O problema foi humano. MFA gerou resistência imediata, porque as pessoas interpretaram como desconfiança da empresa. O que resolveu não foi comunicado formal, foi demonstração: mostrei, em uma reunião de quinze minutos, quanto tempo leva para descobrir uma senha fraca e o que acontece com o e-mail de um financeiro comprometido.

Depois disso, adotei três medidas simples que reduziram o suporte a quase zero: um guia de uma página com prints, um canal fixo no Teams para dúvidas e atendimento presencial nos dois primeiros dias de cada setor.

O que eu faria diferente

• Inventário antes de tudo. Modelo, edição do Windows, idade do equipamento e responsável. Sem isso, todo cronograma é chute.
• Grupo piloto maior. Usei três pessoas de um setor só. Deveria ter usado uma pessoa de cada setor, porque cada área tem um uso diferente de periférico e de arquivo.
• Congelar a estrutura de pastas antes da migração. Migrei enquanto as pessoas ainda criavam pastas novas, e parte do trabalho de organização precisou ser refeita.
• Documentar no mesmo dia. Toda política aplicada precisa de um registro com data, motivo e responsável. Três meses depois, ninguém lembra por que uma exceção existe.

Resultado concreto

Ao final, o ambiente ficou com identidade centralizada, dispositivos criptografados e gerenciados, acesso por grupo em vez de por pessoa, comunicação interna dentro do Teams e SharePoint, e backup coberto pela política da plataforma. O ganho mais visível para a diretoria não foi segurança, foi previsibilidade: entrada e saída de funcionário viraram um procedimento de poucos minutos, em vez de uma caçada por senhas e arquivos.

Se você vai fazer isso na sua empresa

Comece pequeno e em ordem. Identidade, dados, dispositivos, segurança, pessoas. Não pule etapa por pressa e não prometa data antes do inventário. E trate adoção como parte do projeto, não como consequência dele. Ambiente seguro que ninguém usa direito é só uma despesa mensal bem documentada.