Hello,

I would like to get some feedback from the Proxmox development team before we invest further development effort into a VMware/NSX-to-Proxmox migration project, in particular to avoid duplicating functionality that may already be planned for PVE or PDM.

We are currently evaluating large-scale migrations from VMware vSphere + NSX to Proxmox VE.

The existing ESXi importer already provides a solid foundation for VM migration, while PVE SDN/firewall and the ongoing PDM development increasingly provide the target networking and security control plane.

We are currently testing different approaches and are particularly interested in the transition from the VMware/NSX environment to a native Proxmox environment, rather than building another permanent Proxmox network/security controller.

One migration model we are considering would be :

discover vCenter and NSX inventory: VMs, networks/segments, IP/MAC information, groups/tags, services and DFW policies;
Understand and resolve the effective NSX security policy applicable to each workload;
migrate workloads to PVE while preserving their existing IP addressing whenever possible, using temporary L2 coexistence between NSX and PVE;
translate the effective NSX DFW policy into native PVE firewall objects such as Security Groups, IP sets and VM/VNet firewall rules;
translate workload-centric rules with the appropriate direction semantics, for example source membership to PVE OUT policy and destination membership to PVE IN policy;
validate security-policy and network-flow parity between the source NSX environment and PVE during coexistence;
progressively hand over each network's gateway/routing from NSX to PVE SDN/EVPN/BGP;
provide pre-checks and rollback at the VM, security and network-cutover stages;
leave no permanent runtime dependency on the migration tool once the VMware/NSX environment has been retired.

We are currently experimenting with VM migration, PVE SDN/EVPN connectivity and the feasibility of translating NSX security groups and policies into native PVE firewall constructs.

Before going further, particularly with same-address coexistence and network handoff, I would appreciate Proxmox's guidance on the following points:

1. Is NSX-aware migration already planned or being worked on within Proxmox, publicly or internally?

In particular, are there plans around NSX DFW/security-policy migration, NSX network preservation, or staged migration from NSX networking to PVE SDN?

2. Do you see this functionality primarily as an external migration/transformation tool using PVE/PDM APIs, or do some of these functions belong in PVE or PDM themselves?

We explicitly do not want to develop a competing permanent SDN/firewall control plane if PDM is intended to provide that functionality.

3. For an external migration tool, what would you consider the preferred and sufficiently stable API integration points?

In particular for VM migration, SDN/VNet provisioning, EVPN/BGP configuration, Security Groups/IP sets, guest/VNet firewall policies and multi-cluster orchestration through PDM.

4. Would effective NSX-policy translation and policy-parity validation be useful functionality from Proxmox's perspective?

For example, resolving dynamic NSX group memberships and the effective DFW policy for a VM, compiling that intent into native PVE firewall objects, and comparing the resulting effective policy before cutover.

5. Does the proposed same-address migration model fit the intended PVE SDN architecture?

The idea is to temporarily extend the existing NSX L2 network to PVE, migrate the workloads while keeping IP/gateway addressing unchanged, and only later hand the gateway/routing function over from NSX to PVE EVPN/BGP on a network-by-network basis.

6. Is low-downtime/incremental VMware migration already in scope for the existing importer?

We are particularly interested in whether a VDDK/CBT-style precopy/delta mechanism, or another warm-migration mechanism from ESXi, is already planned.

7. Are there generic PVE/PDM capabilities that would be useful to implement upstream for this use case?

Possible examples are effective-firewall-policy inspection, policy diff/validation, dry-run APIs, structured external-migration prechecks, or bulk firewall/IP-set operations.

8. If some of these pieces would be appropriate upstream, where would you prefer them to live and what development interfaces/conventions should we target?

For example PVE vs PDM, the appropriate repositories and APIs, Rust vs existing PVE components, expected test coverage and contribution workflow.

Our intention would be to keep all VMware/NSX-specific discovery and transformation logic in the migration tooling, while contributing only genuinely generic Proxmox capabilities upstream if that is of interest.

Once the migration is complete, the resulting environment should consist solely of native PVE/PDM SDN and firewall configuration and should not depend on the migration tool for normal operation.

I would be happy to share a more detailed architecture or the results of the current proof of concept if useful.

Best regards,

		Vincent LIONNETON Infrastructures Consultant
		Sword Switzerland +41(0)22 594 91 16 vincent.lionneton@sword-group.com	Business Park Terre-Bonne, Bâtiment A1, Route de Crassier 7, 1262 Eysins (Nyon)
		sword-group.com	Follow us on LinkedIn \| YouTube \| Twitter/X \| Facebook
		This message and all attachments are for the exclusive use of the recipients and are confidential. If you receive this message in error, please destroy it and immediately notify the sender and/or privacy@sword-group.com. Any use of this message that does not conform to its destination, any distribution or publication, in whole or in part, is prohibited, unless expressly authorised. As the Internet cannot ensure the integrity of this message, Sword Group (and its subsidiaries) declines all responsibility with regard to this message, in the event that it has been modified, altered or falsified. Sword Group thanks you for your attention.