Decidir o que sai do datacenter e o que permanece nele é uma das escolhas mais caras de uma migração para a nuvem — e errar essa conta costuma aparecer meses depois, em forma de retrabalho. Se a sua equipe precisa como avaliar workloads antes de migrar para Azure sem transformar o projeto em aposta, este texto apresenta um método estruturado: inventário, dependências, criticidade, desempenho, custos e riscos, com critérios objetivos para priorizar ondas e aprovar cada carga antes de movê-la.
O que significa avaliar um workload antes de migrar para o Azure
Avaliar um workload antes de migrar para o Azure é o processo estruturado de levantar, documentar e analisar cada carga de trabalho do ambiente atual — aplicação, banco de dados, serviço ou conjunto de servidores que entregam uma função de negócio — para decidir se ela pode migrar, como deve migrar e em que ordem. O termo "workload" não se limita a uma máquina virtual: ele abrange a pilha completa que sustenta uma operação, incluindo sistema operacional, middleware, bibliotecas, conexões de rede, identidades, rotinas de backup e políticas de segurança.
Essa avaliação produz um dossiê por workload com informações objetivas: consumo real de CPU e memória, picos de utilização, dependências de rede, requisitos de latência, acoplamento com hardware físico, obrigações de compliance e custo projetado no Azure. Sem esse dossiê, a decisão de migrar vira aposta — e apostas em infraestrutura costumam ser cobradas caro em retrabalho, indisponibilidade e custos fora do orçamento.
Na prática, avaliar significa responder a três perguntas para cada carga: o que ela faz, do que ela depende e o que acontece se ela falhar. A resposta à terceira pergunta é o principal insumo para classificar criticidade e definir a estratégia de migração, que pode ir do simples rehost até a aposentadoria do workload.
Por que a avaliação pré-migração evita retrabalho e surpresas
Migrar sem avaliação prévia gera três tipos de surpresa recorrentes. A primeira é técnica: workloads que dependem de bibliotecas obsoletas, drivers de hardware específico ou versões de sistema operacional sem suporte no Azure falham na validação ou apresentam desempenho degradado. A segunda é financeira: provisionar recursos com base em especificação nominal — e não em consumo medido — leva a máquinas superdimensionadas que inflam a conta mensal. A terceira é operacional: equipes descobrem, no meio da migração, que não há janela de manutenção aprovada pelo negócio ou que a documentação de uma integração crítica simplesmente não existe.
O retrabalho aparece quando a migração precisa ser revertida ou refeita. Reverter um workload já em produção no Azure é mais caro do que corrigir um plano antes da execução, porque envolve sincronizar dados que continuaram mudando no ambiente de origem, reconfigurar DNS e identidade e, frequentemente, repetir testes de aceite. A avaliação prévia reduz a probabilidade de reversão ao antecipar incompatibilidades e dependências ocultas.
Há também o efeito sobre a credibilidade do projeto. Decisores de TI que apresentam um plano de migração baseado em inventário e métricas reais conseguem aprovar orçamento e janelas com mais facilidade do que aqueles que dependem de estimativas verbais. Em ambientes regulados — como os que processam transações via Pix ou dados sensíveis —, a documentação da avaliação também serve como evidência de due diligence para auditorias internas e externas.
Inventário: descobrir tudo o que roda no ambiente atual
O inventário é a fundação da avaliação. Ele responde a uma pergunta aparentemente simples — "o que existe no ambiente?" — que, em empresas de médio e grande porte, raramente tem resposta completa. Servidores esquecidos, máquinas virtuais órfãs, aplicações aposentadas que ainda consomem licença e bancos de dados de teste sem dono são achados comuns em assessments bem conduzidos.
Um inventário útil registra, para cada servidor ou serviço: nome, sistema operacional e versão, quantidade de vCPUs e memória alocada, disco provisionado e utilizado, endereço IP, VLAN, função declarada, dono do negócio, criticidade preliminar e existência de backup. Sem dono identificado, o workload não deveria migrar — a ausência de responsável indica provável ausência de requisitos documentados e de plano de testes.
Coleta automatizada versus levantamento manual
A coleta automatizada usa ferramentas como o Azure Migrate para descobrir servidores, medir consumo de recursos e mapear dependências de rede sem intervenção humana em cada máquina. Ela é mais rápida, menos sujeita a viés e captura dados de desempenho ao longo de semanas, revelando picos que um levantamento pontual não enxerga. A desvantagem é que a descoberta automática não captura contexto de negócio: não sabe qual aplicação é crítica para o fechamento contábil nem qual integração só roda no dia 5 de cada mês.
O levantamento manual complementa a coleta automatizada com entrevistas a donos de aplicação, revisão de documentação, análise de contratos de licenciamento e inspeção de rotinas agendadas. Ele é indispensável para workloads legados sem documentação ou com configurações fora do padrão. A combinação das duas abordagens — dados técnicos automatizados e contexto de negócio manual — é o padrão recomendado para assessments confiáveis.
Dependências entre aplicações, bancos e integrações
Mapear dependências significa identificar, para cada workload, quais outros sistemas ele consome e quais sistemas o consomem. Uma aplicação de pagamento pode depender de um banco SQL Server, de um serviço de mensageria, de uma API de antifraude e de um diretório Active Directory — e, se qualquer um desses componentes migrar isoladamente, a aplicação quebra.
As dependências se dividem em técnicas e temporais. Dependências técnicas são conexões de rede, portas, protocolos, bibliotecas compartilhadas e contas de serviço. Dependências temporais são janelas em que a integração acontece: lotes noturnos, fechamentos mensais, sincronizações em horário comercial. Um workload que só troca dados com outro às 2h da manhã pode parecer independente durante o dia e falhar na primeira madrugada após a migração.
Ferramentas de mapeamento de dependências baseadas em agente, disponíveis no Azure Migrate, geram mapas visuais das conexões entre servidores e processos. Esses mapas são o ponto de partida para agrupar workloads que precisam migrar juntos — os chamados "grupos de migração" — e para identificar conexões órfãs que apontam para servidores já desligados ou funções obsoletas.
Como classificar workloads por criticidade e padrão de uso
Depois do inventário, cada workload recebe uma classificação de criticidade que combina impacto de negócio, requisitos de disponibilidade e sensibilidade dos dados. A classificação não é um exercício acadêmico: ela define a ordem de migração, o nível de redundância necessário no Azure, o regime de testes exigido e o investimento em contingência.
Uma escala simples e eficaz tem três níveis:
- Crítico: parada causa prejuízo financeiro direto, violação contratual ou risco regulatório.
- Importante: parada degrada a operação, mas há contorno manual por horas ou dias.
- Acessório: parada tem impacto baixo e tolerância a indisponibilidade prolongada.
Workloads críticos exigem estratégia de migração com replicação contínua, testes de corte rigorosos e plano de reversão documentado. Workloads acessórios podem servir de laboratório para validar o processo de migração com risco controlado.
Sazonalidade, picos e janelas de manutenção
O padrão de uso de um workload raramente é constante. Sistemas de folha de pagamento têm pico nos dias de processamento; e-commerces concentram tráfego em datas promocionais; aplicações financeiras enfrentam picos em horários de compensação bancária. Avaliar apenas a média de consumo esconde esses picos e leva a um dimensionamento incorreto no Azure.
A coleta de métricas deve cobrir pelo menos um ciclo completo de negócio — idealmente 30 dias, incluindo fechamento mensal e, quando aplicável, datas sazonais. O dimensionamento no Azure usa os percentis 95 ou 99 de consumo, não a média, para garantir folga nos momentos de pico sem superdimensionar o restante do tempo.
As janelas de manutenção precisam ser levantadas com o dono do negócio, não presumidas pela equipe de TI. Um sistema contábil pode ter janela aprovada apenas no primeiro domingo do mês; um sistema de pagamentos pode não ter janela alguma durante o horário de funcionamento do Pix. Migrar fora da janela aprovada transforma um problema técnico em um problema de negócio — e costuma escalar rápido.
Workloads que não podem parar durante a migração
Alguns workloads exigem migração com downtime próximo de zero. Sistemas de pagamento, plataformas de atendimento ao cliente, ERPs em uso contínuo e aplicações de missão crítica em saúde ou finanças entram nessa categoria. Para eles, a avaliação precisa responder não apenas "o que migrar", mas "como manter as duas pontas sincronizadas durante a transição".
As opções técnicas incluem replicação contínua com ferramentas como Azure Site Recovery, espelhamento de banco de dados, log shipping ou sincronização em nível de aplicação. Cada opção tem requisitos próprios de largura de banda, latência entre origem e Azure, e compatibilidade com o sistema operacional e o banco de dados. A escolha errada aqui gera perda de dados ou indisponibilidade — os dois piores desfechos possíveis em uma migração.
Os seis critérios de avaliação de um workload
Para tornar a decisão de migração objetiva, cada workload deve ser pontuado em seis critérios. A pontuação alimenta uma matriz de decisão que indica a estratégia de destino e a ordem de migração, eliminando decisões baseadas em preferência pessoal ou em quem grita mais alto na reunião.
Compatibilidade técnica e sistema operacional
O Azure suporta uma ampla gama de sistemas operacionais, mas nem todos com o mesmo nível de suporte. Windows Server 2008 e 2008 R2, por exemplo, saíram do suporte estendido da Microsoft — e, embora possam rodar no Azure, exigem Extended Security Updates pagos ou modernização imediata. Distribuições Linux fora do catálogo de imagens suportadas podem rodar com kernel próprio, mas sem garantia de suporte da Microsoft.
A avaliação de compatibilidade inclui arquitetura de processador (x64 versus ARM), requisitos de drivers específicos, presença de agentes de terceiros incompatíveis e dependência de recursos de virtualização não suportados no hipervisor do Azure. Workloads com alta pontuação de compatibilidade são candidatos naturais a rehost; os incompatíveis exigem replatform ou refatoração.
Dependências de rede, latência e identidade
Workloads que dependem de latência baixa entre componentes — como aplicação e banco de dados no mesmo segmento de rede — precisam de planejamento de topologia no Azure: redes virtuais, peering, grupos de segurança e, quando necessário, ExpressRoute para conexão dedicada com o ambiente on-premises. Migrar a aplicação para o Azure e deixar o banco on-premises pode funcionar, mas a latência entre os dois precisa ser medida e validada antes do corte.
Identidade é outro ponto crítico. Workloads autenticados contra Active Directory on-premises exigem sincronização com Microsoft Entra ID (antigo Azure AD), decisão entre Entra Connect e cloud-only, e validação de protocolos de autenticação legados como NTLM ou Kerberos. Aplicações que usam autenticação integrada do Windows frequentemente falham em cenários cloud-only sem um plano de modernização de identidade.
Requisitos de segurança, compliance e residência de dados
Workloads que processam dados sensíveis — informações financeiras, dados pessoais sob LGPD, transações Pix — carregam requisitos que vão além da técnica. A avaliação deve mapear: onde os dados podem residir fisicamente (regiões do Azure no Brasil, por exemplo), quais controles de criptografia são exigidos em repouso e em trânsito, quais logs de auditoria precisam ser preservados e por quanto tempo, e quais certificações o provedor precisa manter.
Para o setor financeiro, há ainda requisitos específicos de instituições reguladoras e de arranjos de pagamento. A avaliação precisa documentar esses requisitos workload a workload, porque dois sistemas da mesma empresa podem ter obrigações de compliance diferentes. Um ambiente de homologação com dados mascarados, por exemplo, tem exigências mais leves do que um ambiente de produção com dados reais de clientes.
A residência de dados é um critério de decisão binário em alguns casos: se um workload não pode ter dados fora do Brasil, a região Azure Brazil South (São Paulo) entra como requisito obrigatório — e serviços que ainda não estão disponíveis nessa região ficam vetados para esse workload.
Acoplamento com hardware ou licenças legadas
Workloads acoplados a hardware físico são os mais difíceis de migrar. Isso inclui aplicações que dependem de dongles USB, de placas específicas de criptografia, de dispositivos de telemetria conectados por porta serial ou de storage com características que o disco gerenciado do Azure não reproduz. Nesses casos, a migração direta é impossível — a avaliação precisa identificar o acoplamento cedo para planejar replatform, virtualização do componente ou substituição da aplicação.
Licenças atreladas a núcleos físicos ou a hardware específico também travam a migração. Alguns softwares legados licenciam por socket do processador físico, e mover para o Azure — onde o hardware é abstrato — pode exigir renegociação de contrato ou migração para licenciamento por núcleo virtual. O custo dessa renegociação precisa entrar no business case, senão a economia de infraestrutura desaparece na conta de licenciamento.
Impacto operacional e capacidade da equipe
Migrar um workload para o Azure não elimina o trabalho operacional — ele muda de natureza. A equipe que hoje administra servidores físicos ou VMware precisa operar máquinas virtuais no Azure, entender grupos de segurança, gerenciar custos por assinatura, configurar monitoramento e responder a incidentes em um ambiente que ela talvez ainda não domine.
A avaliação deve medir a maturidade da equipe em relação a cada workload migrado. Um workload crítico migrado para uma equipe sem experiência em Azure é um risco operacional novo, não uma redução de risco. O plano de migração precisa incluir capacitação, documentação de runbooks e, quando a lacuna for grande, apoio externo durante a transição.
Esse critério também considera a carga operacional atual: se a equipe já opera no limite da capacidade, adicionar workloads no Azure sem reduzir o legado on-premises aumenta o risco de incidentes por sobrecarga. A avaliação honesta da capacidade da equipe evita que a migração vire uma crise de burnout.
O que define o custo de manter o workload no Azure
O custo de um workload no Azure é definido por quatro vetores principais. O primeiro é o dimensionamento: quantidade de vCPUs, memória e tipo de disco provisionado, que devem refletir o consumo medido — não a configuração nominal do servidor atual. O segundo é o padrão de uso: workloads que rodam 24x7 custam diferente de workloads que podem ser desligados fora do horário comercial ou escalados para baixo nos fins de semana.
O terceiro vetor é a estratégia de serviço: usar máquinas virtuais IaaS custa diferente de usar serviços gerenciados como Azure SQL Database, App Service ou Functions. O quarto é o compromisso de uso: contratos de um ou três anos (reserved instances) e savings plans reduzem o custo em troca de compromisso — mas só fazem sentido para workloads com previsibilidade de consumo.
A avaliação precisa projetar o custo mensal de cada workload no Azure usando a calculadora oficial e os dados de consumo medidos. Essa projeção alimenta o business case e permite comparar, em números, o custo atual on-premises — incluindo energia, refrigeração, licenças, hardware depreciado e mão de obra — com o custo projetado em nuvem.
Escolhendo a estratégia de destino: rehost, replatform, refatorar ou aposentar
A matriz de decisão cruza a pontuação dos seis critérios com quatro estratégias de destino possíveis:
- Rehost (lift and shift): mover o workload como está, sem mudanças de arquitetura. Indicado para workloads compatíveis, com baixa criticidade ou prazo curto de migração.
- Replatform: pequenas mudanças para aproveitar serviços gerenciados — por exemplo, trocar SQL Server em VM por Azure SQL Managed Instance. Reduz custo operacional sem reescrever a aplicação.
- Refatorar: reescrever ou reestruturar a aplicação para arquitetura nativa de nuvem. Custo alto e prazo longo; indicado para workloads estratégicos com vida útil longa pela frente.
- Aposentar: desligar o workload porque ele não tem mais função de negócio ou porque o custo de migração supera o benefício.
A decisão de aposentar é frequentemente negligenciada. Servidores órfãos, aplicações duplicadas e ambientes de teste abandonados costumam aparecer no inventário. Aposentar antes de migrar reduz o escopo do projeto e libera orçamento para os workloads que realmente importam.
Workloads que não devem migrar — por acoplamento irreversível a hardware, por requisito regulatório de permanência on-premises ou por latência incompatível com a distância até a região Azure — precisam ser explicitamente classificados como "permanecer on-premises". Essa decisão, documentada, evita que o workload volte a aparecer como candidato a migração em ciclos futuros sem uma reavaliação formal.
A estratégia escolhida não é definitiva para sempre. Um workload pode entrar no Azure via rehost para ganhar velocidade e, meses depois, passar por replatform para reduzir custo operacional. O que a avaliação entrega é a decisão inicial fundamentada — e o registro dos critérios que a sustentaram, para que revisões futuras tenham ponto de partida.
Ferramentas que apoiam a avaliação no Azure
O ecossistema de ferramentas da Microsoft cobre a maior parte do processo de avaliação, da descoberta ao custo projetado. Usar essas ferramentas — em vez de planilhas manuais — acelera o assessment e reduz erro humano na coleta de dados.
Azure Migrate e avaliação baseada em agente
O Azure Migrate é o hub central de descoberta e avaliação. Ele descobre servidores on-premises (VMware, Hyper-V, servidores físicos), coleta métricas de desempenho, mapeia dependências entre máquinas e gera recomendações de tamanho de VM no Azure com base no consumo real. A avaliação pode ser sem agente — usando o appliance do Azure Migrate — ou baseada em agente, com instalação de agentes em cada servidor para capturar dependências em nível de processo e conexão.
A avaliação baseada em agente é mais invasiva, mas entrega o mapa de dependências que a descoberta sem agente não consegue produzir com a mesma granularidade. Para workloads críticos, onde uma dependência não mapeada pode causar falha no corte, o esforço adicional do agente se justifica. Para ambientes grandes e homogêneos, a descoberta sem agente cobre a maior parte da necessidade com menos atrito.
Azure Advisor, Cost Management e dependências
Depois que os primeiros workloads migram, o Azure Advisor passa a emitir recomendações de otimização: máquinas superdimensionadas, discos sem uso, recursos ociosos e configurações de segurança que merecem atenção. Essas recomendações alimentam o ciclo contínuo de avaliação — o assessment não termina na migração, ele vira rotina de otimização.
O Microsoft Cost Management consolida o custo real por workload, assinatura, grupo de recursos ou tag. Comparar o custo projetado na avaliação com o custo real após a migração revela desvios de dimensionamento e permite corrigir rapidamente. A prática de etiquetar (taggear) cada recurso com o nome do workload e o dono do negócio é pré-requisito para que o Cost Management produza relatórios úteis — sem tags, o custo vira uma massa indistinta impossível de atribuir.
Para workloads com dados sensíveis, a avaliação de dependências também precisa considerar o plano de proteção de dados no destino. A forma como o backup será executado no Azure — com políticas de retenção, backup imutável contra ransomware e testes de restauração — deve estar definida antes do corte, não depois.
Como priorizar a ordem de migração: ondas e quick wins
A ordem de migração não deve seguir a conveniência técnica nem a pressão política. Ela deriva da matriz de decisão: workloads com baixa criticidade, alta compatibilidade e poucas dependências formam a primeira onda — os quick wins que validam o processo, geram aprendizado para a equipe e constroem confiança no projeto.
Workloads críticos com muitas dependências entram nas ondas finais, depois que a equipe já executou migrações menores e dominou o processo. A exceção são workloads cujo custo on-premises é tão alto — hardware em fim de vida, licenças vencendo, contrato de datacenter encerrando — que a urgência financeira justifica antecipá-los, desde que com plano de contingência robusto.
As ondas precisam respeitar os grupos de dependência mapeados no inventário: aplicação e banco de dados que se comunicam com latência baixa devem migrar na mesma onda, ou em ondas adjacentes com validação de latência entre elas. Migrar o banco em uma onda e a aplicação três meses depois pode funcionar tecnicamente, mas exige medir e validar a latência entre os dois ambientes antes de cada etapa.
Uma referência útil para definir a ordem é o plano de continuidade existente: workloads que já possuem backup em ambiente híbrido têm um risco de migração menor, porque a proteção de dados já está resolvida independentemente de onde o workload roda.
Erros comuns na avaliação de workloads e como evitá-los
O primeiro erro é avaliar com base em configuração nominal em vez de consumo medido. Servidores provisionados com 16 vCPUs e 64 GB de RAM que usam 20% disso geram recomendações de VM no Azure muito maiores do que o necessário — e a conta mensal acompanha o exagero. A correção é simples: coletar métricas por pelo menos 30 dias e dimensionar pelo percentil 95.
O segundo erro é ignorar dependências ocultas. Workloads que parecem independentes no inventário superficial revelam conexões com bancos de dados, APIs ou serviços de autenticação apenas quando o mapa de dependências é gerado. Pular o mapeamento de dependências em workloads críticos é a causa mais comum de falhas no corte.
O terceiro erro é não envolver o dono do negócio na avaliação. A TI pode mapear a técnica, mas só o dono da aplicação sabe que o sistema de cobrança não pode parar no dia 25, que a integração com o banco roda apenas em dias úteis ou que a janela de manutenção aprovada é a madrugada de domingo. Avaliações feitas apenas pela TI tendem a subestimar criticidade e a escolher janelas erradas.
O quarto erro é tratar a avaliação como um evento único. Workloads mudam: novas versões, novas integrações, novas exigências de compliance. O assessment precisa ser revisitado periodicamente, e as métricas de custo e desempenho pós-migração precisam alimentar a próxima rodada de decisões.
O quinto erro é subestimar o esforço de licenciamento. Workloads com licenças atreladas a hardware, contratos de suporte legados ou software de terceiros com restrição de execução em nuvem podem inviabilizar a economia projetada. A avaliação de licenças precisa ser feita com o fornecedor ou com um especialista em licenciamento Microsoft, não presumida pela equipe interna.
O sexto erro é não planejar a proteção de dados no destino antes do corte. A migração move o workload, mas a responsabilidade pelo backup, pela retenção e pela capacidade de restaurar continua da empresa. Definir a estratégia de backup do SQL Server e das demais cargas antes da migração evita a janela perigosa em que o workload já está no Azure mas ainda não tem backup configurado.
Checklist de avaliação antes de aprovar a migração de um workload
O checklist de aprovação (go/no-go) consolida os critérios da avaliação em uma lista objetiva. Se qualquer item essencial não estiver respondido, o workload não entra na onda de migração — ele volta para a fase de levantamento até que a lacuna seja fechada.
- Inventário completo: servidor, sistema operacional, recursos alocados e consumidos, dono do negócio identificado.
- Dependências mapeadas: conexões de rede, bancos de dados, integrações e rotinas agendadas documentadas.
- Criticidade classificada: nível crítico, importante ou acessório definido com o dono do negócio.
- Compatibilidade validada: sistema operacional, arquitetura e drivers confirmados como suportados no Azure.
- Requisitos de compliance documentados: residência de dados, criptografia, auditoria e certificações exigidas.
- Licenças verificadas: acoplamento com hardware e contratos de licenciamento analisados.
- Estratégia de destino definida: rehost, replatform, refatorar, aposentar ou permanecer on-premises.
- Custo projetado aprovado: estimativa mensal no Azure validada contra o custo atual.
- Janela de manutenção aprovada: data e horário confirmados pelo dono do negócio.
- Plano de contingência documentado: procedimento de reversão e teste de restore validado antes do corte.
- Backup no destino configurado: política de proteção de dados ativa no Azure antes da entrada em produção.
- Equipe preparada: capacitação concluída e runbooks operacionais disponíveis.
O checklist funciona como um contrato entre a equipe de migração e o dono do workload: cada item marcado é uma decisão documentada, não uma suposição. Em ambientes regulados, esse registro é a evidência de que a migração seguiu um processo estruturado — o que reduz o risco de questionamento em auditorias e facilita a prestação de contas à diretoria.
A avaliação pré-migração não elimina todos os riscos de uma migração para o Azure — nenhum processo elimina. Mas ela transforma riscos desconhecidos em riscos conhecidos, que podem ser gerenciados, mitigados ou aceitos com fundamento. Para workloads que processam dados sensíveis e transações financeiras, essa diferença é o que separa um projeto de migração bem-sucedido de um incidente com consequências regulatórias e reputacionais.
