Migrating from VMware to Proxmox VE: a step‑by‑step work plan

Where a migration starts and what problems it solves

Moving from VMware to Proxmox VE usually doesn't start with installing a new cluster, but with answering a simple question: which problem do you want solved in 3–6 months after the move. Reasons are usually practical: rising TCO, desire to reduce vendor lock‑in, clearer support model and faster scaling.

Migration is almost always about risk. The most common issues are unplanned downtime, surprises with drivers and guest agents after V2V conversion, and errors at the network and storage level (VLAN, MTU, different access modes to LUN or NFS). In documentation it looks neat, but these issues surface on the first production VM move.

Before technical work, agree with the business on basics: which services are critical and in what order they will be switched, acceptable downtime (minutes or hours), who and by what criteria decides on rollback, how long to observe after switch, and which changes are forbidden during migration (freeze releases).

A simple benchmark: success is measured not by the fact of migration, but by users hardly noticing. Typical success criteria include availability (service is up and stable), performance (no degradation on key metrics) and operability (backups run, monitoring sees VMs, admins know where to check logs).

Example: if you have accounting, a file server and several internal web services, it makes sense to first move a less critical web service and validate network, backups and recovery. Only then plan a switch window for accounting.

If you run the project with an integrator, it’s useful to fix responsibility boundaries upfront: who is responsible for hardware, network and 24/7 support, and who handles the migration and service validation. At GSE.kz, for example, these zones are often separated so the customer has no “gray” areas about who should act.

Project boundaries and acceptance criteria

To prevent the migration from becoming endless, define scope up front: what will be moved and what remains. Common options: move the whole cluster at once, migrate ESXi hosts one by one, or move only a subset of VMs (for example non‑production) to validate the approach.

Decide whether to migrate associated objects: VM templates, ISO libraries, tags and folders, placement rules, backup policies and scheduled tasks. Some VMware settings have no direct equivalents and should be redefined in clear rules—for example which VMs must live on fast disks, which can be on capacity storage, and which require HA.

Also identify which services are actually affected. If your scope includes AD, databases, file servers, VDI or critical external integrations, they need separate test plans and a dedicated maintenance window. For VDI latency and network are most important; for databases you need disk consistency and a clear stop/start procedure.

Record constraints explicitly: guest OS and app licenses, security requirements (segmentation, logging, access control), data localization and bans on moving backups offsite.

Acceptance criteria are convenient as a checklist of "before" and "after":

• VMs boot and see their disks and network. Names and IPs do not change without agreement.
• Key services pass functional tests (user login, file access, DB queries).
• Performance meets agreed thresholds (CPU/RAM/disk, response times).
• Backups run and at least one VM is test‑restored.
• There is a documented rollback plan and confirmed downtime window.

Sign off these criteria in advance to avoid disputes like “it seems to work” after cutover.

Inventory: what to collect before the first step

Migration projects often fail not because of conversion, but because of forgotten details: “who owns this VM”, “what is its IP”, “why does it run a nightly job”, “where does traffic go”. Start with an inventory and make it a single document understandable to both IT and service owners.

Begin with a VM list. For each VM record OS and purpose (e.g. 1C, file server, domain controller), business criticality, owner and contacts for scheduling. Mark systems where even a 15‑minute downtime is unacceptable and those that can be stopped for an hour.

Next collect numbers: allocated resources (vCPU, RAM, disk sizes and types) and actual load on a normal day and at peak. If you have disk metrics (IOPS, latency), keep them to compare later and not mistake migration issues for existing behavior.

Dependencies are equally important. Many VMs have invisible ties: app‑to‑DB links, integrations, scheduled jobs, nightly exports and backups. Note special cases that could block migration: disk encryption, hardware keys, very old OSs, special drivers or license bindings to virtual hardware.

For each VM run a short checklist:

• who owns the service and who approves the switch
• which resources and typical load
• which other systems are required and when they communicate
• any special requirements (encryption, keys, legacy)
• network setup: VLAN, IP, gateway, important routing rules

