Proxmox 8 to 9 Migration: hands-on experience and methodology
Proxmox VE 9.0 was released in June 2025, based on Debian 13 Trixie. We migrated our entire production infrastructure to Proxmox 9.1 in December 2025; the fleet is updated monthly, in full, and runs Proxmox VE 9.2 today. This article details our methodology, our kernel opt-in approach, the Debian 12 vs 13 comparison, and the technical steps for a successful migration.
Why migrate to Proxmox 9
Proxmox VE 9.x brings significant improvements across three areas: the base OS, the Linux kernel, and virtualization components. Here are the main reasons that justify the migration.
Debian 13 Trixie: long-term support
Proxmox VE 9 is based on Debian 13 "Trixie", released in June 2025. Debian 13 will receive security support until at least 2028 (LTS until 2030+). Staying on Proxmox 8 (Debian 12 Bookworm) means progressively approaching the end of active support for Debian 12 (standard support expected to end mid-2026, LTS until 2028).
Migrating now gives us a 4+ year margin on base OS support, instead of having to plan an emergency migration when Debian 12 approaches end of life.
Up-to-date kernel and new features
Proxmox 9.x ships with a recent 6.x kernel with notable improvements: better support for recent hardware (latest-gen Intel/AMD CPUs, NVMe, network cards), I/O performance optimizations, security improvements (more efficient Spectre/Meltdown mitigations), and improved io_uring support for storage workloads.
Debian 12 end of support approaching
Even though Debian 12 LTS will remain supported until 2028, Proxmox VE 8.x packages will no longer receive new features — only security fixes. New features (GUI, SDN, Ceph) will only be available in the 9.x branch. Migrating now lets you benefit from the latest improvements.
Our choice
At RDEM Systems, we migrated our entire production infrastructure to Proxmox 9.1 as early as December 2025. Zero incidents, identical or better performance, and a fresh OS base for the next 4+ years. Since then the fleet has been updated monthly, in full: it runs Proxmox VE 9.2 today — which is why the kernel we took as opt-in ended up being caught up by the release.
Debian 12 vs 13 / Proxmox 8 vs 9 — comparative study
The move from Proxmox 8 to 9 involves a complete base OS change (Debian 12 to 13). Here is a detailed comparison of key components.
System components
| Component | Proxmox 8 (Debian 12) | Proxmox 9 (Debian 13) |
|---|---|---|
| Base OS | Debian 12 Bookworm | Debian 13 Trixie |
| Kernel | 6.8.12-9 default, 6.14 opt-in | 6.17.2-1 default (9.1) |
| systemd | 252 | 256+ |
| OpenSSL | 3.0.x | 3.3.x+ |
| Python | 3.11 | 3.13+ |
| glibc | 2.36 | 2.40+ |
Proxmox VE components
| Component | Proxmox 8.4 | Proxmox 9.1 |
|---|---|---|
| QEMU | 9.2.0 | 10.1.2 |
| ZFS | 2.2.7 | 2.3.4 |
| LXC | 6.0.0 | 6.0.5 |
| Ceph | Squid 19.2.1 / Reef 18.2.4 | Squid 19.2.3 |
| GUI / Web UI | ExtJS 7 | ExtJS 7 improved + new widgets |
| SDN | OVN, VXLAN, EVPN | Improved OVN, new SDN panel |
Careful: "the" Proxmox kernel is two different things
Every Proxmox VE release ships a default kernel and, sometimes, a newer opt-in kernel you install explicitly. Conflating the two invalidates any version comparison.
- Proxmox VE 8.4 — default
6.8.12-9, opt-in6.14 - Proxmox VE 9.0 — default
6.14.8-2, no opt-in - Proxmox VE 9.1 — default
6.17.2-1 - Proxmox VE 9.2 — default
7.0, available as opt-in on 9.x before its release
The pattern repeats every cycle: the opt-in kernel of one release becomes the default kernel of the next. It holds across the whole series — 5.15 then 6.2 opt-in on 7.4, 6.8 then 6.11 on 8.3, 6.8 then 6.14 on 8.4. Going opt-in means taking early the kernel you will get anyway.
A concrete example from one of our hypervisors: it runsproxmox-ve 9.2.0 on Debian 13 Trixie, with7.0.14-6-pve. Both meta-packages are installed:proxmox-kernel-7.0 — the one you name explicitly to take a kernel early — andproxmox-default-kernel. On 9.2 both resolve to 7.0, because it has become the default: the kernel taken as opt-in was caught up by the release, exactly as expected.
Our hypervisors are updated at least once a month, across the whole fleet — which is exactly why a kernel taken as opt-in always ends up being caught up by the release. A fleet updated once a year never sees this: it jumps straight from one default to the next, with every accumulated change landing at once.
This is also why uname -r is not enough to tell whether you are on an opt-in kernel: you have to look at whichproxmox-kernel-* package is installed, and compare it with your release default.
The 8.4 opt-in kernel is the 9.0 default kernel — which is exactly what makes the method below worthwhile: you validate the Proxmox 9 kernel on your own hardware before changing the base OS. Watch out for theproxmox-default-kernel meta-package though: it tracks the default of the installed release, so on an 8.4 host it gives you 6.8, not 6.14. The opt-in kernel has to be named explicitly. Sources: Proxmox VE roadmap and the official Upgrade from 8 to 9 guide.
Concrete benefits of upgrading to 9.x: better hardware support, QEMU 10.x with improved I/O performance, more stable and performant Ceph Squid, web interface improvements, and a freshly supported Debian base for 4+ years.
Proxmox 8 vs 9: what actually changes for performance
"Proxmox 9 is faster" is not a useful answer. What changes is the version of four components that each sit on a different part of the I/O path. Whether you feel it depends on which one is your bottleneck.
| What moves | 8 → 9 | Where you would see it |
|---|---|---|
| Kernel | 6.8.12 → 6.17.2 | io_uring on storage workloads, scheduling on recent many-core CPUs, drivers for latest-gen NVMe and NICs. The largest gains are on hardware newer than the 6.8 kernel, not on an older fleet. |
| QEMU | 9.2.0 → 10.1.2 | Guest block layer and virtio paths. Matters most for I/O-heavy VMs; a CPU-bound VM will not notice. |
| Ceph | Squid 19.2.1 → 19.2.3 | Only if you run Ceph. Squid is the component with the clearest stability and behaviour changes of the four. |
| LXC | 6.0.0 → 6.0.5 | Marginal. A container was already running on the host kernel, so the kernel jump matters more than the LXC jump. |
What we observed in production. We migrated our own clusters to Proxmox 9.1 in December 2025: zero post-migration incidents, about 30 minutes per node for the dist-upgrade and reboot, and zero seconds of VM downtime thanks to live migration between nodes. On identical workloads and identical hardware, we measured no regression. Those same nodes have since followed the 9.x line: they run Proxmox VE 9.2 today with kernel7.0.14-6-pve, taken as opt-in before it became the 9.2 default.
What we did not measure, and will not claim. We did not run a synthetic before/after benchmark campaign. Our acceptance criterion was non-regression on real production workloads, not a benchmark figure. Anyone publishing a single "X % faster" number for Proxmox 8 vs 9 is describing their hardware and their storage, not the hypervisor. If your bottleneck is disk latency on recent NVMe, the kernel and QEMU jumps are where your gain is; if you are CPU-bound on older hardware, expect parity, not a boost.
Proxmox 8 end of life, and which Debian each release is based on
Proxmox VE 9 is based on Debian 13 "Trixie", released in June 2025. Proxmox VE 8 is based on Debian 12 "Bookworm". That base OS is what drives the support window, so the two questions are really one.
| Proxmox VE 8 | Proxmox VE 9 | |
|---|---|---|
| Debian base | Debian 12 Bookworm | Debian 13 Trixie (June 2025) |
| Standard security support | expected to end mid-2026 | at least 2028 |
| Debian LTS | until 2028 | 2030+ |
Practically: staying on Proxmox 8 means planning an upgrade under time pressure once Debian 12 leaves standard support. Moving now buys a four-year runway on the base OS. Check the Debian release schedule for the authoritative dates.
One product, not three. This page covers Proxmox VE (the hypervisor) and its pve8to9 path. Proxmox Backup Server has its own upgrade path (pbs3to4, PBS 3.x to 4.x) and Proxmox Mail Gateway another (pmg8to9). The three follow the same Debian 12 to 13 base change but are not interchangeable: run the checker matching the product you are upgrading.
Our approach — kernel opt-in
Before launching the full dist-upgrade from Debian 12 to Debian 13, we chose to use the kernel opt-in method. This approach involves installing the Proxmox 9 kernel on your existing Proxmox 8 installation, without migrating the base OS.
Why kernel opt-in?
- Version control: you choose exactly when to switch to the new kernel, independently of the dist-upgrade. This lets you validate the kernel on your specific hardware before changing anything else.
- Easy rollback: if the new kernel causes issues (GPU driver, exotic network card, third-party DKMS module), simply reboot on the old kernel via GRUB. No dist-upgrade rollback required.
- Production stability: validate the kernel first (the most critical component), then perform the dist-upgrade in a second step. Two stages instead of a big bang.
How to proceed
Installing the opt-in kernel takes just a few commands:
# 1. Make sure you're on Proxmox 8.4 (latest 8.x version) apt update && apt dist-upgrade # 2. Install the Proxmox 9 kernel meta-package apt install proxmox-kernel-6.14 # 3. Pinning: ensure the new kernel takes priority proxmox-boot-tool kernel pin 6.14.11-4-pve # adjust to exact version number # 4. Reboot on the new kernel reboot # 5. Verification after reboot uname -r # should display 6.14.x-x-pve pveversion # still Proxmox 8.4, but with 9.x kernel
Important
The kernel opt-in is an optional step. We chose it for performance reasons — the significant gains from the new kernel justified prior validation on our production hardware. You can skip straight to the dist-upgrade if you are confident in your hardware.
Proxmox 8 to 9 migration steps
Here are the detailed technical steps we follow for each migration. Also refer to the official Proxmox documentation .
Audit and preparation
First, check the state of your infrastructure:
# Check current version pveversion -v # Run the official checker pve8to9 --full # Check disk space (minimum 5 GB free) df -h / # Back up cluster configuration tar czf /root/pve-config-backup.tar.gz /etc/pve/ # Check Ceph health (if applicable) ceph status ceph osd tree
Update to Proxmox 8.4
Make sure you are on the latest 8.x version before migrating:
# Full update to 8.4 apt update apt dist-upgrade -y # Reboot if a new kernel was installed reboot # Verify pveversion # should display 8.4-x
Migration to Proxmox 9.1
Update the repositories and launch the dist-upgrade:
# Update APT sources to Debian 13 + PVE 9 sed -i 's/bookworm/trixie/g' /etc/apt/sources.list sed -i 's/bookworm/trixie/g' /etc/apt/sources.list.d/pve-*.list # Or better: manually edit each file # Update and dist-upgrade apt update apt dist-upgrade -y # Answer configuration prompts # (keep local version unless otherwise specified) # Mandatory reboot reboot
Post-migration verification
After rebooting, verify everything is working correctly:
# Proxmox version
pveversion -v # should display the latest published 9.x (9.2 today)
# Kernel
uname -r # should display the default kernel of your release
# 6.17.x-x-pve on 9.1, 7.0.x-x-pve on 9.2
# Proxmox services
systemctl status pvedaemon pveproxy pvestatd
# Cluster (if multi-node)
pvecm status
# Ceph (if applicable)
ceph status
ceph osd versions # should display Squid
# VMs and containers
qm list
pct list
# GUI access: https://node:8006Official documentation: for full details and edge cases, refer to the official Proxmox 8 to 9 migration guide .
Our hands-on experience
We migrated our entire production infrastructure to Proxmox 9.1 in December 2025. Here is our concrete feedback.
Migration scope
- Multi-node production clusters
- Ceph storage already on Squid before cutover — official prerequisite
- PBS 3.x to 4.x — continuous backups without interruption
- SDN OVN — configuration preserved
Results
0
post-migration incidents
~30 min
per node (dist-upgrade + reboot)
0 s
VM downtime (live migration)
Migration pricing: to learn about our Proxmox 8 to 9 migration packages and support details, see our detailed pricing on RDEM Managed Services .
Prerequisites and key considerations
Key considerations
- Ceph: never migrate more than one Ceph node at a time. Wait until the Ceph cluster is in
HEALTH_OKbefore moving to the next node. A hyper-converged Ceph cluster must already be running Squid 19.2 before you start the upgrade: that is an official prerequisite, not a step of the dist-upgrade. Rebalancing after each node can take time. - Extensions and DKMS modules: if you use third-party kernel modules (NVIDIA GPU drivers, proprietary Intel network cards, custom ZFS), verify their compatibility with the new kernel before migrating. The kernel opt-in is your best tool for this validation.
- Backup before migration: perform a full backup of all your VMs and cluster configuration (
/etc/pve/) before starting. Use NimbusBackup or PBS for a complete backup before the maintenance window. - HA (High Availability): if your VMs are managed by the HA Manager, temporarily disable HA resources on the node you are migrating. Re-enable them once the node is back in the cluster running version 9.
- Custom repositories: if you have added third-party APT repositories (Zabbix, Docker, Grafana...), make sure they offer packages for Debian 13 Trixie before the dist-upgrade. Otherwise, temporarily disable them.
Official documentation
Frequently asked questions
Related articles
Also read on our blogs
Need help migrating to Proxmox 9?
RDEM Systems delivers turnkey Proxmox 8 to 9 migrations. Infrastructure audit, kernel opt-in, dist-upgrade and full validation — zero downtime in cluster environments.