Sua saída da VMware vai doer se você não começar agora: o playbook de 12 meses de um CTO

Seu hipervisor agora é um risco de nível de conselho. Após a revisão de licenciamento da Broadcom, muitas empresas descobriram que a conta do vSphere não estava apenas subindo — estava dobrando, às vezes pior. E isso não é hipotético: uma operadora nos EUA teria começado a mover dezenas de milhares de VMs para fora da VMware enquanto brigava nos tribunais. Se nem eles engolem o lock‑in, por que você acha que vai conseguir?

Você não resolve isso com um press release ou um “lift‑and‑shift” de duas semanas. Migração ao vivo entre hipervisores diferentes não existe. Seus construtos do NSX não mapeiam 1:1 para nada fora da VMware. E tomar o caminho preguiçoso — “é só jogar tudo no EC2” — vai te entregar uma nova conta 2–3x maior que o seu custo on‑prem totalmente amortizado quando você somar egress, Reserved Instances, backup e a inevitável superalocação de performance.

A verdade incômoda é: você precisa de um plano disciplinado de saída, e ele começa neste trimestre. Abaixo está um playbook de 12 meses, opções tecnológicas com trade‑offs reais e as armadilhas que vi times enfrentarem quando tentam sair correndo pela porta.

O framework de decisão: quatro caminhos viáveis para sair da VMware

Escolha uma via com base no mix de workloads, habilidades, restrições de latência e compliance. Esta é uma decisão de portfólio, não um concurso de beleza.

1) HCI com KVM em primeiro lugar (Proxmox VE, Harvester, derivados de oVirt)

Melhor para: Ambientes majoritariamente Linux, escala moderada (dezenas a poucas centenas de nós), times confortáveis com operações em Linux.

• Por que funciona: KVM é o hipervisor de fato por trás de AWS, GCP e muitas clouds. Proxmox VE oferece uma UI/API limpa, clusterização, live migration e backup nativo. Harvester (KubeVirt + Longhorn) adiciona um substrato Kubernetes se você quiser harmonizar operações de VMs e contêineres.
• Economia: Proxmox VE é gratuito para uso; assinaturas do repositório enterprise custam aproximadamente €110–€935 por soquete de CPU por ano, dependendo do nível de suporte. Mesmo com suporte, você geralmente fica em 10–30% do seu gasto de software VMware legado para capacidade equivalente.
• Trade‑offs: Você perde um pouco da ergonomia de NSX/vSAN. Terá que reconstruir os overlays de rede (OVN/OVS) e o storage (Ceph/ZFS/Longhorn) por conta própria ou com um parceiro.

2) OpenStack (com KVM, OVN, Ceph)

Melhor para: Nuvens privadas multi‑times, necessidades multi‑tenant, alta maturidade operacional.

• Por que funciona: OpenStack entrega primitivas de IaaS (compute, rede, storage) com cotas, projetos e APIs sólidas. É o mais próximo de um EC2 privado.
• Economia: O software é open source; o custo é operacional. Espere investir em cobertura SRE 24x7 e CI/CD para a própria nuvem.
• Trade‑offs: Complexidade. Se seu time nunca operou um plano de controle, não aprenda isso na sua saída de produção.

3) Alternativas HCI comerciais (Nutanix AHV)

Melhor para: Ambientes mistos Windows/Linux, times que querem o polimento “estilo VMware” sem a VMware.

• Por que funciona: Plano de gerenciamento maduro, tooling para guests Windows, rede e storage integrados. AHV é KVM sob o capô com o plano de controle da Nutanix.
• Economia: Você vai pagar um valor real, mas para muitas organizações ainda sai mais barato que o TCO da “nova VMware” quando você precifica bundles da Broadcom de que não precisa.
• Trade‑offs: Outro relacionamento com fornecedor, com seu próprio risco de roadmap. Menos flexibilidade “faça‑você‑mesmo” do que Proxmox/OpenStack.

4) Rehost em nuvem pública (EC2/Azure/GCP)

Melhor para: Ambientes pequenos ou times que já estão >70% em nuvem, onde o on‑prem é dívida técnica.

