Licenciamento VMware Broadcom: o que mudou e alternativas

Licenciamento VMware Broadcom virou pauta obrigatória de comitê de TI em 2026. A razão é direta: o modelo de comercialização da VMware mudou após a aquisição pela Broadcom em novembro de 2023. Em outras palavras, o que era licença perpétua com manutenção opcional virou subscription obrigatória por core físico. Adicionalmente, vieram bundles consolidados e penalidades por renovação atrasada. Como resultado, organizações que renovaram contratos em 2024-2026 reportam aumentos amplamente relatados na faixa de 300% a 500% comparado ao modelo anterior (casos extremos acima de 1.000%).

Este guia organiza o tema em três blocos para gestores brasileiros de TI. Primeiramente, o diagnóstico: o que mudou no modelo e qual o impacto financeiro real. Em seguida, o catálogo decisório: quais alternativas existem e como compará-las. Por fim, o plano operacional: como construir uma rota de migração realista, com monitoramento que valida a equivalência de SLA antes e depois.

O conteúdo é direcionado a CIOs, CTOs, gerentes de infraestrutura e arquitetos de virtualização. O foco está em organizações que rodam parques máquinas virtuais em VMware vSphere ou ESXi e enfrentam renovação contratual. Por outro lado, CFOs também encontram o framework que justifica o salto de custo. Adicionalmente, aprovam o orçamento de migração com critérios objetivos. Este spoke fecha o ciclo decisório aberto pelo sub-hub FinOps de virtualização. Complementa também o catálogo do sub-hub plataformas de virtualização.

O que mudou no licenciamento VMware após a Broadcom

A aquisição da VMware pela Broadcom fechou em novembro de 2023 e marcou a mudança mais impactante no licenciamento de virtualização da última década. Em outras palavras, em poucos meses a Broadcom reorganizou o portfólio inteiro, descontinuou produtos individuais, eliminou licenças perpétuas e reformulou a estrutura de canais. Como resultado, clientes que rodavam VMware há anos com previsibilidade de custo perderam a referência financeira da estrutura anterior.

Fim da licença perpétua. Antes da aquisição, o modelo dominante combinava licença perpétua (paga uma vez, válida indefinidamente) com Software Maintenance and Support (SnS) renovado anualmente. Por outro lado, a Broadcom encerrou completamente a venda de licenças perpétuas em 2024. Agora todos os clientes operam sob subscription com renovação anual ou multi-anual obrigatória. Vale destacar que licenças perpétuas adquiridas antes da mudança continuam funcionando tecnicamente, mas perderam acesso a updates e suporte sem migrar para o novo modelo.

Modelo por core físico. O licenciamento passou a ser calculado por core físico do host, não mais por socket ou por VM. Desde a transição para o modelo de assinatura da Broadcom (fim de 2023), o piso é de 16 cores por CPU. Em abril de 2025 a Broadcom chegou a elevar o mínimo por pedido para 72 cores, mas recuou diante da reação do mercado e manteve os 16 cores (heise, abr/2025). Por isso, hosts densos que rodavam poucos VMs grandes em 32 ou 64 cores físicos agora pagam proporcional ao hardware. Esse é o ponto que mais penaliza ambientes mal dimensionados.

Bundles obrigatórios. Os SKUs individuais (vSphere Standard, Enterprise Plus, vCenter, NSX, vSAN avulsos) foram consolidados em dois bundles. Primeiramente, vSphere Foundation (VVF) inclui vSphere + vCenter + Tanzu Kubernetes Grid + Aria Operations. Além disso, VMware Cloud Foundation (VCF) inclui tudo de VVF mais NSX, vSAN, Aria Automation e HCX. Como resultado, clientes que usavam apenas vSphere agora pagam por NSX e vSAN mesmo sem adoção real. Essa consolidação é a maior alavanca do aumento de custo reportado.

Penalidade de reinstatement por renovação atrasada. Segundo relatos de especialistas em licenciamento, penalidade de reinstatement de cerca de 20% (condições variam por contrato). Contratos renovados após a data de vencimento podem sofrer essa cobrança sobre o valor do primeiro ano da assinatura renovada. Em síntese, a janela “analiso no próximo ciclo” foi eliminada. Por isso, decisão estratégica sobre stack precisa acontecer antes do fim do contrato vigente; quem deixa passar paga mais para a mesma coisa.

