Migrate from Nutanix to Proxmox VE

Migrate from Nutanix to Proxmox VE: what the move involves

A Nutanix renewal or term change forces a decision on both the hypervisor and the storage layer, and that is the reason to plan the move as one project rather than a VM copy. In most cases the migration is a bounded project that a small platform team can run with partner help, provided the cutover window is set and the target design is agreed before the first VM moves. The person who owns the Nutanix estate, usually the infrastructure lead, should own the cutover plan, with the security and compliance owners signing off on the controls that change.

Moving the virtual machines is the easy part. Exporting VMs as OVA from Prism Central and importing them into Proxmox VE with the qm importovf path or a disk import is well documented, but each VM still needs its boot mode, drivers and Nutanix guest tools checked after import. The harder work is replacing Prism, which handles provisioning, alerts, snapshots and replication in one console, with the Proxmox VE web interface, Proxmox Backup Server and Ceph dashboards. Storage design on Ceph is the largest single decision: the Ceph hardware recommendations call for a dedicated drive per OSD, enterprise-class SSDs for metadata, and bonded network links across two switches, and existing Nutanix nodes may not meet all of them. Confirm this against your own hardware before committing to reuse.

Proxmox VE is licensed under AGPL v3, so the software carries no license fee. Its subscriptions are priced per CPU socket per year, with Community at 120 euros, Basic at 370 euros, Standard at 550 euros and Premium at 1,100 euros, and every tier includes the same features, so the tier only changes support entitlements and enterprise repository access. Time the move to the Nutanix subscription end date, and run the Proxmox VE and Ceph pilot on reused nodes before that date. Ask any implementation partner for a written scope covering the VM inventory, the storage design, the cutover runbook and the rollback plan.

Which Nutanix capabilities map to Proxmox VE and Ceph, and which need rework

This table maps the main Nutanix capabilities to their Proxmox VE and Ceph counterparts and marks each as clean, needs rework, or gap. Read the status column first, then the notes, to plan which workloads can move as they are and which need redesign or a separate tool. Items marked gap need a replacement chosen before cutover.

Nutanix capability	Proxmox VE and Ceph equivalent	Status and what to plan
AHV virtualization	Proxmox VE with KVM virtual machines	Needs rework: guests need VirtIO drivers and firmware checks after import; Nutanix guest tools must be removed
Prism Central management	Proxmox VE web interface and API, per cluster	Needs rework: operators must relearn workflows; there is no multi-cluster view equivalent to Prism Central unless you add one
Nutanix storage (distributed storage fabric)	Ceph RBD for VM disks, with Ceph replication across nodes	Needs rework: Ceph needs a dedicated drive per OSD and sizing for peak memory; benchmark before buying hardware
Snapshots and replication	Proxmox VE snapshots and storage replication, Ceph snapshots	Needs rework: map Nutanix protection policies to Proxmox schedules and confirm recovery points meet your targets
Backup and recovery	Proxmox Backup Server for VM backups	Clean for VM backup: deduplicated backups of KVM guests; confirm restore tests cover each application
High availability	Proxmox VE HA with watchdog-based fencing	Needs rework: HA needs at least three cluster nodes for reliable quorum, shared storage, redundant hardware and watchdog fencing
Nutanix Move	No direct equivalent; use the Proxmox VE import wizard, qm importovf, or qm disk import	Gap: Nutanix Move has no direct Proxmox equivalent. Export OVA from Prism Central, then import and validate each VM
Flow microsegmentation	Proxmox VE firewall rules and security groups	Needs rework: rebuild policies by hand and test them before cutover; Flow policies do not transfer automatically
Object and file services	Ceph RGW for S3-compatible object storage and CephFS for shared file systems	Gap: Nutanix Objects and Files are not migrated; plan Ceph RGW and CephFS as separate services with their own sizing
Prism analytics and Nutanix support tooling	No direct equivalent; plan monitoring with separate tools	Gap: Prism analytics and Nutanix support tooling need their own replacements, such as a monitoring stack and internal runbooks

What data and integrations move, and what you rebuild

Moving AHV workloads is mostly a disk, identity and network exercise. Each card below covers one item you move or rebuild, and most of them depend on confirming how your AHV exports look before you commit to an import path.

VM disks from Prism Central OVA exports