Simple example: a clinic has a VM for the reception system and a separate VM for the database. If you don’t record that a nightly exchange with an external system uses a specific VLAN, the migration may be “successful” yet patient records won’t open in the morning.

Target Proxmox VE architecture: cluster, network, storage

The target architecture sets rules for the whole migration: how you ensure availability, where VM disks live, and what happens if a node or link fails. Mistakes here lead not to inconvenience but to outages and complex rollbacks.

Cluster: single node or HA

For a lab or small site without availability requirements, a single node can be a reasonable start. For critical services choose a cluster of at least three nodes to survive one host failure and keep quorum.

Before choosing, answer: which VMs must auto‑start, how many minutes of downtime are acceptable, and is there a separate site or backup contour.

Network and storage: separate roles

In Proxmox VE it’s important to separate traffic by purpose: management, VM traffic, migrations and storage. Use separate VLANs or physical interfaces so migrations or backups don’t throttle business services.

Storage choices typically include: local disks (fast and simple), ZFS (great for integrity and snapshots), external SAN (if already in place) or Ceph (for distributed cluster storage). Hybrids are common: OS and some VMs on ZFS, large volumes on SAN.

Guidelines that help:

• For simple HA choose 3+ nodes and a clear quorum scheme.
• ZFS is good for predictability and checks; Ceph makes sense if you accept more operational complexity.
• Use at least a management network and a separate path for storage or migrations.
• Apply least‑privilege access and enable auditing.
• Plan CPU/RAM spare capacity and fast disks; cluster scenarios often need 10/25G networking.

Example: an org with 30–40 VMs, 10 critical, typically picks a 3‑server cluster (e.g. on GSE S200 class platforms), ZFS on each node for fast disks and separate networks for management and migration. This gives a clear operational model and reduces cutover risk.

Site preparation: installation and basic setup

Before moving the first VM, bring the site to a predictable state. Most issues aren’t caused by disk conversion but by small things: mixed firmware versions, BIOS modes, drifting time or DNS.

Start with servers. Update BIOS/UEFI, storage controllers and NIC firmware to agreed versions. Decide how disks are presented to the hypervisor: via RAID controller (for simplicity) or HBA/pass‑through (if you plan software storage). Check BIOS/UEFI settings: enable CPU virtualization (VT‑x/AMD‑V) and IOMMU if needed, set correct boot order, and disable power‑saving modes that cut performance.

After installing Proxmox VE set node basics: hostname, IP, gateway, DNS, timezone and NTP. Time must match across nodes or strange cluster, certificate and log issues appear.

Define repository and update policies. Agree how often nodes are updated, who performs updates and how to roll back if an update affects operation. Bring all nodes to the same version and schedule regular update windows.

Once nodes are ready, create the cluster and plan naming, tags and resource pools. A simple rule: a name should show site, rack and role.

Before migrating the first VM do a quick check: are VLANs/bridges present, do storages mount, is there enough space, can you create and boot a test VM. This takes about 15 minutes but saves hours on migration day.

P2V/V2V steps: moving and initial VM checks

VM migration usually comes down to two questions: which method to use and how to quickly detect hidden issues after first boot. Common paths: V2V conversion, export/import images (OVF/disks) or restore from backup if supported.

Prepare each VM before migration or you’ll bring old problems into the new environment. Remove unnecessary snapshots and consolidate them, check the guest filesystem, free disk space (especially on system disks) and shut down the VM cleanly.

A practical sequence:

• Choose the migration method for the VM.
• Convert disks and decide on the format: qcow2 for snapshot convenience, raw for maximum speed.
• Select the disk controller and NIC type. VirtIO usually performs best but may require guest drivers.
• After the first boot remove or replace VMware Tools, install qemu‑guest‑agent and needed drivers.
• Run a short test: network (IP, DNS), key services, user logins, basic load and log review.

Example: a Windows server boots after migration but network drops after a minute. A common cause is vmxnet driver or conflict with VMware Tools. The fix is usually: remove VMware Tools, install VirtIO drivers and reboot.