Impacto financeiro real para empresas brasileiras

A combinação dos quatro fatores acima eleva o custo total de propriedade da stack VMware de forma estrutural. Em geral, aumentos entre 300% e 500% são reportados em pesquisas independentes. Dados públicos compilados por levantamentos de mercado especializados em pricing pós-Broadcom sustentam o range. Por outro lado, o impacto varia bastante por perfil de cliente. Três variáveis explicam a maior parte da dispersão.

Densidade do host. Quanto mais cores físicos por host, maior o ganho da Broadcom no modelo por core. Por exemplo, um cluster de 4 hosts com 64 cores cada totaliza 256 cores (exemplo ilustrativo). Esse cluster, que antes pagava cerca de R$ 80 mil ao ano em manutenção SnS, pode chegar a R$ 320-400 mil/ano no novo modelo subscription (exemplo ilustrativo; valores reais variam por contrato). Em síntese, o ratio “cores físicos por VMs ativas” virou critério financeiro direto. Hosts ociosos explodem o orçamento mesmo sem ganho de capacidade real.

Adoção de bundles. Clientes que usavam apenas vSphere sentem mais o aumento, pois passam a pagar NSX e vSAN compulsório. Em contrapartida, organizações que já operavam o stack completo (NSX + vSAN + Aria) têm impacto menor proporcionalmente. Para esses casos, a mudança chega ao patamar de 30-80% de aumento, não 300%. Por isso, o cliente típico de PME brasileira (vSphere puro, sem add-ons) é o mais castigado pela consolidação obrigatória.

Janela de renovação. Contratos renovados antes do prazo evitam a multa de 20% e podem negociar prazo de 3 anos com travamento de preço. Por outro lado, quem renovou atrasado paga mais sobre uma base já inflada. Adicionalmente, o ciclo de orçamento brasileiro (revisão anual em outubro-novembro) raramente acompanha o ritmo contratual da Broadcom. Como resultado, cria-se pressão de decisão fora da janela orçamentária natural.

Vale destacar que o salto também muda a natureza contábil do gasto. Em outras palavras, o que era CapEx vs OpEx tradicional (compra de licença + manutenção) virou OPEX puro com tíquete mensal recorrente. Por isso, a análise financeira precisa olhar para o TCO consolidado em 3-5 anos, não apenas para o ticket de renovação imediata. Cabe ressaltar que esse exercício é o cerne de qualquer programa de FinOps em cloud aplicado a virtualização. Ele entrega o número que justifica (ou derruba) a decisão de migração.

Alternativas viáveis ao VMware: open-source e enterprise

O mercado consolidou cinco alternativas viáveis ao VMware para cargas de virtualização de servidores corporativos. Em geral, todas têm cobertura de produção real validada em ambientes brasileiros. Por outro lado, cada uma tem perfil de licenciamento, maturidade enterprise e custo operacional bem distintos. A tabela abaixo sintetiza as cinco principais para comparação direta.

Em síntese, três alternativas dominam o mercado brasileiro como migrações reais documentadas. Primeiramente, Proxmox VE aparece mais em PMEs e ambientes mistos. Adicionalmente, Hyper-V em Windows Server domina empresas com forte adoção Microsoft. Por fim, Nutanix AHV é nativo para organizações que já têm a stack HCI Nutanix. Por outro lado, KVM puro e Red Hat OpenShift Virtualization aparecem em cenários específicos. Atendem equipes Linux maduras ou ambientes que rodam Kubernetes em produção.

Cabe ressaltar que cada alternativa tem perdas funcionais específicas em relação ao VMware. Por exemplo, vMotion entre clusters tem equivalentes em todas, mas DRS automatizado, NSX network segmentation profundo e vSAN com stretched cluster têm cobertura desigual. Por isso, a comparação operacional precisa ser feita por workload, não por hypervisor genérico. Para o aprofundamento dos critérios técnicos lado-a-lado, o material dedicado a comparativo de hypervisors traz o detalhamento por dimensão funcional. Adicionalmente, o catálogo completo das opções enterprise com prós e contras consolidados está em alternativas ao VMware.

Critérios de decisão: ficar com VMware vs migrar

