Como migrar Active Directory local para a nuvem

Por que migrar o Active Directory local para a nuvem virou prioridade

O Active Directory (AD) local foi, por quase duas décadas, a espinha dorsal da identidade corporativa. Ele controla logins, permissões de arquivos, políticas de grupo (GPOs), acesso a impressoras, integração com ERP e praticamente qualquer recurso de TI dentro do perímetro da empresa. O problema é que esse perímetro deixou de existir: colaboradores trabalham de casa, acessam aplicações SaaS, usam notebooks corporativos em redes públicas e consomem dados de múltiplos dispositivos. O AD on-premises, ancorado em controladores de domínio físicos ou virtualizados dentro do data center, não foi projetado para esse cenário.

Segundo o relatório State of the Cloud 2025 da Flexera, 89% das médias e grandes empresas brasileiras já operam em modelo multicloud, e a identidade é apontada como o calcanhar de Aquiles em 62% dos projetos de migração. Manter AD local em uma operação predominantemente em nuvem gera latência de autenticação, custos ocultos com VPN, exposição de portas LDAP e uma superfície de ataque que cresce a cada endpoint remoto. Migrar para o Microsoft Entra ID (antigo Azure AD), em modelo puro ou híbrido, deixou de ser modernização opcional e passou a ser requisito de segurança e continuidade.

A boa notícia é que a migração pode (e deve) ser feita sem parar a operação. A má notícia é que quase toda migração malsucedida que vemos em auditorias começa pelo mesmo erro: pular o discovery. Empresas que tentam "ligar o sincronismo e ver no que dá" descobrem tarde demais que GPOs críticas não têm equivalente em nuvem, que contas de serviço legadas quebram aplicações de RH ou que o schema foi customizado por um consultor que saiu da empresa em 2014.

Discovery: o mapeamento que define o sucesso do projeto

Antes de tocar qualquer configuração, é preciso inventariar o que existe. Um AD maduro costuma ter entre 15 e 40 anos de legado acumulado, incluindo objetos órfãos, contas de serviço sem dono, GPOs duplicadas e relações de confiança com domínios que nem existem mais. O discovery é a fase mais subestimada e mais crítica da migração. Ele revela, em média, 20% a 30% de objetos que podem ser descartados, o que reduz o escopo e o custo do projeto.

O inventário mínimo para uma migração segura deve incluir:

• Usuários ativos e inativos — identificar contas sem login há mais de 90 dias (candidatas a desativação) e contas privilegiadas (Domain Admins, Enterprise Admins, Schema Admins).
• Grupos de segurança e distribuição — mapear aninhamentos, pois o Entra ID tem limites diferentes para grupos dinâmicos e grupos atribuíveis a papéis.
• GPOs aplicadas — quais políticas realmente estão em uso, quais podem ser traduzidas para Intune e quais precisam ser reescritas como Conditional Access ou configuration profiles.
• OUs (Organizational Units) — estrutura hierárquica que, na nuvem, é substituída por Administrative Units e grupos dinâmicos baseados em atributos.
• Contas de serviço e SPNs — frequentemente conectadas a aplicações Kerberos que exigem planejamento específico com Azure AD Kerberos ou migração para autenticação moderna (OAuth 2.0/OIDC).
• Shares de arquivos, impressoras e aplicações on-premises — dependências que determinam se a migração será pura cloud ou híbrida.

Ferramentas como o Microsoft Entra Connect Health, o AD Migration Analyzer e o Purview DLP fornecem parte desse mapeamento, mas nenhuma substitui a entrevista com os donos de aplicação. Muitas vezes, o RH depende de uma conta de serviço específica para rodar a folha, e só o gestor do sistema sabe disso. Pular essa conversa é receita para indisponibilidade.

Arquiteturas de migração: híbrida, faseada ou greenfield

Existem três caminhos possíveis, e a escolha depende da maturidade de TI, do volume de aplicações legadas e do apetite por risco. Não existe resposta única, mas há recomendações claras para PMEs brasileiras.