Record results for each VM: what was changed (driver, controller, boot order), time spent and steps to repeat during the production window. This turns a one‑off success into a predictable procedure.

Network and storage: configuration and common pitfalls

Network and storage cause most surprises. A VM may convert fine but not reach the network or suffer from poor I/O due to different disk models and cache settings.

For networking map the logic: which VLANs were on vSwitch and port groups, which physical NICs carry them, and which bridges you will create on Proxmox nodes. Check MTU: if jumbo frames are used for storage and one segment has mismatched MTU you’ll see packet loss and long timeouts.

To test VMs alongside the old environment, plan IP and DNS carefully. A typical scenario: you place the migrated VM in a test VLAN but DNS still points to the production IP, so users reach the wrong instance and logs become confusing.

Practices that reduce risk:

• Use a separate VLAN or temporary IP range for tests.
• Track MAC/IP changes to avoid conflicts.
• Plan DNS switchovers considering TTL and caches.
• Verify DHCP reservations and bindings.
• Document which switch ports should be trunks and which VLANs are allowed.

Firewalls: Proxmox rules can live at datacenter, node and VM levels. Migrate them as a managed rule set with an owner and scope. A good habit is to enable minimal access (admin and service ports) first, then tighten rules as checks pass.

For storage decide thin/thick policy, quotas and features like deduplication ahead of time. The same guest disk size can have very different impact on the pool with thin provisioning.

Before production cutover run basic performance and connectivity tests: measure read/write speeds inside a VM, check latency to the storage array and copy a large file between VMs in different VLANs. Instability in tests often becomes an outage during the window.

Backups and recovery before cutover

Agree on data goals and downtime limits before migration. Different VM groups have different needs: accounting may tolerate longer downtime, while patient records or payment gateways can’t. Record RPO (how much data you can lose) and RTO (how fast the service must be restored) and classify VMs as critical or non‑critical.

Create a full control backup before any conversions and actually restore it once to a test environment—having a backup is not the same as being able to restore it. The check should include OS boot, app access and data integrity.

Plan backup load so it doesn’t overwhelm migration. Bulk copying often saturates network and disks, lengthening maintenance windows and slowing V2V conversions. Choose timing, limit concurrency and monitor IOPS and bandwidth.

Document in writing:

• RPO/RTO per VM group and priority order
• a full backup with date and test restore result
• where copies are stored: separate storage, isolation, access rights
• schedule and load limits during migration
• fallback plan to backups if rollback fails

Example: for a critical DB VM take a full backup to separate storage, test restore on a lab node, then create a final increment before cutover and fix the recovery point for rollback.

Example migration scenario: waves, not one big cut

For a company of 50–200 users with 25–40 VMs and two sites, the wave approach works well: you validate everything in parts rather than one risky leap.

Divide VMs by risk and dependencies: start with things you can quickly recover and easily rollback, then move progressively to critical services. Typical waves: test (dev, auxiliary services, 1–2 VMs for V2V/network checks), pilot (a small department), then core services (file servers, ERP, DBs, terminal services), and finally peripherals (monitoring, printing, secondary web, archives).

To avoid impacting production, bring migrated VMs up in an isolated network or with temporary IPs and validate access to disks and applications. For data‑heavy services, replicate or delta‑sync and perform final import in the cutover window before changing routing, DNS or VIPs.

Sample schedule: Friday night move a wave and do initial checks, overnight switch users and services in agreed order, morning quick checks with business and sign off.

Agree what you measure before and after:

• VM boot time and service startup time
• app response (login, open form, typical operation)
• errors in logs and user incident categories
• CPU/RAM/disk/network load at peak
• actual downtime per service

If using an integrator, assign them to collect metrics and keep a single change log so each wave ends with a clear status: done, needs approval, or rollback.

Cutover window and rollback: clear sequence

The cutover window is the short period when you switch services from VMware to Proxmox VE. This is where a migration either goes smoothly or becomes a night emergency. The idea is simple: agree in advance what you do, who does it and by which signs you rollback.