• Por que funciona: Caminho mais rápido para sair debaixo de uma renovação VMware. Ecossistema rico para DR, backups e serviços gerenciados.
• Economia: O susto com a fatura é comum. Em regime permanente, espere 1,5–3,0x em relação a um cluster on‑prem bem operado com o mesmo perfil de performance, dependendo de egress e disciplina de RIs.
• Trade‑offs: Latência, residência de dados e controle de custos. Não use esse caminho para mover workloads tagarelas, intensivas em storage e de baixa margem, a menos que você goste de contas surpresa.

Seu plano de saída da VMware em 12 meses

0–30 dias: congele, inventarie, estabeleça a linha de base

• Congele funcionalidades: Pare de introduzir construtos específicos de NSX/vSAN. Sem novas dependências de SRM.
• Inventarie como um banco: Exporte com RVTools ou via sua CMDB, mas valide amostrando o sistema operacional convidado real. Rotule cada VM com responsável, RTO/RPO, CPU/RAM/IOPS, SO e dependências (DNS/AD/NTP, bancos de dados, barramentos de mensagens).
• Linha de base de custos: Últimos 12 meses de itens da VMware, chamados de suporte, licenças de backup, energia e espaço. Você precisa disso para defender o business case.
• Elimine projetos de estimação: Se ninguém consegue nomear o responsável por uma VM em 48 horas, coloque‑a em caminho de descontinuação. Peso morto mata migrações.

30–90 dias: escolha o alvo, construa um piloto

• Escolha seu caminho. Se você tem majoritariamente Linux e operações in‑house, Proxmox VE com Ceph é o caminho prático mais rápido. Se precisa de projetos e cotas multi‑tenant, avalie OpenStack. Se conforto com administração Windows e uma UX caprichada importam, coloque Nutanix AHV na shortlist. Se seu ambiente é minúsculo ou já está 80% em nuvem, planeje um rehost.
• Suba um piloto: Mínimo de 3 nós (cache NVMe, NICs de 25/50Gbps, 256–512GB de RAM). Para Proxmox, adicione Proxmox Backup Server. Para storage, comece com Ceph ou espelhos ZFS, dependendo da escala.
• Pratique as conversões: Use virt‑v2v para VMs Linux e Windows (remova VMware Tools, instale drivers virtio). Espere uma janela de manutenção; migração ao vivo entre hipervisores não é real.
• Prove o básico: Backups, restores, snapshots, builds de templates e RBAC. Se você não restaurou um controlador de domínio do Windows a partir da sua nova stack, você não testou nada.

90–180 dias: rede, armazenamento e onda 1

• Plano de rede: Recrie VLANs e overlays com OVN/OVS ou com seu fabric de switches. Mapeie regras de firewall do NSX para firewalls baseados em host ou firewalls upstream. Coloque DHCP/DNS sob HA adequada.
• Plano de armazenamento: vSAN ≠ Ceph. Comece com 3–5 hosts MON/MDS com SSD/NVMe. Valide IOPS sob suas cargas reais. Habilite TRIM/UNMAP nas VMs para evitar inchaço de I/O.
• Automação: Abrace IaC agora. Use os providers de OpenTofu/Terraform para Proxmox ou sua plataforma escolhida. Gere imagens golden com Packer/Cloud‑Init.
• Migrações da Onda 1: Escolha três classes: um app sem estado, um banco de dados moderado e um serviço Windows (impressão/ADCS/legado de linha de negócio). Valide desempenho e operacionalidade. Documente os runbooks que você realmente usou, não os que você escreveu.

180–270 dias: escala, DR e governança

• Escale: Expanda até a capacidade alvo. Adicione um segundo rack ou cluster para DR. Replique backups offsite. Para Proxmox, teste falhas de quórum do cluster e fencing.
• Padrões de DR: Aceite a realidade: o failover será cold‑to‑warm para a maioria das VMs. Faça script da ordem de boot, trocas de DNS e promoção de banco de dados. Cronometre todo o exercício; se seu RTO diz 60 minutos e você atinge 140, ajuste o plano ou o SLA.
• Observabilidade: Prometheus + Grafana para hosts e guests; exporters de Proxmox ou OpenStack; agregação de logs com Loki/ELK. Acompanhe “vizinhos barulhentos” e contenha‑os com limites de recursos ou nós dedicados.
• Acesso e auditoria: SSO para consoles e APIs, tokens de curta duração, exigência de MFA. Se terceirizados participarem (nearshore ou não), restrinja por postura de dispositivo e allowlists de IP.