Export each VM from Prism Central as an OVA, then choose the Proxmox path: the import wizard is documented for ESXi and vCenter, not for AHV, so an AHV OVA is handled through qm importovf or by extracting disks and running qm disk import on the VMDK files. Clonezilla is the fallback for disks that will not import cleanly. Confirm with Nutanix and Proxmox test runs which disk formats and firmware settings your exports carry before planning the cutover window.

Guest tools and drivers removal

Nutanix guest tools and AHV-specific drivers are installed inside the guest OS, so they must be removed or left inert before the VM boots on KVM. Plan to check for stale services, scheduled tasks and virtio-related driver needs on Windows guests, and to install the QEMU guest agent where the guest supports it. Confirm the exact removal steps with Nutanix documentation for your AHV version, since this is not covered by the supplied sources.

VLAN and network mapping

AHV virtual networks and their VLAN IDs do not carry over automatically, so each source network needs a matching Proxmox bridge or VLAN-aware bridge on the target nodes. Map every VM NIC to a bridge, keep MAC addresses where licensing or firewall rules depend on them, and test routing and firewall policy per VLAN before cutover. Flow microsegmentation rules, if you use them, need their own mapping to Proxmox VE firewall rules.

Active Directory and LDAP identities

Nutanix Prism administrators and any directory-backed service accounts do not move with the VMs. Proxmox VE has its own user management with realms, so decide whether operators log in through a local realm, LDAP or Active Directory, and rebuild role assignments in the Proxmox permission model. Application service accounts that were bound to AHV-hosted systems keep working only if their directory references and certificates are unchanged after the move.

Backup job definitions

Nutanix protection policies and snapshot schedules are not exported with the VMs, so every backup job must be redefined on the Proxmox side, usually with Proxmox Backup Server or another tool on the backup list. Confirm retention periods, application-consistent snapshot needs and restore testing against the new target before you retire the old policies. Keep the old backups readable until restores on the new platform have been verified.

Object and file shares on Ceph

Object buckets and SMB or NFS shares served by Nutanix Objects or Nutanix Files do not move with VM disks. They need a deliberate rebuild: Ceph RGW for S3-compatible buckets, and CephFS for shared file storage, with permissions and client paths recreated and tested. Ceph's hardware recommendations call for dedicated drives per OSD, shared SSDs for WAL and DB on HDD-based OSDs, and bonded network links, so size the cluster before data copies begin.

How to sequence the Nutanix to Proxmox VE cutover

The sequence moves AHV workloads to Proxmox VE and Ceph in stages, so each VM is inventoried, proven on a test cluster, run in parallel and cut over with a tested rollback before any Nutanix node is retired.

Inventory VMs and map dependencies
Your team exports a complete inventory from Prism Central and the guest estate: VM names, vCPU and memory, boot firmware (BIOS or UEFI), disk sizes and formats, NICs and VLANs, attached Nutanix guest tools, and external dependencies such as DNS, license servers, backup agents and databases. Each VM is tagged with an owner, a business criticality and a proposed wave. The step is done when every VM has a row in the inventory and every dependency has a named owner who has confirmed it.
Build a Proxmox test cluster
Install Proxmox VE on spare or reused hardware that matches the production design, using the enterprise repository for anything that resembles production. Configure a test network that mirrors the production VLANs, so pilot VMs keep their IP addressing. Confirm the Proxmox VE release and its Debian base against the Proxmox VE roadmap and FAQ before installation. The step is done when the test cluster passes a node reboot and a network failover test.
Pilot a representative VM set
Choose a small set of non-critical VMs that cover your range: a Linux server, a Windows server, a database host and a UEFI guest. Move them with the OVA export from Prism Central and the import path that fits each disk, such as qm importovf or qm disk import for VMDK files, then remove Nutanix guest tools and install the virtio drivers and QEMU guest agent. Record boot results, driver issues and import times. The step is done when each pilot VM boots, reaches its application and passes the owner's acceptance checks.
Size and benchmark Ceph
Size the Ceph cluster from the workload profile, not from the old Nutanix capacity figures. Follow the Ceph hardware recommendations: one dedicated drive per OSD, WAL and DB on shared SSDs for HDD-based OSDs, enterprise-class SSDs for metadata, bonded network links across two switches, and memory sized for peak use. Benchmark the pool with representative I/O before committing hardware. Confirm the Ceph release and its support window on the Ceph releases page. The step is done when the benchmark meets the latency and throughput targets the pilot owners agreed to.
Run parallel and replicate workloads
Keep Nutanix serving production while the first wave runs on Proxmox VE. Configure Proxmox replication or backup-based copies for the wave's VMs, and test restores into the Proxmox cluster on a schedule the owners approve. Verify that application data stays consistent between the two platforms before any switch is planned. Document each VM's rollback path: the Nutanix copy remains powered down but intact until the owner signs off. The step is done when a restore test succeeds for every VM in the wave.
Cut over each workload in a change window
Move workloads one at a time inside agreed change windows. For each VM, freeze writes or stop the application, take a final export or sync, start the Proxmox copy, update DNS, load balancer and monitoring targets, and run the acceptance checklist. Keep the rollback tested in advance: power the Proxmox VM off, restore the Nutanix VM and reverse the DNS change within the window. The step is done when the owner confirms service health and the change record closes with the rollback plan marked as no longer needed.
Sign off the runbook and decommission Nutanix
Consolidate the inventory, change records, test results and backup restore evidence into a signed runbook approved by the application owners, security and operations. After the last wave has run in production for the agreed period, shut down Nutanix clusters, remove them from Prism Central, and handle license cancellation and data sanitization through your Nutanix contract and your media destruction policy. Confirm the subscription end date with Nutanix before you stop renewal activity. The step is done when Nutanix nodes are wiped, returned or destroyed and the evidence is filed.

