Migrar workloads para o Microsoft Azure não começa pela criação de máquinas virtuais, redes ou subscriptions. Começa pela compreensão detalhada do ambiente atual. Um assessment de infraestrutura Azure permite identificar dependências, gargalos, riscos, requisitos de segurança, capacidade, performance e custos antes que essas variáveis impactem o projeto de migração.
Em projetos corporativos de Cloud Migration, a simples transferência de workloads de um ambiente on-premises para a nuvem raramente é suficiente. Antes de definir o target architecture, é necessário compreender como aplicações, bancos de dados, servidores, redes, identidades, serviços e processos operacionais estão relacionados.
Além disso, uma infraestrutura considerada “Azure-ready” não significa apenas que os servidores podem ser tecnicamente executados no Azure. Significa que existe evidência suficiente para determinar o que migrar, como migrar, em qual ordem, para qual arquitetura e sob quais requisitos de segurança, disponibilidade, performance e custo.
Por isso, um assessment de infraestrutura Azure deve ser tratado como uma etapa de engenharia e arquitetura, e não apenas como um inventário de servidores.
O que significa estar Azure-ready?
Estar Azure-ready significa que a organização possui informações técnicas suficientes para tomar decisões seguras sobre a adoção do Azure.
Na prática, isso envolve muito mais do que descobrir quantos servidores existem no ambiente.
É necessário compreender:
- Quais workloads existem.
- Quais aplicações dependem de cada workload.
- Quais bancos de dados sustentam essas aplicações.
- Quais servidores possuem dependências críticas.
- Quais portas e protocolos são utilizados.
- Quais workloads possuem requisitos de baixa latência.
- Quais sistemas precisam de alta disponibilidade.
- Quais dados possuem requisitos regulatórios.
- Quais componentes podem ser modernizados.
- Quais workloads devem permanecer on-premises.
- Quais recursos podem ser migrados para IaaS.
- Quais componentes são candidatos a PaaS.
- Quais workloads podem ser refatorados.
- Qual será o impacto financeiro da arquitetura proposta.
Consequentemente, a avaliação de prontidão deve considerar tanto aspectos técnicos quanto requisitos de negócio.
O próprio Azure Well-Architected Framework organiza a avaliação arquitetural em cinco pilares: Reliability, Security, Cost Optimization, Operational Excellence e Performance Efficiency. Esses pilares ajudam a estruturar as decisões e os trade-offs de uma arquitetura Azure.
Por que o assessment deve acontecer antes da migração?
Um dos erros mais comuns em projetos de Cloud Migration é iniciar a construção do ambiente Azure antes de compreender completamente o ambiente de origem.
Esse cenário pode gerar problemas como:
- Dimensionamento incorreto de recursos.
- Subdimensionamento de workloads críticos.
- Superdimensionamento de máquinas virtuais.
- Custos recorrentes superiores ao esperado.
- Dependências não identificadas.
- Regras de firewall esquecidas.
- Aplicações com baixa tolerância à latência.
- Falhas de autenticação.
- Problemas de integração.
- Indisponibilidade durante o cutover.
- Arquiteturas inadequadas para crescimento futuro.
Por outro lado, quando o assessment é realizado antes da migração, a organização consegue construir uma visão baseada em evidências.
Isso permite transformar perguntas genéricas, como “podemos migrar para o Azure?”, em perguntas tecnicamente mensuráveis:
Qual workload deve ser migrado primeiro?
Qual SKU atende aos requisitos de performance?
Quais dependências precisam permanecer conectadas ao ambiente on-premises?
Qual será o impacto da latência entre componentes?
Quais workloads podem ser modernizados?
Qual arquitetura atende aos requisitos de RTO e RPO?
Qual será o custo operacional estimado?
Esse nível de informação reduz significativamente a incerteza do projeto.
Assessment de infraestrutura Azure: o que deve ser analisado?
Um assessment técnico de qualidade precisa trabalhar com múltiplas camadas.
Avaliar somente CPU, memória e armazenamento é insuficiente.
1. Inventário de workloads
O primeiro passo é construir um inventário confiável do ambiente.
Nesse inventário devem ser identificados servidores físicos, máquinas virtuais, appliances, bancos de dados, aplicações, serviços de infraestrutura e componentes de integração.
Para cada workload, é importante coletar informações como:
- Sistema operacional.
- Versão.
- CPU.
- Memória.
- Storage.
- IOPS.
- Throughput.
- Utilização média e de pico.
- Interfaces de rede.
- Dependências.
- Serviços instalados.
- Aplicações hospedadas.
- Banco de dados utilizado.
- Criticidade.
- Ambiente de produção, homologação ou desenvolvimento.
- Requisitos de disponibilidade.
Além disso, o inventário precisa ser relacionado aos serviços de negócio.
Um servidor isoladamente pode parecer pouco relevante. Entretanto, quando associado a um ERP, CRM ou sistema financeiro, sua criticidade muda completamente.
2. Análise de dependências entre workloads
A análise de dependências é uma das etapas mais importantes de qualquer Cloud Migration.
Imagine uma aplicação instalada em um servidor Windows que depende de:
- SQL Server.
- Active Directory.
- File Server.
- API interna.
- Serviço de autenticação.
- Serviço externo.
- Servidor de aplicação.
- Sistema legado.
Se esses relacionamentos não forem conhecidos, migrar apenas o servidor da aplicação pode resultar em uma arquitetura funcionalmente incompleta.
O Azure Migrate possui recursos de Discovery and Assessment e Dependency Analysis para ajudar a visualizar dependências entre servidores e construir grupos de migração com maior nível de confiança. A análise de dependências pode utilizar dados de conexão entre servidores para identificar relações que não seriam facilmente percebidas apenas pelo inventário.
Portanto, a pergunta não deve ser apenas:
“Qual servidor será migrado?”
A pergunta correta é:
“Qual conjunto de componentes precisa ser migrado ou mantido conectado para que o workload continue operacional?”
3. Capacity Planning e análise de performance
Outro ponto crítico é dimensionar o ambiente Azure com base em dados reais.
Uma abordagem superficial pode simplesmente replicar a configuração atual.
Por exemplo:
Servidor atual:
- 8 vCPUs
- 32 GB RAM
- 1 TB Storage
Isso não significa automaticamente que o Azure deva receber uma VM com exatamente a mesma configuração.
É necessário observar o comportamento real do workload.
Entre as métricas relevantes estão:
- CPU utilization.
- Memory utilization.
- Disk latency.
- IOPS.
- Throughput.
- Network throughput.
- Read/write ratio.
- Picos de utilização.
- Sazonalidade.
- Concorrência.
- Tempo de resposta.
O Azure Migrate permite avaliações baseadas em configuração atual ou em dados de performance. No modelo baseado em performance, CPU, memória, IOPS e throughput são utilizados para ajudar no dimensionamento do target.
Isso é especialmente importante porque uma migração baseada apenas no tamanho atual pode gerar overprovisioning.
E overprovisioning significa pagar continuamente por capacidade que talvez não esteja sendo utilizada.
4. Right-sizing de workloads
O right-sizing é uma das atividades mais importantes antes da migração.
O objetivo não é simplesmente escolher a maior VM possível.
O objetivo é encontrar o ponto de equilíbrio entre:
Performance + disponibilidade + escalabilidade + custo.
Por exemplo, uma aplicação pode possuir 16 vCPUs disponíveis, mas utilizar apenas 20% da capacidade na maior parte do tempo.
Nesse cenário, simplesmente replicar o ambiente pode gerar desperdício.
Por outro lado, reduzir excessivamente os recursos também pode criar um gargalo depois da migração.
Portanto, o dimensionamento deve considerar dados históricos e requisitos futuros.
Avaliações baseadas em performance podem utilizar métricas coletadas do ambiente para determinar recomendações de compute e storage mais próximas do comportamento real do workload.
5. Avaliação de rede e conectividade
Migrar workloads para Azure altera o modelo de comunicação entre componentes.
Em um ambiente on-premises, aplicações podem estar separadas por poucos milissegundos de latência.
Depois da migração, determinados componentes podem estar:
- Em diferentes Virtual Networks.
- Em diferentes regiões.
- Em diferentes subscriptions.
- Atrás de firewalls.
- Conectados por VPN.
- Conectados por ExpressRoute.
- Em arquiteturas hub-and-spoke.
Consequentemente, a rede precisa ser analisada como parte da arquitetura da aplicação.
O assessment deve considerar:
- IP addressing.
- DNS.
- Routing.
- Firewall.
- NAT.
- NSG.
- Network Virtual Appliance.
- VPN.
- ExpressRoute.
- Latência.
- Throughput.
- Segmentação.
- Dependências externas.
Uma arquitetura Azure-ready precisa ter conectividade compatível com os requisitos dos workloads.
6. Identidade e controle de acesso
Outro ponto frequentemente subestimado é identidade.
Em ambientes corporativos, a migração para Azure normalmente envolve integração com Microsoft Entra ID, Active Directory Domain Services ou arquiteturas híbridas.
Nesse contexto, devem ser analisados:
- Domínios.
- Trust relationships.
- DNS.
- GPOs.
- Service Accounts.
- Managed Identities.
- RBAC.
- Privileged Access.
- MFA.
- Conditional Access.
- PIM.
- Administração delegada.
A identidade é uma das principais fronteiras de segurança em uma arquitetura cloud.
Além disso, o modelo de acesso precisa respeitar o princípio de menor privilégio e separar responsabilidades administrativas.
As orientações atuais do Azure Landing Zone tratam identidade e controle de acesso como uma área fundamental da arquitetura, incluindo RBAC, Microsoft Entra ID, PIM e modelos de acesso just-in-time.
7. Segurança e Zero Trust
A migração para Azure também representa uma oportunidade para revisar o modelo de segurança.
Migrar uma infraestrutura insegura para a nuvem não transforma automaticamente essa infraestrutura em segura.
Pelo contrário, configurações inadequadas podem ampliar a superfície de ataque.
Por isso, o assessment deve verificar:
- Exposição de portas.
- Serviços publicados.
- Regras de firewall.
- Segmentação de rede.
- Contas privilegiadas.
- Credenciais.
- Criptografia.
- Gestão de chaves.
- Logs.
- Monitoramento.
- Vulnerabilidades.
- Políticas de segurança.
- Acesso administrativo.
Além disso, princípios de Zero Trust podem ser incorporados à arquitetura desde o início.
Entre as estratégias recomendadas estão segmentação de rede, controle de acesso baseado em identidade, políticas de segurança e redução de privilégios administrativos.
8. Alta disponibilidade e Disaster Recovery
Nem todo workload possui o mesmo requisito de disponibilidade.
Por isso, o assessment deve classificar as aplicações de acordo com sua criticidade.
Uma aplicação pode aceitar algumas horas de indisponibilidade.
Outra pode exigir recuperação em minutos.
Consequentemente, devem ser definidos:
RTO: Recovery Time Objective.
RPO: Recovery Point Objective.
Esses parâmetros influenciam diretamente a arquitetura.
Dependendo do workload, podem ser necessários mecanismos como:
- Availability Zones.
- Azure Site Recovery.
- Azure Backup.
- Replicação.
- Redundância.
- Geo-redundancy.
- Failover.
- Estratégias de recuperação.
Além disso, o Disaster Recovery deve ser validado por testes.
Uma estratégia de recuperação que nunca foi testada é apenas uma hipótese.
9. Governança e Azure Landing Zones
Outro componente fundamental é a arquitetura da plataforma Azure.
Antes de distribuir workloads em subscriptions, é necessário definir como o ambiente será organizado.
Nesse contexto entram conceitos como:
- Management Groups.
- Subscriptions.
- Resource Groups.
- Azure Policy.
- RBAC.
- Tags.
- Naming Convention.
- Azure Monitor.
- Log Analytics.
- Defender for Cloud.
- Network Topology.
- Cost Management.
- Automation.
- Infrastructure as Code.
A abordagem de Azure Landing Zones fornece uma arquitetura padronizada para estabelecer uma fundação escalável, considerando identidade, organização de recursos, rede, segurança, governança, gerenciamento e automação.
Portanto, não é recomendável simplesmente criar subscriptions e começar a migrar servidores.
Primeiro deve existir uma fundação.
Depois, os workloads podem ser posicionados dentro dessa fundação.
10. FinOps e estimativa de custos
Um dos maiores riscos de uma migração mal planejada é transformar um projeto tecnicamente bem-sucedido em um problema financeiro.
Cloud não significa automaticamente redução de custos.
O custo depende de arquitetura, utilização, modelo de contratação, armazenamento, transferência de dados, redundância, licenciamento e comportamento dos workloads.
Por isso, o assessment deve construir uma baseline financeira.
Devem ser considerados:
- Compute.
- Storage.
- Backup.
- Network.
- Data transfer.
- Licenciamento.
- Monitoring.
- Security.
- Disaster Recovery.
- Managed Services.
- Reserved capacity.
- Savings Plans.
- Crescimento projetado.
Além disso, o modelo financeiro precisa considerar o crescimento futuro.
O Azure Well-Architected Framework destaca que Cost Optimization não significa simplesmente buscar o menor preço. A otimização exige equilíbrio entre custo, performance, segurança, confiabilidade e requisitos de negócio.
11. Compatibilidade e estratégia de migração
Depois de compreender o ambiente, cada workload deve receber uma classificação de migração.
Uma estratégia tradicional pode considerar:
Rehost
Também conhecido como lift-and-shift.
O workload é movido para Azure com poucas alterações.
Replatform
O workload é adaptado para utilizar serviços gerenciados ou componentes mais adequados ao Azure.
Refactor
A aplicação é modificada para aproveitar recursos cloud-native.
Retire
Workloads obsoletos são descontinuados.
Retain
Determinados componentes permanecem no ambiente atual por requisitos técnicos, regulatórios ou estratégicos.
Repurchase
A organização substitui determinada solução por uma alternativa SaaS ou serviço equivalente.
A escolha depende do workload.
Não existe uma única estratégia correta para todo o ambiente.
12. Azure Migrate como ferramenta de descoberta e assessment
O Azure Migrate pode ser utilizado como componente importante da etapa de descoberta e avaliação.
A plataforma permite descobrir workloads, coletar informações do ambiente e realizar assessments para workloads candidatos à migração.
Além disso, avaliações podem considerar critérios de sizing, performance, readiness e estimativas relacionadas ao ambiente de destino.
Entretanto, é importante fazer uma distinção.
Ferramenta de assessment não substitui arquitetura.
Os dados coletados precisam ser interpretados por profissionais capazes de compreender:
- Arquitetura.
- Dependências.
- Performance.
- Segurança.
- Networking.
- Operação.
- Continuidade.
- Custos.
- Requisitos de negócio.
O resultado de uma ferramenta é um insumo para decisão.
A decisão arquitetural continua sendo uma responsabilidade técnica.
13. Como deve ser o resultado de um assessment?
Um assessment de infraestrutura Azure bem executado deve gerar mais do que uma lista de servidores.
O resultado deveria apresentar uma visão estruturada do ambiente.
Entre os principais entregáveis estão:
Inventário técnico
Mapeamento dos workloads e seus componentes.
Matriz de dependências
Relacionamento entre aplicações, servidores, bancos de dados e serviços.
Classificação de criticidade
Identificação dos workloads críticos para o negócio.
Readiness assessment
Identificação de workloads aptos, parcialmente aptos ou que exigem intervenção antes da migração.
Right-sizing
Recomendação de capacidade para o ambiente Azure.
Análise financeira
Estimativa de custos e oportunidades de otimização.
Target Architecture
Definição da arquitetura de destino.
Landing Zone
Definição da fundação necessária para receber os workloads.
Migration Waves
Organização dos workloads em ondas de migração.
Risk Register
Mapeamento de riscos técnicos, operacionais e financeiros.
Roadmap
Sequenciamento das ações necessárias para chegar ao ambiente desejado.
14. Como definir as ondas de migração?
A migração não deve ser organizada simplesmente pela ordem em que os servidores aparecem no inventário.
É necessário considerar dependências e criticidade.
Uma abordagem madura pode classificar workloads em grupos:
Wave 0
Fundação, conectividade, identidade, segurança, monitoramento e governança.
Wave 1
Workloads de baixa criticidade e baixa complexidade.
Wave 2
Workloads com dependências moderadas.
Wave 3
Aplicações críticas e bancos de dados corporativos.
Wave 4
Workloads complexos, legados ou candidatos à modernização.
Essa abordagem permite validar a arquitetura progressivamente.
Além disso, cada onda pode gerar aprendizado para a seguinte.
15. O que pode impedir uma infraestrutura de estar Azure-ready?
Alguns problemas aparecem repetidamente em assessments corporativos.
Entre eles:
- Sistemas operacionais obsoletos.
- Aplicações sem suporte do fabricante.
- Dependências desconhecidas.
- Banco de dados sem estratégia de HA/DR.
- Storage com performance insuficiente.
- Aplicações altamente acopladas.
- Endereçamento IP incompatível.
- DNS dependente de infraestrutura local.
- Service Accounts sem estratégia de identidade.
- Falta de documentação.
- Ausência de monitoramento.
- Falta de governança.
- Dados sensíveis sem classificação.
- Ausência de política de backup.
- Falta de estratégia de rollback.
Portanto, identificar esses pontos antes da migração é uma das principais funções do assessment.
Azure-ready não significa apenas “pode rodar no Azure”
Essa é talvez a principal conclusão deste processo.
Um workload pode ser tecnicamente compatível com Azure e, mesmo assim, não estar preparado para uma migração segura.
Imagine uma aplicação que pode ser executada em uma Azure Virtual Machine.
Tecnicamente, ela pode funcionar.
Entretanto, se:
- depende de um servidor local;
- possui banco de dados com baixa performance;
- depende de IP fixo;
- utiliza uma conta administrativa compartilhada;
- não possui backup adequado;
- não possui estratégia de Disaster Recovery;
- possui uma aplicação cliente sensível à latência;
então simplesmente mover a VM não resolve o problema.
Por isso, Azure readiness deve ser analisado como uma combinação de compatibilidade técnica, arquitetura, segurança, operação, performance, disponibilidade e viabilidade financeira.
Qual a relação entre assessment e modernização?
Um assessment também pode revelar que simplesmente migrar o workload não é a melhor alternativa.
Por exemplo, uma aplicação pode atualmente depender de:
- Windows Server.
- SQL Server.
- File Server.
- IIS.
- Scripts agendados.
- Jobs.
- Serviços Windows.
Durante a análise, pode ser identificado que parte dessa arquitetura poderia ser modernizada utilizando serviços gerenciados.
Nesse cenário, o projeto deixa de ser apenas uma migração.
Passa a ser uma transformação arquitetural.
Essa distinção é importante porque uma arquitetura cloud-native pode apresentar benefícios significativos em escalabilidade, operação e automação.
Por outro lado, modernização aumenta complexidade e exige análise de impacto.
Portanto, a decisão deve ser baseada em requisitos técnicos e de negócio, e não apenas na tendência de utilizar serviços PaaS.
O papel do Azure Well-Architected Framework
Depois do assessment, a arquitetura proposta deve ser validada considerando os princípios do Azure Well-Architected Framework.
Os cinco pilares são:
Reliability
Capacidade de continuar funcionando e se recuperar de falhas.
Security
Proteção de identidade, dados, aplicações e infraestrutura.
Cost Optimization
Uso eficiente dos recursos considerando retorno e requisitos.
Operational Excellence
Capacidade de operar, monitorar e evoluir o ambiente.
Performance Efficiency
Capacidade de entregar desempenho adequado utilizando os recursos de forma eficiente.
Esses pilares não devem ser avaliados isoladamente.
Existe uma relação direta entre eles.
Por exemplo, reduzir custos diminuindo recursos pode afetar performance.
Aumentar redundância pode elevar custos.
Adicionar controles de segurança pode aumentar complexidade operacional.
Por isso, arquitetura é essencialmente um exercício de trade-offs.
Checklist técnico para saber se sua infraestrutura está Azure-ready
Antes de iniciar uma migração corporativa, vale verificar:
- Existe inventário atualizado dos workloads?
- As dependências entre servidores estão documentadas?
- Os workloads críticos estão identificados?
- Existe histórico de utilização de CPU e memória?
- Storage, IOPS e throughput foram analisados?
- Existe estratégia de right-sizing?
- A conectividade com Azure foi definida?
- DNS e identidade foram avaliados?
- Existe estratégia de RBAC?
- O princípio de menor privilégio foi considerado?
- Os requisitos de segurança foram definidos?
- Os workloads possuem classificação de dados?
- RTO e RPO foram definidos?
- Backup e Disaster Recovery foram avaliados?
- Existe arquitetura de Landing Zone?
- Management Groups e subscriptions foram planejados?
- Azure Policy foi considerada?
- Monitoramento e observabilidade foram definidos?
- Existe baseline de custos?
- Os workloads foram classificados por estratégia de migração?
- Existe roadmap de migration waves?
- Os riscos foram documentados?
- Existe plano de rollback?
Se várias respostas forem “não”, provavelmente a organização ainda não possui informações suficientes para iniciar uma migração com baixo risco.
Como a Ynsize pode ajudar
A Ynsize atua na avaliação de ambientes corporativos e na definição de estratégias para Cloud Migration, arquitetura de dados, infraestrutura, bancos de dados, segurança e modernização.
Nossa abordagem começa pelo entendimento do ambiente atual.
A partir do assessment, analisamos workloads, dependências, performance, capacidade, conectividade, segurança, disponibilidade, arquitetura e custos.
Com essas informações, é possível construir uma visão técnica mais precisa do caminho para o Azure.
O objetivo não é simplesmente mover servidores.
É definir uma arquitetura que faça sentido para o negócio.
Além disso, a experiência em ambientes de dados e infraestrutura permite analisar componentes que frequentemente são críticos para projetos de migração, como SQL Server, aplicações corporativas, integrações, workloads de alta criticidade e plataformas analíticas.
Para conhecer as soluções da Ynsize relacionadas a Microsoft Azure, consulte nossa página de Microsoft Azure.
Conclusão
Uma migração para Azure bem-sucedida começa muito antes da primeira máquina virtual ser criada.
Ela começa com descoberta.
Depois vem a análise.
Em seguida, a arquitetura.
E somente então a execução.
Um assessment de infraestrutura Azure permite transformar um ambiente complexo em informações técnicas capazes de orientar decisões sobre migration strategy, right-sizing, segurança, conectividade, disponibilidade, governança e custos.
Mais importante, o assessment permite identificar antecipadamente aquilo que poderia se transformar em incidente durante a migração.
Por isso, antes de perguntar:
“Quando vamos migrar para Azure?”
A pergunta mais importante é:
“Nós realmente conhecemos o ambiente que estamos planejando migrar?”
Porque colocar uma infraestrutura na nuvem é uma decisão técnica.
Colocá-la na arquitetura certa é uma decisão estratégica.
Perguntas frequentes sobre assessment de infraestrutura Azure
O que é um assessment de infraestrutura Azure?
É uma avaliação técnica do ambiente atual para identificar workloads, dependências, capacidade, performance, segurança, conectividade, disponibilidade e custos antes da migração para Azure.
O Azure Migrate é suficiente para realizar um assessment?
O Azure Migrate é uma ferramenta importante para descoberta, análise e dimensionamento. Entretanto, seus resultados precisam ser interpretados dentro do contexto da arquitetura, dos requisitos de negócio, segurança, operação e continuidade.
Todo servidor pode ser migrado para Azure?
Não necessariamente. A compatibilidade depende do sistema operacional, aplicação, dependências, arquitetura, requisitos de performance, segurança e suporte do fabricante.
O assessment consegue identificar quanto a empresa gastará no Azure?
Ele pode gerar estimativas e apoiar o planejamento financeiro, mas o custo final depende da arquitetura escolhida, utilização, contratos, licenciamento, região, armazenamento, rede, backup e demais serviços utilizados.
O assessment é necessário para uma migração lift-and-shift?
Mesmo em projetos de lift-and-shift, o assessment é altamente recomendado. Sem análise de dependências, performance e capacidade, existe risco de migrar problemas existentes para um novo ambiente.
Quanto tempo leva um assessment?
O prazo depende do número de workloads, complexidade do ambiente, quantidade de dependências, disponibilidade de informações e profundidade da análise necessária.
Qual é a diferença entre assessment e arquitetura Azure?
O assessment concentra-se na compreensão e diagnóstico do ambiente atual. A arquitetura define como o ambiente deverá funcionar no Azure. Na prática, os dois processos são complementares.
Precisa descobrir se sua infraestrutura está realmente Azure-ready?
Antes de iniciar uma migração, avalie o ambiente, identifique dependências, dimensione corretamente os workloads e estabeleça uma arquitetura capaz de suportar segurança, performance, disponibilidade e crescimento.
A Ynsize pode ajudar sua empresa a transformar um ambiente complexo em um roadmap técnico de Cloud Migration.