A decisão estratégica frente ao novo licenciamento não é binária. Em outras palavras, organizações maduras estruturam a análise em três opções, não duas. Primeiramente, renovar com Broadcom no novo modelo: aceitar o salto de custo em troca de continuidade operacional total. Além disso, consolidar e otimizar antes de decidir: reduzir cores licenciados via rightsizing agressivo e descomissionamento de zumbis, comprando tempo. Por fim, migrar workloads para alternativa: assumir o projeto de transição completo.

A opção 2 (consolidar primeiro) é a mais ignorada pela narrativa dominante “fica vs migra”. Por outro lado, é onde está o ROI mais rápido. Por exemplo, em ambientes corporativos típicos, 30-50% das VMs em produção podem ser candidatas a rightsizing e 10-25% do parque inicial é zumbi. Como resultado, reduzir o footprint VMware antes da renovação já corta cores licenciados em 20-40%. Isso muda completamente o número final negociado, independentemente da decisão de stack.

Para decidir entre as três opções, três critérios objetivos pesam mais do que os outros. Em primeiro lugar, TCO 5 anos da opção atual vs alternativa. Em segundo lugar, maturidade operacional do time interno para a alternativa escolhida. Por fim, SLA contratual e dependências de funcionalidade VMware específica (DRS profundo, NSX, vSAN stretched). A regra mental funciona assim: migrar faz sentido quando TCO da alternativa é mais de 40% menor. Em paralelo, o time precisa de maturidade comprovada e zero dependência crítica de funcionalidade exclusiva. Caso contrário, consolidar primeiro e reavaliar em 12 meses.

Vale destacar que muitos comitês de TI subestimam o custo operacional de migração no primeiro orçamento. Em outras palavras, migrar 100 VMs envolve muito além da conversão técnica entre formatos VMDK, VHDX ou qcow2. Adicionalmente, exige treinamento, retrabalho de runbooks, integração com automação existente e período de paralelização. Por isso, o ROI da migração só aparece líquido após 12-18 meses na maioria dos cenários. Como resultado, decisões precipitadas em ciclo de orçamento apertado tendem a falhar pelo timing errado.

Como construir um plano de migração realista

Plano de migração realista da VMware para alternativa estruturado em quatro fases, cada uma com critério de saída objetivo. Em síntese, organizações que pulam fases ou aceleram artificialmente entregam projetos com perda de SLA, retrabalho e desistência parcial no meio do caminho.

Fase 1: Inventário e baseline (4-8 semanas). Mapear todo o parque VMware atual: hosts físicos, cores físicos, licenças contratadas, VMs ativas, footprint por workload, dependências (vMotion, DRS, NSX, vSAN). Em paralelo, coletar baseline de SLA atual. Os dados incluem disponibilidade, latência P95, IOPS percentil 99, tempo médio de boot. Para o detalhamento operacional do que medir nesta fase, consulte a documentação oficial do vSphere sobre métricas de plataforma. Esses números viram o teto que a alternativa precisa igualar ou superar. Critério de saída: documento de inventário + planilha de baseline aprovados por sponsor executivo.

Fase 2: POC e validação técnica (8-12 semanas). Selecionar 3-5 workloads representativos (1 web tier, 1 banco de dados, 1 aplicação legada Windows, 1 cluster HA). Em seguida, recriar em ambiente isolado da alternativa escolhida e rodar bateria de testes funcionais e de carga. Cabe ressaltar que o POC precisa cobrir cenário de falha. Os cenários críticos incluem host down, network partition e storage failure, não apenas operação normal. Para conduzir POC com a alternativa open-source mais usada em PMEs, a wiki oficial Proxmox VE centraliza a documentação técnica de cluster, HA e storage. Critério de saída: relatório técnico com gap funcional documentado e plano de mitigação.

Em seguida, entra a etapa que ocupa mais calendário. Fase 3: Paralelização e migração assistida (12-24 semanas). Rodar VMware e alternativa simultaneamente durante a transição. Adicionalmente, migrar workloads em ondas, priorizando os menos críticos primeiro. Cada wave tem rollback documentado para mitigar incidente. Em geral, organizações maduras migram 5-15 VMs por semana após a primeira wave estabilizar. Por isso, projeto de 100 VMs costuma levar 6-12 meses na Fase 3. Propostas comerciais que sugerem “2 semanas” geralmente omitem o tempo real de validação. Critério de saída: 100% das VMs migradas, baseline de SLA igualado ou superado por workload.