How the migration changes by estate size and starting point

A small estate usually reuses its Nutanix nodes as Proxmox VE hosts and builds a Ceph cluster across the same machines. Three nodes is the minimum for reliable quorum and high availability, so a cluster of three or four nodes leaves little room for error when a host is down for maintenance. The migration is mostly a rebuild of storage and management, with a modest number of VMs to move.

Ceph design on shared hardware: Confirm that each node has a dedicated drive per OSD and enterprise-class SSDs for metadata, and that the network links are bonded across two switches. Reused nodes often lack these, so check before you commit.
Watchdog fencing: High availability needs watchdog-based fencing so a failed node is reset before its guests restart elsewhere. Test this on the actual hardware.
Import volume: The number of VMs is usually small enough to move in waves, with a rollback copy kept until each application owner signs off.
Pilot: Run one non-critical VM through export, import and a failover test before you schedule the rest.
Staffing: One or two administrators can usually run the cluster, but they need Ceph skills in place before cutover, either from internal training or a support plan.

Before committing, check each node against the Ceph hardware recommendations and confirm the Proxmox VE subscription tier you need for support.

What drives cost and duration of the move

This table lists each cost component of moving from Nutanix AHV to Proxmox VE with Ceph, who is paid for it, whether it is one-time or recurring, and what pushes it up or down. Use it to build a like-for-like quote request and to see where the renewal date matters most.

