Quem decide migrar para o Azure costuma descobrir tarde demais que a ferramenta da Microsoft não funciona sozinha: falta permissão no tenant, provedor de recursos sem registro, saída de rede bloqueada ou credencial inadequada no ambiente de origem. O resultado aparece na forma de descoberta incompleta, appliance que não conecta e avaliação que não serve para planejar. Este guia reúne um checklist de pré-requisitos antes de usar o Azure Migrate para que o time valide cada item na ordem certa e chegue à execução sem surpresas.
O que é o Azure Migrate e o que ele exige antes de qualquer descoberta
O Azure Migrate é o hub central da Microsoft para planejar e executar migrações de servidores, bancos de dados, aplicações web e desktops virtuais para o Azure. Ele reúne descoberta, avaliação, dimensionamento e execução de migração em um único projeto, com ferramentas nativas e integração com ISVs parceiros. Antes de iniciar qualquer descoberta, o ambiente precisa atender a um conjunto específico de requisitos técnicos e organizacionais — ignorá-los gera avaliações imprecisas, falhas de conexão do appliance ou bloqueios de segurança no meio do projeto.
Um erro comum é tratar o Azure Migrate como uma ferramenta que "basta instalar e rodar". Na prática, ele depende de permissões no tenant, provedores de recursos habilitados, conectividade de saída liberada, contas com privilégios no ambiente de origem e uma janela de coleta de desempenho bem definida. Empresas de médio e grande porte, sobretudo as que operam com dados sensíveis ou transações via Pix, precisam alinhar esses pré-requisitos com as políticas internas de segurança antes mesmo de provisionar o projeto.
O objetivo deste guia é funcionar como um checklist de pré-requisitos antes de usar o Azure Migrate, cobrindo desde a estrutura da conta até os critérios de aceite de rede e identidade. Cada seção detalha o que validar, por que importa e qual o impacto de deixar o item pendente. A ordem segue o fluxo real de implantação: primeiro a fundação no Azure, depois a conectividade, o appliance, o inventário e, por fim, as camadas de governança e conformidade.
Pré-requisitos de conta, assinatura e permissões no Azure
O projeto do Azure Migrate nasce dentro de uma assinatura do Azure. A assinatura precisa estar ativa, sem restrições de gasto que bloqueiem a criação de recursos, e associada a um tenant do Microsoft Entra ID. Antes de criar o projeto, confirme que a assinatura escolhida tem quota suficiente para os recursos auxiliares — como contas de armazenamento e cofres de chaves — que o Azure Migrate provisiona automaticamente durante a descoberta.
Também é necessário definir quem vai operar o projeto. A recomendação da Microsoft é usar contas de serviço ou identidades dedicadas, não contas pessoais de administradores. Isso facilita auditoria, revogação de acesso e continuidade do projeto caso alguém saia da equipe. Em ambientes que lidam com dados sensíveis, essa separação costuma ser exigida pela própria política de compliance.
Papéis e permissões mínimas para criar e operar o projeto
Para criar o projeto do Azure Migrate, o usuário precisa de permissão de Contributor ou Owner na assinatura, ou de uma custom role equivalente que permita registrar provedores de recursos e criar os recursos do serviço. Depois que o projeto existe, as permissões podem ser reduzidas: para operar descoberta e avaliação, o papel Azure Migrate Contributor costuma ser suficiente na maioria dos cenários.
- Owner ou Contributor na assinatura: necessário apenas na criação do projeto e no registro inicial de provedores.
- Azure Migrate Contributor: cria e gerencia avaliações, executa descoberta e inicia migrações dentro do projeto.
- Leitor no grupo de recursos: permite visualizar avaliações e relatórios sem alterar configurações.
- Permissões no Entra ID: exigidas para criar aplicativos de serviço usados na descoberta sem agente.
Em organizações com segregação de funções rígida, o ideal é mapear cada etapa do Azure Migrate para um papel específico. O time de segurança, por exemplo, pode reter o Owner e conceder apenas Azure Migrate Contributor ao time de infraestrutura. Isso reduz a superfície de privilégios sem travar o projeto.
Provedores de recursos e regiões que precisam estar habilitados
O Azure Migrate depende de vários provedores de recursos registrados na assinatura. Entre os principais estão Microsoft.Migrate, Microsoft.OffAzure, Microsoft.KeyVault e Microsoft.Storage. Sem o registro, a criação do projeto falha com erro de permissão ou de recurso indisponível. O registro pode ser feito pelo portal, por Azure CLI ou por PowerShell.
Quanto à região, o projeto do Azure Migrate pode ser criado em várias geografias, mas os metadados de descoberta e avaliação permanecem na região escolhida. Empresas com exigência de residência de dados devem selecionar a região correta já na criação do projeto — ela não pode ser alterada depois. Vale lembrar que a região do projeto não precisa ser a mesma região de destino das máquinas migradas.
Pré-requisitos de rede e conectividade para o appliance e os agentes
A conectividade é a causa mais frequente de falha na descoberta. O appliance do Azure Migrate e os agentes instalados nos servidores de origem precisam alcançar endpoints públicos do Azure, a menos que a organização use Azure ExpressRoute ou VPN com roteamento adequado. Em ambientes com proxy corporativo, firewall de saída restrito ou inspeção TLS, os requisitos mudam e exigem configuração adicional.
Antes de implantar qualquer componente, o time de redes precisa validar três camadas: resolução de DNS, rota de saída para os endpoints do Azure e política de firewall. Uma validação antecipada evita o cenário clássico de appliance implantado, conta configurada e descoberta parada por timeout de conexão.
Portas, endpoints e regras de saída necessárias
O appliance do Azure Migrate se comunica com o Azure pela porta 443 (HTTPS) de saída. Não há necessidade de abrir portas de entrada, já que a comunicação é sempre iniciada pelo appliance. Os endpoints de destino incluem domínios como *.migrate.azure.com, *.blob.core.windows.net, *.servicebus.windows.net e *.vault.azure.net, entre outros que variam conforme o cenário de descoberta.
- Porta 443 de saída: obrigatória para todo o tráfego do appliance e dos agentes.
- Porta 443 para o vCenter/Hyper-V: usada pelo appliance para consultar a API de gerenciamento.
- Porta 22 (SSH) ou 5985/5986 (WinRM): para descoberta de servidores físicos ou migração baseada em agente.
- Lista de domínios: precisa estar liberada no firewall ou proxy, não apenas por IP, pois a Microsoft altera os endereços periodicamente.
Se a organização usa proxy com autenticação, o appliance suporta configuração de proxy durante a implantação. Em cenários com inspeção TLS, é preciso adicionar os certificados da autoridade interceptadora ao repositório de confiança do appliance. Sem isso, o handshake TLS falha e a descoberta não avança.
Acesso ao vCenter, hosts ou servidores de origem
Para descobrir máquinas virtuais VMware, o appliance precisa de uma conta com acesso somente leitura ao vCenter Server. Essa conta deve ter privilégios de leitura em datacenters, hosts, VMs, datastores e redes. Para Hyper-V, o appliance se conecta aos hosts ou ao cluster com uma conta de administrador local ou de domínio com permissão de leitura.
No caso de servidores físicos ou de nuvens como AWS e GCP, a descoberta pode ser feita com credenciais de administrador local em cada máquina, via WinRM ou SSH. A recomendação é criar contas dedicadas para o Azure Migrate, com senha forte e, se possível, protegidas por cofre de senhas ou gerenciamento centralizado de credenciais. Evite reutilizar contas de serviço de outros sistemas.
Pré-requisitos do appliance do Azure Migrate
O appliance é uma máquina virtual que funciona como coletor e orquestrador da descoberta. Ele é fornecido como um template OVA para VMware, VHD para Hyper-V e script de instalação para servidores físicos. O appliance não deve ser reaproveitado de outros projetos nem compartilhado entre ambientes de descoberta diferentes.
Um único appliance descobre até 10.000 servidores em um ambiente VMware, mas o número prático depende do volume de dados de desempenho e da frequência de coleta. Para ambientes maiores, é possível implantar múltiplos appliances, cada um apontando para um escopo diferente do vCenter.
Dimensionamento, sistema operacional e recursos do appliance
O appliance do Azure Migrate requer, no mínimo, 4 vCPUs, 16 GB de RAM e 80 GB de disco para a maioria dos cenários de descoberta de VMware e Hyper-V. Para descoberta de servidores físicos ou avaliação de dependências com perfil de tráfego, a Microsoft recomenda 8 vCPUs e 16 GB de RAM. O sistema operacional é baseado em Windows Server, fornecido já configurado no template.
- VMware: 4 vCPUs, 16 GB RAM, 80 GB de disco, template OVA.
- Hyper-V: 4 vCPUs, 16 GB RAM, 80 GB de disco, VHD compactado.
- Servidores físicos: 8 vCPUs, 16 GB RAM, 80 GB de disco, instalação via script.
- Rede: o appliance precisa de IP estático e acesso ao vCenter/hosts e à internet.
O appliance não deve ser usado para outras funções e não requer alta disponibilidade — se ele falhar, a descoberta pode ser retomada com um novo appliance, desde que o projeto e as credenciais estejam preservados. O disco de 80 GB armazena metadados temporários e logs; o desempenho do disco influencia a velocidade de processamento dos dados coletados.
Contas de descoberta e escopo de coleta de inventário
Durante a configuração do appliance, é preciso informar as credenciais de acesso ao ambiente de origem e definir o escopo de descoberta. No VMware, o escopo pode ser o vCenter inteiro, um datacenter, um cluster ou pastas específicas de VMs. No Hyper-V, o escopo é definido por host ou cluster. Limitar o escopo a ambientes que realmente serão avaliados reduz ruído e acelera a descoberta.
A conta usada para descoberta deve ter permissão de leitura, mas o appliance também precisa de uma conta local com privilégios administrativos para instalar agentes leves quando a avaliação de dependências sem agente estiver habilitada. Em ambientes com credenciais rotacionadas automaticamente, é importante alinhar a janela de validade da senha com o calendário do projeto.
Pré-requisitos de inventário e avaliação de dependências
A qualidade da avaliação depende da qualidade do inventário. Antes de iniciar a descoberta, o time de infraestrutura deve ter clareza sobre quais sistemas operacionais, versões de aplicação e cargas de trabalho serão incluídos. Isso evita surpresas com sistemas legados sem suporte ou com dependências ocultas entre servidores.
Para empresas do setor financeiro, o inventário também serve como evidência de conformidade. Documentar o que existe, onde está e como se comunica é parte do processo de due diligence antes de qualquer movimentação de carga. O Azure Migrate gera esse inventário automaticamente, mas a validação humana continua sendo necessária.
O que levantar antes: sistemas operacionais, versões e workloads
O Azure Migrate suporta descoberta de Windows Server 2008 em diante e das principais distribuições Linux, mas versões muito antigas podem exigir migração baseada em agente ou ajustes manuais. O ideal é levantar, por servidor: sistema operacional, versão, edição, quantidade de discos, tamanho dos discos, memória, vCPUs e aplicações instaladas. Esses dados alimentam o dimensionamento e o cálculo de custo no Azure.
- Sistemas operacionais: Windows Server, distribuições Linux com suporte e versões de kernel.
- Workloads: SQL Server, IIS, aplicações Java, Oracle, SAP e serviços de arquivo.
- Discos e volumes: tamanho, tipo de storage e taxa de IOPS/throughput.
- Dependências: conexões de rede entre servidores, portas e protocolos usados.
Para avaliação de dependências, o Azure Migrate oferece dois modos: sem agente, que usa dados de conexão coletados pelo appliance, e baseado em agente, que instala Microsoft Monitoring Agent e Dependency Agent em cada máquina. O modo sem agente é mais simples, mas tem menos granularidade; o baseado em agente exige mais preparação, porém entrega mapa completo de comunicação.
Dados de desempenho e janela de coleta necessária
O dimensionamento baseado em desempenho exige uma janela de coleta de métricas. A Microsoft recomenda coletar dados por pelo menos 7 dias para capturar ciclos de uso, e idealmente por 30 dias quando há sazonalidade — como picos de fim de mês, fechamento contábil ou horários de pico de transações via Pix. Quanto maior a janela, mais preciso o percentil de utilização usado no dimensionamento.
O Azure Migrate coleta CPU, memória, disco e rede em intervalos regulares e aplica percentis configuráveis, como P95, para sugerir o tamanho da VM no Azure. Se a janela for curta demais, o dimensionamento pode subestimar picos e gerar máquinas subdimensionadas. Se for longa demais, pode incluir períodos atípicos e inflar o custo estimado.
Pré-requisitos de identidade, segurança e conformidade
Migração envolve movimentação de dados e, em muitos casos, replicação de discos inteiros para a nuvem. Em setores regulados, isso aciona controles de segurança e exigências de conformidade que precisam ser resolvidos antes do início da descoberta. Não se trata apenas de permissão técnica, mas de alinhamento com políticas internas e regulatórias.
O Azure Migrate replica dados por canais criptografados, mas a organização precisa decidir onde os dados de replicação ficam, quem tem acesso ao cofre de chaves e como auditar as ações realizadas no projeto. Em ambientes que processam dados sensíveis, como transações financeiras, esses pontos costumam ser bloqueadores se não forem tratados desde o início.
Integração com Microsoft Entra ID e controle de acesso
O Azure Migrate usa o Microsoft Entra ID (antigo Azure Active Directory) para autenticação e autorização. O projeto herda as políticas de acesso condicional do tenant, o que significa que logins podem ser bloqueados por políticas de MFA, localização ou dispositivo. Antes de iniciar, confirme que as contas de serviço usadas no projeto estão cobertas pelas políticas corretas e não serão bloqueadas no meio da descoberta.
O controle de acesso deve seguir o princípio do menor privilégio. Atribua papéis no escopo do grupo de recursos ou da assinatura, não no tenant inteiro. Para ambientes com exigência de trilha de auditoria, habilite o Azure Activity Log e, se necessário, envie os logs para o Microsoft Sentinel ou para o SIEM corporativo. Cada criação de projeto, registro de appliance ou início de replicação gera eventos auditáveis.
Requisitos de segurança, criptografia e políticas internas
Os dados coletados pelo Azure Migrate são criptografados em trânsito e em repouso. O appliance usa canais TLS para enviar metadados ao Azure, e as contas de armazenamento criadas pelo serviço aplicam criptografia gerenciada pela Microsoft por padrão. Para organizações que exigem chaves gerenciadas pelo cliente, é possível configurar customer-managed keys em alguns recursos do Azure Migrate.
Políticas internas de segurança também podem afetar o projeto. Ambientes que bloqueiam administração remota, exigem jump servers ou proíbem instalação de agentes em servidores de produção precisam de um plano alternativo — como descoberta sem agente ou replicação por appliance. O ideal é envolver o time de segurança na fase de design, não na fase de execução. Para entender como proteger dados sensíveis durante a migração, vale revisar as práticas descritas em proteger dados sensíveis.
O que define o custo de uma migração com o Azure Migrate
O Azure Migrate em si é gratuito para descoberta e avaliação na maioria dos cenários — o custo aparece nos recursos auxiliares e na infraestrutura de destino. Durante a descoberta, o serviço cria contas de armazenamento, cofres de chaves e, em alguns casos, um Log Analytics workspace que geram cobrança conforme o volume de dados e a retenção configurada.
- Volume de dados coletados: quanto maior o inventário e a janela de desempenho, maior o armazenamento consumido.
- Recursos auxiliares: Log Analytics, contas de armazenamento e cofres de chaves têm custo próprio.
- Replicação de discos: durante a migração, o tráfego de replicação e o armazenamento temporário geram custo.
- Infraestrutura de destino: o custo final depende do tamanho e da quantidade de VMs provisionadas no Azure.
O dimensionamento correto, feito a partir de uma avaliação com boa janela de coleta, é o principal fator de controle de custo. Máquinas superdimensionadas no Azure geram gasto recorrente desnecessário; máquinas subdimensionadas geram retrabalho. Por isso, a fase de pré-requisitos e coleta de dados é também uma fase de otimização financeira, não apenas técnica.
Checklist final: valide cada pré-requisito antes de iniciar
Use este checklist como critério de aceite. Cada item deve estar confirmado e documentado antes da primeira descoberta. Em projetos com auditoria externa ou comitê de mudanças, o checklist serve como evidência de que a preparação foi concluída.
- Assinatura ativa com quota suficiente e região do projeto definida.
- Provedores de recursos registrados: Microsoft.Migrate, Microsoft.OffAzure, Microsoft.Storage, Microsoft.KeyVault.
- Papéis atribuídos: Owner/Contributor para criação e Azure Migrate Contributor para operação.
- Rede validada: porta 443 de saída liberada, domínios do Azure Migrate acessíveis, proxy configurado se necessário.
- Acesso ao ambiente de origem: conta de leitura no vCenter/Hyper-V ou credenciais locais para servidores físicos.
- Appliance provisionado: dimensionamento correto, IP estático, template na versão mais recente.
- Inventário mapeado: lista de servidores, sistemas operacionais, workloads e dependências conhecidas.
- Janela de coleta definida: mínimo de 7 dias, ideal de 30 dias para cargas com sazonalidade.
- Políticas de segurança alinhadas: acesso condicional, criptografia, trilha de auditoria e aprovação do time de segurança.
Se algum item estiver pendente, não inicie a descoberta. Um pré-requisito falho no começo costuma custar mais caro corrigir no meio do projeto, principalmente quando envolve reconfiguração de firewall, recriação de appliance ou renegociação de acesso com o time de segurança.
Erros comuns de pré-requisito que travam a migração
Conhecer os erros frequentes ajuda a priorizar as validações. A maioria dos projetos que param na fase de descoberta enfrenta um ou mais dos problemas abaixo — e quase todos são evitáveis com o checklist aplicado antes da implantação.
- Provedor de recurso não registrado: falha na criação do projeto ou do cofre de chaves.
- Firewall bloqueando endpoints: appliance implanta, mas não envia dados; descoberta fica vazia.
- Conta do vCenter sem privilégios suficientes: descoberta parcial ou lista de VMs incompleta.
- Proxy com inspeção TLS sem certificado no appliance: handshake falha e a comunicação é interrompida.
- Janela de coleta curta demais: dimensionamento impreciso, VMs subdimensionadas no Azure.
- Política de acesso condicional bloqueando conta de serviço: autenticação falha durante a replicação.
- Escopo de descoberta amplo demais: volume excessivo de dados, custo de Log Analytics elevado e ruído na avaliação.
Um erro menos visível, mas igualmente crítico, é tratar o Azure Migrate como projeto exclusivo da infraestrutura. Sem envolvimento de segurança, redes e compliance desde o início, o projeto tende a ser interrompido na primeira revisão de mudança. Em ambientes regulados, a ausência de um plano de backup durante a transição também costuma ser apontada como pendência.
Perguntas frequentes sobre pré-requisitos do Azure Migrate
Preciso de uma assinatura dedicada para o Azure Migrate?
Não é obrigatório, mas é recomendado separar o projeto de migração em uma assinatura específica. Isso facilita o controle de custos, a gestão de permissões e a auditoria das ações realizadas durante o projeto.
O appliance precisa ficar no mesmo domínio dos servidores de origem?
Não. O appliance se conecta ao vCenter, aos hosts Hyper-V ou diretamente aos servidores físicos por rede. Ele não precisa ingressar em domínio, mas precisa de conectividade de rede com o ambiente de origem e com os endpoints do Azure.
Posso usar o Azure Migrate sem abrir portas de entrada no firewall?
Sim. Toda a comunicação é iniciada pelo appliance ou pelos agentes em direção ao Azure, pela porta 443 de saída. Nenhuma porta de entrada precisa ser liberada no ambiente de origem.
Quanto tempo dura a fase de pré-requisitos?
Depende da maturidade do ambiente. Em organizações com processos de mudança ágeis, a preparação pode levar de uma a duas semanas. Em ambientes regulados, com aprovações de segurança e comitês de mudança, pode levar de quatro a oito semanas.
O Azure Migrate funciona com proxy corporativo?
Sim, o appliance suporta configuração de proxy. Em proxies com autenticação ou inspeção TLS, é necessário ajustar credenciais e certificados. Consulte a documentação oficial para a lista completa de domínios que precisam ser liberados.
Preciso parar as máquinas de origem durante a descoberta?
Não. A descoberta e a coleta de desempenho são feitas com as máquinas em operação. A parada só ocorre, se desejado, no momento do cutover final da migração.
