Subscriptions and new hardware

Sep 7, 2025
20
1
3
What, if any, are the options for having an "overlap" on subscriptions when bringing a new Proxmox cluster online on new hardware?

Basically, I have an existing cluster with subscriptions and a brand new cluster with new hardware. I understand I can move the subscription between the two, but I would prefer to get the new cluster all set up and updated, ready to roll, while leaving the existing cluster with the subscriptions, then move the VMs over and ditch the old hardware.

I could just buy new subscriptions, but halfway through a year's subscription, that is kind of expensive. I am willing to pay something, just not lose half a year's subscriptions. Something like a one-month subscription to see us over the migration period would be ideal?
 
That is exactly what I am trying to avoid, having my cluster in a state where it is not getting updates. Support is less of an issue as I am unlikely to use it. Lack of updates however in the cyber security environment of 2026 is something of a deal breaker.
 
You should really ask https://shop.proxmox.com/contact.php for a recommended/safe procedure. Probably you are not the first person with this "problem".

Please post their answer here :-)
 
@niteshadow While technically you could, you are breaking two golden rules:
  • Good practice dictate to have the same package versions on every node.
  • Each server in your cluster needs its own subscription based on its specific socket count. All nodes within a cluster must be subscribed at the same level to ensure repository consistency and support eligibility (from the FAQ [1]).
[1] https://www.proxmox.com/en/products/proxmox-virtual-environment/pricing
 
From a VMware perspective, you could always just install vSphere, use the 60-day trial license, and once ready, move the licenses over. Been there, done that. Looks like this is something else lacking from an enterprise perspective in the Proxmox offering. Looks like the best bet might just be some extra community licenses. My new servers are single-socket, so that does lessen the pain.
 
The way I do it:
  1. - Src cluster has subscription.
  2. - Update the nodes to latest version.
  3. - Install new servers, configure network.
  4. - Move subscription to new nodes.
  5. - Install latest packages on new nodes.
  6. - Setup Ceph, storages, backups, users, etc (if on the same cluster most of this gets imported automatically).
  7. - Migrate VMs to new servers (backup/restore, migration if on the same cluster, maybe PDM if needed, etc).
  8. - If needed remove old servers from cluster.
Unless you are going to take months to migrate, that's perfectly valid. As mentioned above, you just switch old servers to the no-subscription repo and still get updates in case some kind of zero day or breaking bug shows up during the migration.
 
Last edited:
I am going to legitimately compare VMware to Proxmox. VMware has/had a method to migrate from old to new hardware with "production" level of updates on all nodes at all times within a 60 day window at no extra cost. Proxmox does not appear to have that option. That is in my view a short coming in the Proxmox offering compared to VMware and there is nothing you can do to persuade me otherwise. Noting this option existed long before the Broadcom price hikes.

The are basically a number of "enterprisy" features in the VMware offering that Proxmox lacks and this is one of them and it IS locked behind a license cost. Displaying what is borderline hostility because someone has the audacity to compare Proxmox to VMware and finds it lacking in some way just makes one look like a jerk.
 
You can get that very same behavior on PVE, either with or without aditional subscriptions for the new hardware. I've already shown you how to do it without any extra cost.
In fact, as Enterprise repo has slightly older packages than no-subscription, you could install the very same versions that are on Enterprise using the no-subscription repo. If you really want to upgrade packages during the migration (dunno why would you), that requires some manual work to keep the very same versions on hosts using Enterprise vs no-subscription repo, but usually the differing packages are a handful.
Anyway, If you already have subscription with support, contact PVE about you use case and get an official answer for your situation.
 
  • Like
Reactions: Johannes S
Subscription (Basic plus) is mainly for support, so yes when you need support all servers in a cluster must have the same level of subscription.
Community subscription is just binaries (enterprise repo): no support from Proxmox.
Either case software is licensed open source and no cost, very flexible in how you use it.
 
You can get that very same behavior on PVE, either with or without aditional subscriptions for the new hardware. I've already shown you how to do it without any extra cost.
In fact, as Enterprise repo has slightly older packages than no-subscription, you could install the very same versions that are on Enterprise using the no-subscription repo. If you really want to upgrade packages during the migration (dunno why would you), that requires some manual work to keep the very same versions on hosts using Enterprise vs no-subscription repo, but usually the differing packages are a handful.
Anyway, If you already have subscription with support, contact PVE about you use case and get an official answer for your situation.
You are being disingenuous. The idea that you would be hand picking packages from the no subscription repo to match the enterprise repo is an utterly ridiculous suggestion. It is clear that to migrate to new hardware you are going to need additional subscriptions if you want to remain with access to the enterprise repositories for updates during the migration period. As I said with VMware you got a 60 day window for your migration at no additional cost.

Why would I be doing upgrades during a migration, well because the migration period might be measured in more than a day. I have to setup the new cluster and testing make sure it is running properly before the migration starts. It would be entirely reasonable for that to take a couple of weeks. Then add in the time to migrate the actual VM's over. Perhaps you don't care about cybersecurity, I do.