Before the window prepare the organizational basics: freeze changes (releases, firewall edits, disk expansions), send notifications with expected unavailability, assign roles (network, apps, business communications), collect contacts and accesses, and prepare acceptance checks for each service.

The order is usually the same. First bring up infrastructure services (DNS, DHCP, AD/LDAP, monitoring, backups), then core apps (DBs, queues, file services) and only then secondary VMs. If accounting depends on SQL and domain, verify domain auth and DB access before starting the application VM.

The rollback plan must be as concrete as the switch plan. Define stop signals and who says “rollback now.” Common triggers:

• a critical function is down longer than agreed (e.g. 30–60 minutes)
• discovered data loss or desynchronization
• basic network checks fail (routing, NAT, storage access)
• performance drops to unacceptable levels
• no progress on a fix within a fixed time

Rollback is usually returning VM execution to VMware, reverting DNS (lowering TTL beforehand helps), routing and NAT. Important: rollback is a predefined procedure, not “we’ll sort it out later.”

After cutover run post checks: service access from user desktops, data integrity (especially DBs), error logs, CPU/RAM/disk loads and monitoring alerts. If you don’t have an on‑call team, involve the integrator with 24/7 support and an SLA so rollback decisions are quick and fact‑based.

Common mistakes and how to avoid them

Major failures usually come from small things: network, backups and the process order.

First trap — underestimating the network. If the old environment used VLANs, jumbo frames and separate NICs for storage, reproduce these deliberately in the new setup. Mismatched MTU often appears as “sometimes it works”: VMs ping but DBs break under load.

Second — migrating without checking restores. Having a backup != being able to restore. At minimum restore one test VM in an isolated network and verify login, data and service start.

Third — too big a first step. Moving all critical VMs at once turns any unknown into a business outage. Start with one or two medium‑importance systems, refine the process, then move to core systems.

Fourth — last‑minute changes: patches, DNS edits, firewall rules or adding a server. This breaks the plan and makes root cause analysis harder.

Reduce risk by assigning service owners, defining acceptance criteria (what “works” means: metrics, users, reports), forbidding unplanned changes during the cutover, performing a separate network check (VLAN, MTU, routes, storage access) and testing backup restores before the window.

Another common failure is ignoring licensing and regulatory requirements for data and logs. In government and finance this is critical: retention periods, data location and log access. Check these before migration, not after.

Short checklists and next steps after migration

Most post‑migration issues are small: missed fresh backup, an unsigned window, VLAN misconfiguration or missing access. The checklists below help avoid critical misses.

Mini checklist before start

• Inventory: VM list, roles, dependencies (AD, DNS, DB), criticality and allowable downtime.
• Backups: when taken, where stored, test restore exists on a separate VM.
• Test migration: one non‑critical VM passed V2V and boots without errors.
• Network diagram: VLANs, gateways, DNS, firewall rules, responsibilities.
• Storage: target disks for VMs, space and IOPS for peak loads.

Mini checklist before the cutover window

24–48 hours before, confirm the runbook and roles:

• Freeze changes: forbid updates and config edits in VMware.
• Notifications: business, support, owners, start and end times.
• Rollback plan: failure triggers, wait times and reversal steps.
• Access: consoles, accounts, passwords, network and storage equipment access.
• Checkpoint: final backup/snapshot and confirmation it’s readable.

After cutover, monitor intensively for the first 2–4 hours: CPU/RAM, disk latency, network errors, Proxmox and guest logs. Prepare a short “symptom → action” list, e.g. steps for time issues, network drivers or disk performance.

Then tidy up: standardize VM templates (drivers, agents, disk settings), schedule regular updates and maintenance windows, document final network and storage layout, and fix backup rules and RPO/RTO.

If you need help not only with migration but also with server selection, deployment and ongoing operations, it’s convenient to have one party responsible for the whole stack. GSE.kz (gse.kz) acts as a server manufacturer and systems integrator and provides 24/7 technical support, which often simplifies post‑migration operations.