From PVE 5 to 9: Migrating Legacy Proxmox Workloads Safely
Inheriting someone else's infrastructure brings its own kind of stress. I don't mean the clean, well-documented kind, or the "we'll migrate this next quarter" kind. I mean the deeply lived-in, mission-critical, slightly dusty stack that's been humming along for years because one person knew exactly how it worked, and now that person isn't around anymore.
That's the situation with a small business still running on Proxmox VE 5.4-15, a version old enough to feel like a time capsule. And now it needs to jump all the way to 9, several major versions in one go.
When "it still works" isn't enough
On paper, the setup wasn't massive: two nodes, a handful of VMs, and a NAS for backups, with nothing exotic in the mix.
One node had already been limping along on 8.x before its drives started failing. It got replaced with a new Supermicro micro server running a clean install of Proxmox 9, and things were actually... smooth. Backups via Proxmox Backup Server were working, and migration off the dying node went well. So far, so good.
Then there's the old PVE 5 box, which is where the real ghosts live.
The NAS that chokes
Backing up the remaining mission-critical VMs should be simple, in theory. In practice, sending backups from PVE 5 to the NAS nearly cripples it.
The NAS is a TerraMaster box in RAID 5 with a single 1Gb NIC. It isn't running the VMs themselves; it just acts as a mounted backup target. But when a backup job kicks off, everything slows to a crawl. The NAS bogs down, the network groans, and it feels like you're pushing it one job closer to retirement.
The NAS is already on the upgrade list, but the replacement isn't here yet. So what do you do when the act of protecting your data might be the thing that breaks your storage?
The community's response was refreshingly pragmatic: slow it down. Rate limiting isn't flashy and doesn't feel like a "big solution," but setting bwlimit in /etc/vzdump.conf to cap transfer speeds, say 50MB/s, can be enough to stop the NAS from drowning under write pressure. The same idea works on the PBS side using traffic control rules. It's neither glamorous nor modern, but it works.
The temptation to skip steps
There's always that thought in the back of your mind: what if we just upgrade in place? Go 5 to 6, 6 to 7, 7 to 8, and 8 to 9, following slow, methodical, supported paths.
Except this is a working business, and the VMs in question run ancient custom software that nobody quite knows how to rebuild from scratch. One of them is Windows 7, with no internet access, running a core service, and untouchable in the most terrifying way. The others are Windows 10, lightly connected but still critical.
If those break, there isn't a reinstall script waiting in a Git repo, and there isn't documentation. There's just anxiety. That's what makes this jump from 5 to 9 feel less like an upgrade and more like open-heart surgery.
The i440FX warning that won't go away
After migrating some VMs to the Proxmox 9 node, a new warning appears:
Machine type 'pc-i440fx-5.1' is deprecated. Current machine version is subject to deletion.
It's not an error, and everything boots, but it's a ticking clock.
The old i440FX machine type emulates a legacy PCI-based chipset. Modern Proxmox prefers Q35, which emulates a PCIe-based platform. On paper, that sounds minor, just virtual hardware under the hood. In reality, it's a platform swap.
Switching from i440FX to Q35 takes more than flipping a dropdown. It can trigger device reinitialization, new virtual NICs, and a new PCI topology, so Windows might see entirely new hardware. That can mean:
- Possible new IP addresses
- Driver shuffles
- Activation hiccups
- That awful "Installing device driver software..." pause
On a lab VM, that's fine. On a Windows 7 box running core business software that nobody wants to touch, it's a white-knuckle reboot.
The advice from seasoned admins was blunt: treat it like new hardware, plan for device re-detection, expect to reconfigure networking, and don't assume it'll be invisible. They also said not to panic. In most cases it works; it just requires deliberate handling.
An unwritten rule: don't cluster across generations
One piece of advice stood out clearly: don't cluster 5.x with 8.x or 9.x. The API differences alone can cause headaches, and it's not worth it. If you're still on 5, don't try to build a hybrid Frankenstein cluster.
Nuke and pave instead. Build fresh, restore backups, upgrade virtual hardware after landing in a modern release, and then upgrade guest tools. That clean break is often less risky than incremental patching through half a decade of changes.
The "just copy the disk" argument
There's always someone who suggests it, and they have a point. If the VM disk is a qcow2 file, rsync it. If it's LVM, use dd and ncat. Power the VM down, copy the disk, and recreate the config from /etc/pve/.
It's technically sound and emotionally terrifying, because copying a disk image feels like bypassing the "official" path. It feels like duct tape, even when it's not.
Proxmox VMs are mostly just disk files and configuration text, with no magic database hidden somewhere. If you understand what you're copying, it's perfectly valid. What matters is downtime: the VM must be offline, with no half-measures. And in many migrations, that direct disk copy is faster and less punishing on fragile storage than repeated backup cycles.
There's also the Veeam route
For Windows VMs, another option came up: treat them like physical machines. Tools like Veeam Backup & Replication can back up a Windows VM at the OS level and restore it into a new environment, which abstracts away the hypervisor jump. That's attractive when the hypervisor version gap feels dangerous.
It does introduce another layer, another tool, and another dependency, though, and sometimes simpler really is safer.
The emotional weight of legacy systems
One detail in this story matters more than any bandwidth limit or machine type flag: this environment belonged to someone who cared deeply about keeping it running, and now someone else is carrying that responsibility forward.
That changes how you approach risk. You don't want to be the person who "modernized" everything into downtime, or who broke the one Windows 7 VM that runs an ancient custom app no one understands. So you move carefully. You test backups repeatedly, verify PBS jobs, and ask the community before touching machine types. You respect the system, even if it's outdated.
What actually happens when legacy refuses to let go
Legacy infrastructure doesn't fail all at once; it degrades in layers. First it's the drives, then the warnings, then the unsupported versions, then the backup bottlenecks. Each layer whispers the same thing: "You should've upgraded earlier."
But small businesses don't always have upgrade budgets, spare hardware, or downtime windows. So environments like this survive longer than they should, and when the upgrade finally comes, it's a leap across years.
The good news is that Proxmox is surprisingly resilient across generations. With proper backups, offline disk copies, and careful hardware transitions, jumping from 5 to 9 is doable. Most of the risk sits in the unknown custom workload inside those Windows VMs, more than in Proxmox itself.
The playbook that emerges
Stripped down to essentials, the strategy looks like this:
- Ensure verified backups via Proxmox Backup Server.
- Rate limit backups to avoid crushing old NAS hardware.
- Avoid clustering mixed major versions.
- Restore onto fresh 8.x/9.x nodes.
- Upgrade virtual hardware deliberately.
- Test before touching machine types.
- Treat i440FX to Q35 as a platform migration rather than a cosmetic change.
It's plain, disciplined execution, and that discipline is what keeps small businesses alive during transitions like this.
And that Windows 7 box?
It's still there, still running, and still isolated from the internet like a museum exhibit behind glass. Eventually it'll need to move, or retire, or be virtualized inside another VM like some kind of digital nesting doll. For now, it just needs to survive the hypervisor jump, and honestly, that's enough.
Sometimes modernization means carrying forward what already works, carefully and respectfully, without breaking the things that keep the lights on.