OS subscriptions are recurring per-vCPU or per-socket costs, and the CentOS Stream shift pushed many shops to rebuild their Linux strategy. RHEL-compatible rebuilds (Rocky Linux, AlmaLinux) and Ubuntu/Debian remove or reduce the subscription while keeping workloads largely unchanged.
Not every move in this category carries the same risk. Migrations between RHEL rebuilds are nearly mechanical because binary compatibility means packages, versions, and SELinux policy all carry over. Moving off an end-of-life CentOS is more about urgency than cost, since you are leaving an unpatched OS. Changing distribution families, SUSE to the RHEL family, or Windows to Linux, is a genuine rebuild or re-platform, not a swap. Sort your intended move into the right category before you estimate effort, because the runbooks and timelines differ sharply.
Two paths: convert or reprovision
- In-place conversion, RHEL→Rocky/Alma is famously low-friction via
migrate2rocky/almalinux-deploy, swapping the distro in place. Fast, but snapshot first. - Reprovision, build a golden image / Ansible roles for the target and redeploy. Cleaner long-term, and the right call when changing distro families (e.g. RHEL→Ubuntu) or modernizing config management.
A useful rule of thumb: convert well-managed, stateless hosts in place, and reprovision the long-lived, hand-tuned ones. Reprovisioning also forces you to express a host’s configuration in code, which pays off well beyond the migration itself. Cross-major moves (for example an EL7 host to an EL9 target) are reprovision territory, since the EL family does not support in-place major-version jumps the way Ubuntu does, with AlmaLinux’s ELevate being the notable exception via leapp.
What to check
Inventory packages, services, and configuration; map application/runtime certifications (some ISV support matrices are distro-specific) and kernel/driver dependencies. Map package equivalents across dnf/apt/zypper, and confirm repo access. Windows→Linux re-platforming is a bigger lift, only supported apps move cleanly.
Counting the whole subscription, not just cores
On VMs, RHEL/SUSE/Windows are effectively counted by vCPU (or per-VM subscription); Windows Datacenter licenses host cores but allows unlimited VMs. The open rebuilds are free (support optional via CIQ, Canonical, etc.). Keep the model qualitative and treat any figures as illustrative rather than vendor quotes: the point is the shape of the saving, not a precise number.
The subtlety with Windows is that per-core licensing is only part of the bill. Client access licenses (CALs) and Software Assurance stack on top, so a Windows-to-Linux comparison that counts only cores understates the removed cost. Count CALs and any add-on entitlements (HA, layered products) on the source side so the comparison reflects what you actually stop paying.
From snapshot to smoke tests
Snapshot → convert or reprovision → reboot and verify the OS, services, and agents (backup/monitoring/security) → run application smoke and regression tests → re-register configuration management. Run a patch-and-reboot cycle test before declaring success. Rollback = restore the snapshot or redeploy the prior image.
Test on a real host, then release the entitlement
Convert a non-production clone first to surface package/driver/boot issues, then roll out in waves. Keep snapshots through hypercare. Pilot on a representative host (an app server with your real repo set and agents), not a bare box, so the issues you find are the ones you will hit in production.
For migrations that remove a subscription, remember that the saving is not real until you actually release the entitlement: de-register from the vendor (for example subscription-manager unregister for RHEL), remove the subscription agents, and reconcile the freed entitlements against your renewal count. Converting a fleet but forgetting de-registration on a subset is a common way to keep paying for OSes no live system is running.
Open a source→target page for the exact conversion commands and a per-vCPU TCO model.