270–360 dias: ondas de cutover e descomissionamento

• Agenda das ondas: Trate isso como um calendário de lançamento de produto. Comunique janelas de freeze aos stakeholders com 30 dias de antecedência; faça dry‑run de movimentações complexas em um cluster de staging.
• Ajuste de performance: Faça pinning de CPUs para bancos sensíveis à latência, habilite hugepages onde ajudar, escolha virtio‑scsi em vez de tipos de disco legados e verifique o alinhamento de NUMA em caixas grandes.
• Hardening de segurança: UEFI Secure Boot nos hosts, unidades de boot criptografadas, passthrough de TPM quando necessário, pipelines de patch para hosts. Se você usa AMD EPYC, avalie SEV‑ES para criptografia de memória de VMs em clusters multi‑tenant hostis.
• Reduza a VMware: Desligue hosts descomissionados. Arquive configs. Mantenha uma pequena ilha apenas se for indispensável (por exemplo, appliances presos a fornecedor). Entre nas negociações de renovação com fatos de uso, não com sentimentos.

Quanto isso realmente custa

Números que você pode levar para o financeiro. São direcionais; insira seus orçamentos e tarifas de energia reais.

• Hardware: Um servidor 1U moderno de dois soquetes com 256–512GB de RAM, 2×25Gbps NICs e um par de NVMe de 1,6–3,2TB ficará na faixa de US$6k–$12k dependendo do fornecedor e dos descontos. Você vai querer 6–12 nós para começar se estiver substituindo um ambiente vSphere modesto.
• Energia: Um nó de virtualização em idle fica em ~150–250W e chega a 300–500W sob carga. Dez nós a 300W em média = ~3kW. A $0,12/kWh, isso dá ~$315/mês em energia por 3kW antes de refrigeração e sobrecarga de PUE.
• Software/suporte: Assinaturas do Proxmox VE por soquete de CPU ficam aproximadamente entre €110 (Basic) e €935 (Premium) por ano; muitos times escolhem Standard (~€280/soquete) pelo repositório enterprise + suporte. Ceph é open source; considere suporte pago apenas se faltar skill in‑house. Distribuições de AHV e OpenStack variam; você pagará por suporte e conveniência.
• Pessoas: Este é o custo real. Espere 1–2 FTE de esforço focado por 6–12 meses para planejar, pilotar e migrar um ambiente de 150–300 VMs, além de ajuda dos donos de aplicativos para testes. Se você não tem essa capacidade, um pod SRE nearshore dedicado com 6–8 horas de overlap pode comprimir o calendário sem arruinar o roadmap do seu time.

As armadilhas que explodem cronogramas

• Tentar migração ao vivo entre hipervisores. Não dá. Planeje janelas de cutover com sincronizações diferenciais, não mágica. Use rsync/ZFS send para pré‑estagiar dados quando viável.
• Subestimar o trabalho em Windows. Remova VMware Tools de forma limpa, pré‑instale drivers virtio e valide ativação/licenciamento. Problemas de sincronização de tempo e relações de confiança de domínio vão te emboscar às 2 da manhã.
• Ignorar traduções do NSX. Regras de firewall distribuído e micro‑segmentações não vão se portar sozinhas. Ou reconstrua‑as upstream (Palo Alto, Fortinet, etc.) ou implemente regras baseadas em host e aceite algum espalhamento.
• Pressupor que a performance do vSAN vai se repetir. Ceph e Longhorn se comportam de forma diferente sob cargas de escrita aleatória. Rode fio sob seus padrões reais, não os padrões de marketing.
• Pular ensaios de backup/restore. Um backup que você nunca restaurou é uma história, não um controle. Prove restores completos de VM e em nível de arquivo a partir da sua nova stack antes de qualquer corte em produção.
• Deixar os responsáveis de fora. Se os donos dos apps souberem da migração por um e‑mail de status, você vai falhar no UAT e fazer rollback. Traga‑os para as war rooms cedo.

E o Kubernetes?