Por fim, vem o fechamento operacional do projeto. Fase 4: Descomissionamento e otimização final (4-8 semanas). Desligar hosts VMware liberados, renegociar contrato Broadcom para footprint residual (ou encerrar totalmente), retirar redes ou storage exclusivos VMware, atualizar runbooks e documentação. Vale destacar que esta fase é frequentemente subestimada: descomissionar mal deixa custo residual de licença e overhead operacional por meses. Critério de saída: contrato Broadcom encerrado ou renegociado, runbooks atualizados, time treinado integralmente na nova stack.

Monitoramento durante e após a migração

Monitoramento operacional é o instrumento que valida a equivalência de SLA antes, durante e depois da migração. Em outras palavras, sem dados contínuos comparáveis entre ambiente VMware origem e ambiente alvo, qualquer análise de sucesso vira anedota. Por isso, ferramenta de monitoramento multi-vendor (capaz de coletar métricas de VMware E de Hyper-V/KVM/Proxmox/Nutanix simultaneamente) é pré-requisito do projeto de migração, não opcional.

As métricas que importam dividem-se em duas categorias. Primeiramente, métricas de paridade técnica: CPU Ready Time, memory ballooning, IOPS por VM, latência de storage, throughput de rede, tempo de boot. Em segundo lugar, métricas de paridade de negócio: disponibilidade percebida pelo usuário, tempo de resposta de aplicação, taxa de erro, throughput de transações. A paridade técnica valida que a alternativa entrega a mesma fundação operacional. Em contrapartida, a paridade de negócio valida que essa fundação se traduz em experiência equivalente para quem consome o serviço.

Cabe ressaltar o gancho com FinOps. Em paralelo à validação de SLA, o monitoramento contínuo descobre cores ociosos no parque VMware residual durante a transição. Por isso, cada wave de migração libera capacidade. Essa capacidade pode virar redução imediata de licenciamento contratado (renegociação do tier Broadcom) ou capacidade extra para outras workloads. Como resultado, o ROI da migração aparece em duas frentes simultâneas. Há economia direta de licença Broadcom e ganho operacional do novo ambiente.

Vale destacar que esse mesmo monitoramento contínuo se mantém útil em regime permanente após a migração. Em síntese, descobrir VM zumbi, identificar over-provisioning e validar SLA não muda de hypervisor. O target sim muda, mas a prática permanece a mesma. Por exemplo, o spoke dedicado a monitoramento de VMware aprofunda métricas específicas do stack VMware durante a fase de paralelização. Adicionalmente, a camada operacional permanece estável independente da escolha final.

Conclusão

Em síntese, licenciamento VMware Broadcom mudou de forma estrutural em 2024-2026. Como resultado, exige decisão estratégica explícita de qualquer organização que rode VMware em produção. O modelo subscription por core combinado com bundles obrigatórios e penalidade de 20% por atraso eliminou a possibilidade de “continuar como está”. Por outro lado, o cenário tem três rotas concretas. Primeiramente, renovar no novo modelo. Adicionalmente, consolidar para reduzir o footprint antes de decidir. Por fim, migrar para alternativa viável.

Adicionalmente, as cinco alternativas mapeadas (Proxmox VE, Hyper-V, KVM puro, Nutanix AHV, Red Hat OpenShift Virtualization) cobrem perfis bem distintos de cliente brasileiro. Em geral, a decisão certa depende de TCO 5 anos comparado. Em paralelo, pesam maturidade operacional do time e dependência de funcionalidade VMware específica. A popularidade de uma ou outra opção não deve dominar a análise. Como resultado, organizações que estruturam a decisão nessas três variáveis tomam escolhas sustentáveis. As que pulam para a migração mais “barata” tendem a retrabalho caro no segundo ano.

Por fim, o plano de migração realista combina inventário, POC, paralelização e descomissionamento em 4 fases mensuráveis. Em paralelo, o monitoramento contínuo valida paridade de SLA em cada wave. Se a sua organização precisa estruturar essa análise com dados de uso real do parque VMware atual, fale com um especialista da OpServices. O OpMon alimenta o ciclo de decisão e o monitoramento multi-vendor durante toda a transição.