Most of the OS migrations on this site are between RHEL rebuilds, where binary compatibility makes the move nearly mechanical. SUSE Linux Enterprise to Rocky is different, and it is important to be honest about that. SUSE and the RHEL family are separate distribution lineages: different package format conventions, different package manager (zypper vs dnf), different default tooling (AutoYaST vs kickstart), and different config layouts. There is no in-place converter and there should not be one. This is a reprovision-and-rebuild project driven by the SUSE per-socket subscription and add-on module costs, so scope it accordingly.
Why teams make the jump
The driver is cost and standardisation: SUSE’s per-socket subscriptions, separately-billed modules, and support-tier gating add up, and many shops want to consolidate on a single RHEL-family standard (Rocky or Alma) they already run elsewhere. The trade is real effort, you are changing distributions, not swapping a rebuild.
Standardisation is often the quieter but stronger argument. Running SUSE alongside a RHEL-family estate doubles the surface you have to patch, monitor, and staff for: two package managers, two config-management dialects, two security models, two sets of vendor certifications to track. Consolidating onto Rocky removes that split and lets one set of Ansible roles, one repo strategy, and one team competency cover the fleet. Weigh the migration effort against the ongoing cost of keeping two Linux families in production, not just against the SUSE line item.
Treat it as a reprovision
Forget in-place conversion. The clean path is to build fresh Rocky hosts and migrate workloads onto them:
- Build Rocky from kickstart (or a golden image), sized to match the SUSE host.
- Translate the package set from zypper/SUSE package names to dnf/EL equivalents. Names differ, so this is a mapping exercise, not a copy.
- Re-author configuration management. SUSE specifics (AutoYaST profiles, YaST-managed config,
/etc/sysconfigdifferences, wicked vs NetworkManager) become their RHEL-family equivalents in Ansible or kickstart. - Migrate data and services per host, then validate.
- Cut over with the SUSE host on standby for rollback, and decommission once proven.
The specifics that bite
- Package manager and repos. zypper patterns and SUSE module repos have no direct dnf analogue, rebuild your repo and patch strategy on the EL side (EPEL, internal mirrors).
- Networking stack. SUSE has historically used wicked; Rocky uses NetworkManager. Re-create interface, bonding, and VLAN config rather than copying files.
- Service and config layout. Paths, defaults, and
/etc/sysconfigcontents differ between families; do not assume a SUSE config file drops into Rocky. - Third-party and vendor software. Anything certified specifically for SLES needs its RHEL-family build and a support check, inventory these before committing.
- AppArmor vs SELinux. SUSE leans on AppArmor; Rocky uses SELinux. Security profiles must be re-authored, not migrated.
Proving each workload before cutover
Because this is a rebuild rather than a converter run, validation is per workload rather than per package swap. For each migrated host, confirm before cutover:
- Package parity: every capability the SUSE host provided has a working dnf-installed equivalent on Rocky, checked by function rather than by matching package names.
- Networking: interfaces, bonding, VLANs, and routing behave identically under NetworkManager, tested rather than assumed from the copied intent.
- Security policy: the re-authored SELinux policy runs in enforcing mode without unexpected denials for the workload.
- Services and data: migrated services start under systemd, and migrated data (databases, file shares) is complete and consistent.
- Integrations and agents: monitoring, backup, and security agents re-check-in, and upstream and downstream integrations still resolve to the new host.
- Vendor software: anything previously certified for SLES is running on its supported RHEL-family build, with support confirmed.
The safety net a rebuild gives you
The reprovision model gives you the cleanest rollback of any migration on this site: the SUSE host never changes. You build Rocky alongside it, validate, and only shift traffic once the replacement is proven. If anything fails after cutover, you re-point back to the still-running SUSE box and investigate without time pressure. Keep the SUSE host powered and drained through hypercare, then decommission and release its per-socket subscription only once you are confident. Because nothing was converted in place, there is no snapshot-restore dance, just a traffic switch.
Where SUSE may still be the right call
Not every host should move. If you run SAP on SLES (SUSE has deep SAP certification and tooling) or depend on SUSE-specific features, the subscription may be the better total-cost answer for those hosts. Move the general-purpose estate to Rocky and keep SUSE where its certifications genuinely earn their cost.
The short version
SUSE to Rocky is the one OS migration here that is a real distribution change, not a rebuild swap, so plan it as reprovision-and-rebuild rather than an in-place convert. Map packages from zypper to dnf, re-author networking (wicked to NetworkManager) and security (AppArmor to SELinux), and migrate workloads host by host with the SUSE box on standby. Keep SLES where SAP or specific certifications justify it. Model the removed per-socket subscription and module costs against the rebuild effort in the calculator above.