1. Migração híbrida (Hybrid Identity) — O Entra Connect sincroniza o AD local com o Entra ID em tempo quase real. Usuários continuam autenticando no AD local para recursos on-premises e no Entra ID para recursos cloud (Microsoft 365, SaaS, Azure). É a abordagem mais segura para empresas com ERP legado, file servers locais ou aplicações que ainda dependem de Kerberos. A desvantagem é manter dois mundos, o que dobra a superfície de manutenção.

2. Migração faseada com coexistência — Departamento por departamento, cargas de trabalho são movidas para a nuvem. Começa-se por equipes 100% SaaS (marketing, comercial), valida-se a experiência de login, e só então avança-se para times com dependências legadas (financeiro, operações). Essa abordagem minimiza risco e permite aprender com os primeiros grupos antes de tocar em áreas críticas.

3. Greenfield (tenant novo) — Cria-se um tenant Entra ID do zero, sem sincronismo com o AD legado. Usuários são recriados, aplicações reintegradas e o AD antigo é desativado em uma janela planejada. É a abordagem mais limpa, mas exige downtime e só faz sentido para empresas pequenas (até ~100 usuários) ou que estão passando por uma cisão/aquisição.

"Em 18 anos migrando ambientes corporativos, aprendemos que a migração híbrida faseada é a que menos gera chamado no service desk. O usuário não percebe a troca — e essa é a métrica de sucesso." — Equipe de Cloud Duk Informática

Passo a passo técnico: do Entra Connect ao cutover

Com o discovery consolidado e a arquitetura escolhida, a execução segue uma sequência bem definida. Pular etapas ou inverter ordem é a principal causa de reversão de projeto.

1. Preparação do tenant Entra ID — definir domínios customizados (empresa.com.br), configurar MFA obrigatório para contas administrativas, habilitar Conditional Access em modo report-only e criar break-glass accounts (2 contas emergenciais fora do sincronismo).
2. Limpeza do AD local — remover contas inativas, consolidar grupos duplicados, corrigir atributos inconsistentes (UPN, mail, proxyAddresses) e validar o schema com o IdFix, ferramenta gratuita da Microsoft que detecta 90% dos problemas de sincronismo antes deles acontecerem.
3. Instalação do Entra Connect — servidor dedicado (nunca no controlador de domínio), com SQL Server Express para ambientes até 100 mil objetos ou SQL Server completo acima disso. Escolher o método de autenticação: Password Hash Sync (mais simples e resiliente), Pass-through Authentication (valida credencial direto no AD local) ou Federation com ADFS (legado, evitar em novas implementações).
4. Sincronismo inicial em modo staging — o servidor sincroniza objetos mas não envia autenticação. Permite validar mapeamentos, regras de filtro e scope antes de ativar. Esse passo economiza dias de retrabalho.
5. Ativação e validação piloto — um grupo de 10 a 20 usuários voluntários valida login em Microsoft 365, SaaS e aplicações híbridas. Qualquer problema aqui é corrigido sem impacto em produção.
6. Rollout por ondas — departamentos são migrados em janelas semanais. A cada onda, métricas de service desk, latência de login e chamados são avaliadas. Se algo desvia do baseline, a próxima onda é pausada.
7. Substituição de GPOs por Intune — políticas de dispositivo, instalação de software, restrições de USB e configurações de segurança migram para Microsoft Intune. GPOs locais são desativadas gradualmente conforme máquinas são enrolled.
8. Decomissão do AD legado — só acontece quando 100% das dependências foram migradas ou aposentadas. Mesmo assim, muitas empresas mantêm um AD local reduzido para Kerberos legado por mais 12 a 24 meses.

Segurança e conformidade: o que muda na identidade em nuvem