Cost component	One-time or recurring, and who is paid	What drives it up or down	What to ask for in a quote
Proxmox VE subscription	Recurring per year per physical CPU socket. Paid to Proxmox Server Solutions. Community is 120 euros, Basic 370 euros, Standard 550 euros and Premium 1,100 euros, per the Proxmox VE pricing page. Tiers differ in support tickets and response times, not features.	Socket count per host, tier chosen, and whether the no-subscription repository is acceptable for non-production nodes. Production nodes need the enterprise repository, which requires a valid key.	Socket count per node, tier per node, the support response times included, and whether the quote covers test or lab clusters separately.
Ceph hardware and drives	One-time capital cost, paid to hardware vendors. Reused Nutanix nodes may cover part of it, but Ceph needs a dedicated drive per OSD and separate fast devices for WAL and DB on HDD-based OSDs.	Drive count and type, enterprise-class SSDs for metadata, network bonding across two switches, and memory sized for peak use. Reusing nodes lowers capital cost but may need added drives or NICs.	Confirm with the vendor whether existing Nutanix nodes meet Ceph drive and network needs, and request a sizing and benchmark plan before any purchase.
Ceph and Proxmox staff time	Recurring internal or partner effort. Paid through salaries or a retainer, and it covers day-to-day cluster operations, patching and upgrades.	Team skills in Linux, Ceph and KVM, cluster size, and how many Proxmox VE major upgrades fall in the planning window. Proxmox VE 8 on Debian 12 reaches end of life in August 2026, so upgrades can be scheduled earlier.	Ask for a named operations model, runbooks and a staffing estimate that covers upgrades, Ceph recovery and watchdog-based HA testing.
Migration services and tooling	One-time, paid to the internal team or an implementation partner. Covers VM export from Prism Central, OVA or disk import and validation.	VM count, OS mix, driver and firmware cleanup after import, and the number of VMs with large disks or snapshot history, which import more slowly.	A written inventory method, a pilot wave, a rollback plan and a per-wave acceptance checklist, with the exact scope agreed before work starts.
Snapshot history and disk size	One-time effort that changes import time and cutover window. No fixed cost, but it adds transfer and storage capacity needs.	Long snapshot chains and large VM disks lengthen transfers. Consolidating snapshots and removing stale disks before export reduces both time and scratch space.	Ask how the plan handles snapshot consolidation, scratch capacity and transfer bandwidth for the largest VMs.
Cutover and parallel running	One-time effort, paid to internal staff or a partner, plus the cost of running Nutanix and Proxmox side by side until the renewal ends.	Overlap length, number of waves, and whether any VMs need downtime windows. Timing the cutover to the Nutanix subscription renewal can limit how long both platforms must be paid for.	Ask for the renewal-aligned schedule, the overlap period assumed, and the change window needed per wave.
Replacing Prism management and replication	One-time design and configuration work. Replaces Prism snapshots, replication and dashboards with Proxmox VE web interface features, backup tooling and monitoring you choose.	Number of protection policies, replication targets and monitoring integrations to rebuild. Snapshot schedules and backup retention are often the largest rebuild items.	Ask for a mapping of each Prism policy to its Proxmox VE or Ceph equivalent, and a list of items the vendor expects you to build separately.
Nutanix renewal timing	Not a cost item in itself, but it sets when the old recurring fees end. Confirm the term end date and any notice period in the Nutanix contract.	An early exit can mean paying for overlapping subscriptions. A later exit can mean paying for capacity you no longer need after the move.	Confirm the exact subscription end date and notice terms with Nutanix before setting the migration schedule.

What usually goes wrong in a Nutanix to Proxmox move

Most failed Nutanix to Proxmox VE moves do not fail on the import itself. They fail on the sizing, cluster design, and configuration choices made before and after the first VM lands. The cards below cover the risks that tend to surface during cutover and the checks that prevent them.

Undersized Ceph memory or mixed drives

Ceph is the storage layer most teams add to reuse Nutanix hardware, and it is sensitive to undersizing. Ceph's hardware guidance says to size memory for peak load rather than quiet periods and to benchmark before buying, because no two clusters behave alike. Mixing drive types across OSDs produces uneven latency that looks like a VM problem. Benchmark the reused nodes with a representative workload and size memory for recovery peaks before the first production import.

Skipping the three-node HA requirement

Teams often migrate two or three hosts as a convenience cluster and then expect high availability to work. Proxmox VE HA needs at least three cluster nodes for reliable quorum, shared storage for guests, and watchdog-based fencing so a failed node is reset before its guests restart elsewhere. Without fencing, a split cluster can run the same VM twice and corrupt its disks. Validate quorum, shared storage, and watchdog fencing with a planned node failure before you declare HA ready.

Slow imports of snapshot-heavy VMs

VMs that carry snapshots in Prism Central export and import more slowly, and the delay compounds across a large batch. Proxmox documents the same behavior for ESXi imports, so expect the same pattern on the Nutanix side. Long-running transfers also widen the window for data drift if the source keeps writing. Consolidate or remove unneeded snapshots on the source, then import the largest VMs in their own windows.

UEFI and firmware mismatches after import

A VM that boots under AHV with UEFI or Secure Boot settings may not boot in Proxmox if the firmware type, boot disk controller, or EFI variable store does not carry over. The guest may then drop to a boot prompt or lose its network interface name. Nutanix guest tools and drivers also need removing or replacing so they do not conflict with the new hypervisor. Record each VM's firmware, boot mode, and disk controller before export, then verify boot and drivers on a test copy first.

Network mapping errors

Imported VMs keep their virtual NIC definitions, but the target bridges, VLAN tags, and MTU values in Proxmox do not match the source automatically. A VM can boot cleanly and still be unreachable, or it can land on a production VLAN by mistake. Storage and cluster networks also need separate paths from guest traffic. Document every source network and VLAN, build matching Linux bridges or SDN zones on the target, and test reachability for each VM before cutover.