Kubernetes não é um hipervisor. Se você já é pesado em contêineres, aproveite o momento para matar um pedaço do espalhamento de VMs — mas não transforme sua saída da VMware em uma reescrita de plataforma. Dois padrões sensatos:

• KubeVirt ou Harvester para o subconjunto de VMs que precisa viver perto dos seus clusters. Funciona bem para serviços Linux e certos apps com estado. Não é uma boa casa para apps Windows antigos de linha de negócio.
• Split‑brain intencionalmente: Execute Proxmox/OpenStack para VMs, Kubernetes para contêineres. Federar identidade e observabilidade. Não force tudo através de uma única API porque é elegante.

Segurança e conformidade: não reconstrua os riscos de ontem

• Credenciais de curta duração: Use OIDC/SAML no seu API/console de virtualização com MFA obrigatório e TTLs de sessão. Acabe com a cultura de senhas de admin de longa duração.
• Segredos e imagens: Ateste o pipeline de imagens. Assine templates de VM. Armazene segredos em um cofre central com acesso por projeto.
• Residência de dados e privacidade: Se você opera em ou atende estados dos EUA que estão apertando regras de dados, mantenha telemetria e backups por região. Trate metadados (especialmente geolocalização e dados de IP) como regulados — as manchetes estão indo nessa direção.
• Hardening de host: UEFI Secure Boot, TPM, FDE nos discos do SO dos hosts e cadência rápida para updates de microcode/kernel. Não espere uma tempestade de CVEs para praticar reboots rolling.

Quando um pod nearshore realmente ajuda

Não se trata de jogar gente em cima da migração. É manter seus engenheiros core focados em produto enquanto um time especializado cuida do trabalho pesado não diferenciado: saneamento do inventário, construção de hosts, bring‑up de rede/storage, runbooks de conversão e cutovers fora do horário. Em Brazil, você terá 6–8 horas de overlap com os fusos dos EUA e talento sênior em Linux 20–30% mais barato do que onshore nos EUA — sem os gaps de 10–12 horas que você tem no offshore. Use esse overlap para o que é espinhoso: drivers no Windows Server 2012 R2, tuning de placement groups no Ceph ou ACLs no OVN que não se comportam como no NSX.

Checagem de realidade sobre prazos

Já vimos ambientes de 150–300 VMs migrarem em 6–9 meses com um time dedicado e forte engajamento dos donos de apps. Acima de 1.000 VMs, planeje 9–18 meses em ondas. Se sua liderança espera “fim do trimestre” porque um fornecedor de nuvem acenou com créditos, rebata com um calendário de migração atrelado à criticidade dos apps e à sazonalidade do negócio. A penalidade por correr geralmente é paga em noites de rollback e dano reputacional, não em pontos de herói.

Por que começar agora

Dois motivos. Primeiro, seu relógio de renovação está correndo. Cada mês que você adia estreita suas opções e entrega poder de negociação ao incumbente. Segundo, o mercado está se movendo. A T‑Mobile ir a público sobre uma saída maciça da VMware é um sinal, não uma anomalia. Prazos de entrega de hardware ainda são irregulares em 2026. Você quer seus POs emitidos antes que todo mundo acorde para o mesmo Plano B.

Principais pontos

• Escolha a via com base no mix de workloads e na maturidade operacional: HCI com KVM (Proxmox/Harvester), OpenStack, Nutanix AHV ou um rehost direcionado em nuvem.
• Migração ao vivo entre hipervisores não é real. Planeje janelas de cutover com dados pré‑estagiados e runbooks testados.
• Orce mais para pessoas do que para software. Espere 1–2 FTE focados por 6–12 meses para mover um ambiente de 150–300 VMs.
• Reconstrua rede e storage de forma deliberada: OVN/OVS para overlays, Ceph/ZFS/Longhorn para storage. Não presuma que os comportamentos de NSX/vSAN se mantêm.
• Teste restores antes de qualquer corte de produção. Um backup que você não restaurou é um boato.
• Use a saída para modernizar a segurança: SSO/MFA nos consoles, imagens assinadas, hosts criptografados e acesso de curta duração.
• Pods nearshore com 6–8 horas de overlap podem comprimir prazos sem descarrilar o roadmap de produto.
• Comece agora para manter a alavancagem de negociação e evitar apertos de hardware/fornecedores quando outros correrem para a saída.