Migrar o AD para a nuvem não é apenas trocar de tecnologia — é redesenhar o modelo de segurança de identidade. O AD local opera por perímetro (dentro da rede, confia; fora, desconfia). O Entra ID opera por Zero Trust: toda requisição é avaliada por contexto (usuário, dispositivo, localização, risco), independentemente de onde ela venha.

Os controles que passam a estar disponíveis incluem Conditional Access com avaliação de risco em tempo real, MFA resistente a phishing (FIDO2, Windows Hello for Business, Authenticator com number matching), Privileged Identity Management (PIM) para elevação temporária de privilégios, Identity Protection com detecção de credenciais vazadas e Sign-in risk policies que bloqueiam logins anômalos. Um estudo da Microsoft com 1.200 empresas mostrou que a ativação de MFA reduz em 99,2% o risco de comprometimento de conta — dado que nenhum firewall local consegue igualar.

Do lado da conformidade, a LGPD exige rastreabilidade de acesso a dados pessoais. O Entra ID entrega isso nativamente via Audit Logs e Sign-in Logs, exportáveis para Microsoft Sentinel ou SIEM de terceiros. O AD local entrega logs, mas consolidá-los, enriquecê-los e correlacioná-los exige investimento em SIEM e pessoas — custo que muitas PMEs simplesmente não absorvem.

Erros mais comuns e como evitar a reversão do projeto

Migrações que revertem têm padrão. Conhecê-lo é metade do caminho para evitá-lo. Os cinco erros mais frequentes que encontramos em projetos de recuperação são:

• Não testar o plano de rollback — toda fase deve ter um caminho de volta documentado e testado. Quando o imprevisto acontece às 02h da manhã de sábado, não há tempo para improvisar.
• Subestimar o treinamento de usuários — o login muda (de DOMINIO\usuario para email completo), a tela muda, o MFA aparece. Sem comunicação, o service desk vira um caos nas primeiras 72 horas.
• Ignorar aplicações legadas Kerberos — ERPs, sistemas de ponto, softwares de engenharia ainda dependem de Kerberos on-premises. Se não há plano para elas, a migração trava.
• Não desativar o sincronismo de contas privilegiadas — contas de Domain Admin nunca devem ser sincronizadas para o Entra ID. Caso contrário, um comprometimento em cloud escala para o AD local.
• Abandonar o AD local sem plano de decomissão — manter dois ambientes "por garantia" indefinidamente dobra o custo e dobra o risco. Há que se ter data limite, mesmo que ela seja daqui a 24 meses.

Migração de AD não é projeto de infraestrutura. É projeto de identidade, e identidade é o novo perímetro. Quem trata como "troca de servidor" paga caro depois.

Como a Duk conduz migrações de Active Directory sem parar operação

Há mais de 18 anos, a Duk Informática & Cloud atua como parceira de TI de mais de 550 empresas brasileiras, conduzindo migrações de identidade em setores que vão de indústria e varejo a saúde e serviços financeiros. Como Microsoft Gold Partner, temos acesso a ferramentas de planejamento, assessment e suporte escalado diretamente com a Microsoft, o que acelera a identificação de riscos e a resolução de incidentes durante a janela crítica.

Nossa metodologia de migração é dividida em quatro fases: discovery assistido (entrevistas + ferramentas automatizadas), desenho de arquitetura alinhado ao modelo de negócio, execução faseada com janelas de manutenção fora do horário comercial e acompanhamento pós-migração de 90 dias para estabilização. Operamos com SLA de resposta em 3,7 minutos para chamados críticos, o que significa que qualquer problema detectado em produção tem time de especialistas em ação antes mesmo do usuário formalizar o chamado.

Se sua empresa está avaliando migrar o Active Directory local para a nuvem, ou já tentou e recuou, vale conversarmos. Em uma primeira reunião de 30 minutos, mapeamos seu cenário, apontamos riscos que você talvez ainda não tenha percebido e entregamos uma recomendação de arquitetura — sem compromisso.

Fale com um especialista Duk pelo WhatsApp →