Running the community repository in production

The no-subscription repository is suited to testing and non-production use, while the enterprise repository, which requires a valid subscription key, is the recommended choice for production. Teams that leave the no-subscription repository enabled on production nodes may receive updates that have had less testing. Subscription tier also determines support response times, so an unsupported production cluster has no escalation path. Confirm the repository configuration on every node and decide the subscription tier with your support requirements in writing.

Timing the cutover to the Nutanix subscription renewal

Start from the renewal date and work backward. Nutanix sells Cloud Infrastructure as term subscriptions of 1 to 5 years, licensed on physical CPU cores, so the term you hold sets the deadline for everything else. Confirm with Nutanix or your reseller the exact expiry date of each license, the notice period for non-renewal or reduced core counts, and whether a short extension is available if the migration runs late. Write these dates into the project plan first, then schedule the pilot, the data copy windows, the cutover waves and a rollback window before the term ends. Ask for these terms in writing, because notice periods are contractual and vary by agreement.

Plan the pilot and parallel run to finish well before the term ends, not on the last day of it. A pilot should move a small set of non-critical AHV VMs through the OVA export and import path, then check disk controllers, boot mode, network mapping, guest agents and backup jobs in Proxmox VE. A parallel run keeps both platforms available so that you can compare performance and recovery behavior under real load. Leave time to fix what the pilot exposes, and to reconsider Ceph pool sizing if the first results show that the copies are too slow. Once the last cutover wave is complete, you still need time to decommission Nutanix guest tools and confirm backups from the new platform restore correctly.

Do not treat Nutanix Community Edition as a stand-in for a test environment. The Community Edition is a no-cost download positioned for learning and skill development on your own hardware, and Nutanix does not position it as a supported production edition, so it cannot host production workloads during the transition. Use a separate Proxmox VE test cluster for rehearsals, and keep Nutanix production nodes running under the existing subscription until every workload has passed acceptance. The Nutanix Community Edition page describes its intended use, and any question about using it for a specific purpose should go to Nutanix before the project relies on it.

Questions buyers ask before moving from Nutanix to Proxmox VE

What drives the total cost of moving from Nutanix to Proxmox VE?

The total is driven by the components you pay for, not by one license line. On the Nutanix side, you stop paying NCI term subscriptions priced per physical core when they lapse, but you still pay for hardware refresh, if any, and for the migration work. On the Proxmox side, you pay for per-socket subscriptions per year if you want support and the enterprise repository, which the Proxmox pricing page lists at 120 euros for Community, 370 euros for Basic, 550 euros for Standard and 1,100 euros for Premium, with all features in every tier. Software can run without a subscription. Ceph is free software, so its cost is staff time, hardware and any third-party support. Ask any quote to split one-time migration effort from recurring subscription and support costs, and to show the core and socket counts it assumes.

How long does a Nutanix to Proxmox VE migration take?

No supplied figure gives a duration, so the pace depends on the variables you control. The main factors are the number of VMs, their disk sizes, how many carry snapshots, the export and import path you choose, and how much testing each workload needs. Proxmox documents that VMs with snapshots import more slowly, so cleaning up snapshots before export is worth doing. The pace also depends on how many Ceph nodes you bring up and benchmark before cutover. Timing to your subscription renewal matters because it sets the deadline, but it does not set the work. Ask for a written plan with waves, rollback steps and a cutover window per workload before agreeing any date.

What does the migration need from our internal team?

Your team needs skills in four areas: Proxmox VE cluster operation, Linux and KVM guest tuning, Ceph storage, and network design. Proxmox VE high availability needs at least three cluster nodes, shared storage for guests, redundant hardware and watchdog-based fencing, so someone must own those settings. Staff also need to remove Nutanix guest tools, check firmware and driver settings after import, and redo monitoring and backup jobs. Plan for named owners on storage, networking and application testing, and confirm which of these skills already exist in your staff before the project starts.

Can our own team migrate from Nutanix to Proxmox VE without outside help?