Frankly the hostility and copium when anyone suggests that Proxmox is lacking in someway compared to VMware is downright pathetic. It actively hurts the the perception of the Proxmox ecosystem. Proxmox is a decent product, my experience so far is that is not in the same league as vSphere and historically it was not cheaper over the long term. All that said the backup is better. Some of the short comings are not in the product itself, but like the one I have highlighted here. Instead of the hostility it would be far more grownup to just accept there is a short coming in the product offering.
 
You have an active subscription, did you ask the official support?
 
Hi,

Like other community members said, why don't you ask support directly instead of asking the community ?

It's kind of nonsense asking the community about subscriptions.

Best regards,
 
  • Like
Reactions: Johannes S and UdoB
Frankly the hostility and copium when anyone suggests that Proxmox is lacking in someway compared to VMware is downright pathetic.
Can't see were I've been hostile in any way. I've been trying to propose you methods and alternatives that you didn't like and insist on doing things "the VMWware way". That's simply not how PVE works. PVE it's not a 1:1 replacement, but an alternative with it's pro's and con's. Accepting it's downsides is also part of the learning curve.

In practice, after 9+ years managing 200+ clusters, migrations and upgrades I can assure you I've never missed the feature you describe. Basically the publication rate on the Enterprise repo is low enough to make any of the proposed methods fully viable if you ever need them, not to mention the possibility to move the subscription back to the old servers if neeed.

Anyway, think our point of view is clear enough and the feature you require can only be satisfied by Proxmox itself, please ask them on the official support.
 
The idea that you would be hand picking packages from the no subscription repo to match the enterprise repo is an utterly ridiculous suggestion
I dont see where anyone suggested that. you can either run your cluster using the subscription repo (slower, stable) or the no-sub repo (quicker, less, umm, stable.) in practice, the nosub repo is stable enough for production, certainly in mine.

It is clear that to migrate to new hardware you are going to need additional subscriptions
I think you're using the word clear in a way I'm unfamiliar with. subscriptions are not hardware specific.

if you want to remain with access to the enterprise repositories for updates during the migration period.
so what? you migrate once in a lifetime. reach out to support and tell then you must have the same repos on the destination, I'm sure they can accomodate.

Frankly the hostility and copium when anyone suggests that Proxmox is lacking in someway compared to VMware is downright pathetic.
... that face you see is the mirror. You are the one saying "this is the way it has to be done, you are all wrong." Just because what you want requires REACHING OUT to support doesnt mean some deficiency in the product, the offering, or the community.
That's simply not how PVE works. PVE it's not a 1:1 replacement, but an alternative with it's pro's and con's.
This. I can wax poetic in all the way I'm dissatisfied with VSphere. so what?
 
  • Like
Reactions: Johannes S
I dont see where anyone suggested that. you can either run your cluster using the subscription repo (slower, stable) or the no-sub repo (quicker, less, umm, stable.) in practice, the nosub repo is stable enough for production, certainly in mine.

I think you're using the word clear in a way I'm unfamiliar with. subscriptions are not hardware specific.

You must be being deliberately obtuse. There was a suggestion that one could hand pick the updates from the no-sub repo to match what is installed from the subscription repo.

There is no documented approach to migrate to new hardware during a hardware refresh cycle while staying with the supported enterprise repo as this by definition requires both old and new clusters to be running the same software for a short overlap period. It is not exactly a radical request, it is simply best practice of which there is far too little practiced in IT. It should be such a common occurrence that a reasonable person would expect it to be documented process.

so what? you migrate once in a lifetime. reach out to support and tell then you must have the same repos on the destination, I'm sure they can accomodate.

You must have a very short lifetime. You are migrating to new hardware every hardware refresh, that is going to be every 5-7 years these days. Our new hardware has seven years maintenance so six and a bit years from now we will be migrating to new hardware.

... that face you see is the mirror. You are the one saying "this is the way it has to be done, you are all wrong." Just because what you want requires REACHING OUT to support doesnt mean some deficiency in the product, the offering, or the community.

Er, yes there is in this case only one way of migrating to new hardware while remaining compliant with various frameworks (CyberEssentials, ISO27001 etc.) and anyone suggesting otherwise is simply incorrect. Telling me that I am wrong is a hostile response.
 
In practice, after 9+ years managing 200+ clusters, migrations and upgrades I can assure you I've never missed the feature you describe. Basically the publication rate on the Enterprise repo is low enough to make any of the proposed methods fully viable if you ever need them, not to mention the possibility to move the subscription back to the old servers if neeed.

I am seeing updates, at least weekly. CyberEssentials for example requires all security updates to be installed within a 10 day time frame. I don't have an option not to follow CyberEssentials. I simply don't believe that you installed, did all the acceptance testing and then migrated all the VM's in a 10 day window and remained compliant with other frameworks like ISO27001.

So what you are telling me is that you didn't follow best practice during your migrations. That doesn't surprise me in the slightest mind you, most IT does not.

I am simply staggered that there is not a documented method to follow for best practice when migrating to new hardware during a refresh cycle.