Yes, a capable team can do it in-house, provided it has time, a test environment and the skills listed above. Proxmox provides an import wizard for VMware sources, but its supplied documentation covers ESXi and OVF or disk import paths, not Prism Central exports directly, so AHV VMs usually go through an OVA or disk image path that you should test on a non-production VM first. The risk is less in the first VM and more in the cutover of many VMs at once, plus Ceph and HA design. If those are new to your team, a fixed-scope engagement with DeployOpen can cover planning, implementation, testing, documentation and handover, with the scope and deliverables agreed in writing before work starts.

Does Nutanix Move help migrate VMs out of AHV?

No. Nutanix Move, which is free for Nutanix customers, migrates VMs into Nutanix AHV from VMware ESXi, Hyper-V and public clouds, according to Nutanix's Move 6.0 announcement. It is not a tool for moving workloads out of AHV. For leaving AHV, the usual path is to export VMs as OVA from Prism Central, then import them into Proxmox VE or convert disk images. Confirm with Nutanix whether any export tooling in your version is supported for your use case, and confirm the disk format and guest driver steps against your own environment before cutover.

Do we need a paid Proxmox support subscription for production?

The software runs without a subscription, but the Proxmox package repositories documentation says the enterprise repository, which requires a valid subscription key, is the recommended choice for production. The free no-subscription repository is described for testing and non-production use. Support tickets are tiered: Community includes no tickets, Basic includes 3 tickets with a 1 business day response, Standard includes 10 tickets with a 4-hour response, and Premium includes unlimited tickets with a 2-hour response. Decide based on your uptime needs, internal skills and whether a partner covers the troubleshooting you cannot handle in-house.

How does Ceph change our staffing needs?

Ceph adds a storage layer your team must run, so it changes staffing more than the hypervisor does. Ceph's hardware recommendations call for a dedicated drive per OSD, shared SSDs for WAL and DB on HDD-based OSDs, enterprise-class SSDs for metadata, and bonded network links across two switches. Staff must understand placement, failure recovery, capacity planning and upgrades. Ceph releases are tracked in named series, and Squid's estimated end of life is October 31, 2026, while Tentacle's is June 1, 2027, so plan upgrades around those dates. The Ceph hardware guidance also says to size memory for peak use and benchmark before buying. Without a Ceph-experienced owner, the storage layer becomes the main operational risk.

How long will Proxmox VE 9 receive security updates?

Proxmox VE releases are supported at least as long as the matching Debian release has security support, roughly three years according to the Proxmox FAQ. Proxmox VE 9.0 was released on August 5, 2025 on Debian 13, and Proxmox VE 9.2 followed on May 21, 2026. Proxmox VE 8 on Debian 12 reaches end of life in August 2026, so any Nutanix migration that lands on 8 will need a plan to upgrade. Check the current support dates in the FAQ before you commit to a version, and include the next major upgrade in your operating plan.

How DeployOpen scopes, runs and supports the migration

DeployOpen is a Chainscore Labs company that plans, implements, hardens, backs up and documents self-hosted open-source platforms inside the client's own infrastructure, including their cloud accounts, data centers or air-gapped networks. For a Nutanix exit, that work typically covers the Proxmox VE cluster design, the Ceph layout on the reused nodes, the cutover runbook and the operating documentation your team inherits. DeployOpen does not hold any vendor partnership or certification for Proxmox VE or Ceph, so the scope should be checked against the platform documentation your own engineers will use.

Engagements are fixed-scope. Before work starts, the scope, deliverables and timelines are agreed in writing, and that document should name the VM inventory in scope, the export path from Prism Central, the storage and network mapping, the rollback criteria and the acceptance tests for each wave. DeployOpen does not publish a price list. A quote follows from the written scope, so the useful inputs are the number of VMs and disks, how many of them carry large or multi-disk workloads, which Nutanix features (snapshots, protection domains or replication) the business depends on, and how many nodes are being reused. Ask for the quote to separate one-time migration work from recurring items, and to state which Proxmox VE subscription tier, if any, is assumed.

After cutover, ongoing support, upgrades and continuous testing are available as retainers. This matters for Proxmox VE because the release cadence follows Debian, and each major Proxmox VE version has a finite support window tied to the matching Debian release. Agree in advance who applies minor updates, who plans major upgrades, and who responds to a failed node in a Ceph cluster. Confirm the retainer scope in writing, and confirm with Proxmox Server Solutions which support tier your environment requires, since that subscription is separate from any DeployOpen engagement.

Migrate from Nutanix to Proxmox VE