Some links on this page are affiliate links: if you buy through them we may earn a commission, at no extra cost to you.
Rocky Linux supports routine updates within a major release, but it still does not officially support in-place upgrades from one major release to another. Moving from Rocky Linux 8 to 9 or Rocky Linux 9 to 10 means a fresh installation followed by migration of applications, configuration, and data. That is manageable for automated, replaceable infrastructure—but expensive and risky for unique, stateful servers.
Rocky Linux 10 makes the trade-off especially important because it also raises hardware requirements on supported x86 systems. Administrators must validate both their migration process and their hardware before treating Rocky 10 as a routine lifecycle upgrade.
The important distinction: updates versus upgrades
“Rocky Linux does not support upgrades” is too broad. Rocky supports normal package updates within the same major release. For example, a Rocky Linux 10 system moving from 10.1 to 10.2 uses the ordinary DNF update path:
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorssudo dnf -y upgradeThe problem is the transition between major releases:
#1 Best Overall
| Transition | Rocky Linux position |
|---|---|
| Rocky 10.1 → 10.2 | Supported as a same-major update |
| Rocky 9.7 → 9.8 | Supported as a same-major update |
| Rocky 8 → 9 | No officially supported in-place upgrade |
| Rocky 9 → 10 | No officially supported in-place upgrade |
| Fresh installation and migration | Rocky’s supported approach |
Rocky’s version policy says major-version upgrades are not supported. Its Rocky Linux 10 release documentation specifically says that upgrades from Rocky Linux 8.x or 9.x are unsupported and instructs users to perform a fresh installation.
That means there is no Rocky-supported equivalent of “run one command, reboot, and continue” for Rocky 9 to Rocky 10. A major-version move is a migration project.
What Rocky officially recommends
The supported conceptual path is:
- Inventory the existing server and its dependencies.
- Back up data, configuration, certificates, keys, and application state.
- Test restoration before changing production.
- Validate the target hardware and architecture.
- Install the desired Rocky Linux major release.
- Apply updates and security settings.
- Reinstall applications from repositories supported on the target release.
- Restore data and selectively recreate configuration.
- Test services, permissions, networking, storage, SELinux, and monitoring.
- Switch traffic, DNS, load-balancer membership, or service ownership.
- Keep the old system available until rollback is no longer required.
Rocky’s supported-version migration guide describes installing the desired version and transferring data and configuration rather than upgrading the existing operating-system installation in place.
This does not necessarily mean starting from nothing. A fresh installation can be highly repeatable when a team uses Kickstart, Ansible, Packer, Terraform, containers, configuration management, database replication, or immutable images. The burden is greatest on servers that have accumulated years of undocumented manual changes.
Why the policy matters in real environments
It turns a lifecycle event into a migration project
A vendor-supported in-place upgrade may still be complicated, but it normally comes with pre-upgrade checks, documented inhibitors, compatibility guidance, tested package transitions, and a support channel when the process fails. Rocky’s community project does not provide that same official major-release lifecycle.
The difference is not that Rocky packages stop working or that a major upgrade is technically impossible. The difference is supportability: if an unofficial conversion leaves a production system unbootable or with broken services, the Rocky project does not provide an official recovery promise for that upgrade.
It creates capacity and downtime requirements
A clean installation usually works best with a second virtual machine, physical host, cloud instance, spare disk, or parallel environment. Without one, the administrator may need to accept downtime while reinstalling and restoring the only server.
High-availability deployments can replace nodes one at a time. A single-server database, file server, control panel, or business application cannot assume the same flexibility. In those environments, the migration may require replication, a longer maintenance window, temporary hosting, or a carefully rehearsed disk-level recovery plan.
It reveals configuration drift
Long-lived servers commonly contain changes that are absent from formal documentation:
- Manually installed RPMs and external repositories
- Custom systemd units, overrides, timers, and cron jobs
- Hand-edited web, database, SSH, and service configuration
- Firewall rules and SELinux policy modules
- Kernel modules and proprietary drivers
- Custom Python, PHP, or Perl runtimes
- Storage mounts, RAID, multipath, and encryption settings
- TLS certificates, private keys, ACLs, and extended attributes
- Application data stored outside the expected service directory
A reinstall forces the team to find and reproduce these details. That is beneficial for long-term operational discipline, but it can be costly when the original server was treated as a one-off appliance.
Rocky Linux 10 changes the hardware question
Rocky Linux 10 requires x86-64-v3 on supported x86 systems. Some older processors, including certain Intel Atom families, do not provide the required instruction set and are not supported for Rocky Linux 10. See the Rocky Linux 10 release notes for the project’s hardware details.
Quick wins for a faster PC:
Repair Windows errors before they cause bigger problemsFix Now →Fix the driver behind crashes, sound loss and screen glitchesFind Drivers →Clear out junk files and repair common Windows errorsFree Scan →Therefore, a Rocky 9 server is not automatically a Rocky 10 server. Hardware validation must happen before the migration plan is approved. A failed architecture check can turn an operating-system migration into a hardware refresh.
Third-party software can be the real blocker
Every external repository and vendor component must be assessed for the target release. Check for:
- Repository availability and signing keys
- Compatible libraries, ABIs, and module streams
- Kernel-module support
- NVIDIA, storage, virtualization, monitoring, backup, and security agents
- Database version and data-format migration requirements
- Application-vendor certification for the target Rocky release
A clean installation makes these dependencies visible; it does not make them disappear. Blindly enabling old repositories or copying every installed package to the new host is a common way to create an unsupported system.
Is Rocky Linux 8 to 9 or 9 to 10 possible?
It may be technically possible in particular configurations, but Rocky Linux does not offer an officially supported in-place path for either transition.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Rocky’s earlier release documentation described major upgrades as technically possible while recommending a fresh installation. The current policy is more direct: major-version upgrades are not supported by Rocky’s Release Engineering or most of the community. The Rocky 9 documentation and Rocky 9.5 documentation do not provide an official Rocky 8-to-9 upgrade path. Rocky 10 documentation likewise excludes upgrades from Rocky 8.x and 9.x.
That distinction matters for production decisions. “It worked in a lab” is not the same as “the operating-system vendor supports this lifecycle.” Organizations must account for recovery, escalation, compliance, and application-vendor support—not just whether a conversion can complete.
What about ELevate?
ELevate is an AlmaLinux project built around the Leapp ecosystem. It has supported some migration scenarios involving Enterprise Linux derivatives, and it may be useful for particular source and target combinations.
It should not be described as Rocky Linux’s official upgrade tool. Rocky’s own policy says ELevate may help in some cases but has not been formally tested by Rocky Linux and is not covered by official Rocky assistance. Its support matrix must be checked for the exact operating-system versions, packages, storage layout, encryption, kernel modules, and repositories involved.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →If an organization chooses to evaluate ELevate, it should first use a clone or staging system, create and test complete backups, verify console and recovery access, and rehearse a rollback. A successful test on one server does not validate every machine in a fleet.
A practical Rocky major-release migration checklist
1. Inventory before touching production
These commands are inventory aids, not a Rocky-supported major-upgrade procedure:
cat /etc/rocky-release
uname -m
uname -r
sudo dnf history
sudo dnf repolist --enabled
sudo systemctl list-unit-files --state=enabled
sudo systemctl list-timers --all
sudo ss -lntup
sudo lsblk -f
findmnt
getenforce
sudo semanage fcontext -l
sudo firewall-cmd --list-allCapture installed packages as a reference:
rpm -qa --qf '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}n' | sortCompare this list with packages available from enabled repositories. Do not automatically reinstall every package: some are release-specific, obsolete, locally built, or supplied by repositories that do not support the target version.
2. Back up application state, not just files
Review and preserve, as applicable:
/etc, selectively rather than by blindly overwriting the new system/var/libfor each stateful service/home,/root,/srv, and/opt- Logical database dumps and, where appropriate, physical database backups
/var/spool/cron, systemd units, and drop-in overrides/etc/NetworkManager/system-connections//etc/firewalld/and custom SELinux policy modules- TLS certificates, private keys, and certificate-renewal configuration
- Container images, volumes, manifests, and compose files
- Virtual-machine definitions and storage mappings
- Monitoring, alerting, backup-agent, and security-agent configuration
Test restoration to a separate system. A backup that has never been restored is an assumption, not a recovery plan.
Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchWindows Errors? Fix Them Before They Spread
Repair common Windows errors and clear accumulated junk for a smoother, more stable PC - no reinstall needed.Free scan · no reinstall3. Validate the target
Confirm CPU compatibility with Rocky Linux 10, storage capacity, firmware, RAID or SAN access, boot mode, network naming, hardware drivers, and vendor support. Check that databases, applications, agents, and external repositories support the target release.
Rank #4
4. Build and harden the replacement
Install Rocky Linux, update it, configure identity and time synchronization, apply firewall and SSH policy, enable SELinux, install supported applications, and reproduce storage and network configuration. Recreate settings deliberately; do not copy the old /etc directory wholesale.
5. Restore and test
Verify service versions, database schemas, ownerships, permissions, ACLs, capabilities, extended attributes, mounts, certificates, scheduled jobs, firewall rules, SELinux contexts, logs, monitoring, and backups. A service that starts successfully may still point to an empty or incorrect data directory.
6. Cut over with a rollback plan
Use DNS, a load balancer, a floating IP, replication promotion, or a controlled maintenance window as appropriate. Keep the old system powered off but recoverable until the new system has passed an agreed observation period. Do not decommission the old host immediately after the first successful login.
Is the lack of major upgrades a security problem?
Not directly. Rocky Linux can receive normal updates while a major release remains supported, and a fresh installation can be secured just as effectively as an in-place system.
The risk is operational and indirect. Teams may delay migration because the process is disruptive, leave systems on unsupported releases, or attempt an unofficial conversion under deadline pressure. Rocky’s version policy explains that superseded minor versions and end-of-life major releases are unsupported, with older content moved to the vault rather than receiving normal updates.
Rocky’s policy is therefore best understood as a lifecycle and supportability limitation—not proof that Rocky systems are inherently insecure.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Who is Rocky Linux a good fit for?
Rocky remains a reasonable choice when the infrastructure is designed for redeployment:
- Servers are created from images or automation.
- Applications are containerized or otherwise portable.
- Systems are disposable or easy to replace.
- Backups and restores are tested.
- Parallel capacity is available.
- The team uses Ansible, Terraform, Packer, Kickstart, or similar tooling.
- The organization accepts community-level support.
- Hardware and third-party software are validated before each major release.
Rocky is a weaker fit when servers are unique, manually maintained, difficult to replace, or subject to expensive downtime. It is also a poor match when the organization requires vendor accountability, formal escalation, certified applications, or a simple supported in-place major-upgrade workflow.
Best Value
How Rocky compares with alternatives
| Priority | Community Rocky Linux | Commercial or vendor-backed option |
|---|---|---|
| Software cost | No-cost download and community use | Subscription or support fee |
| Major-release migration | Fresh installation and migration | May include documented tooling and support, depending on product |
| Support | Documentation and community assistance | Vendor support, escalation, and possibly an SLA |
| Best deployment model | Automated and replaceable infrastructure | Long-lived or mission-critical systems needing accountability |
| Main trade-off | Lower licensing cost, more internal migration labor | Higher direct cost, potentially lower operational burden |
Red Hat Enterprise Linux
RHEL provides an official upgrade procedure for supported scenarios, including RHEL 8 to RHEL 9, along with a vendor support ecosystem. That does not make upgrades effortless: prerequisites, limitations, application compatibility, and rollback still matter. Its trade-off is subscription cost and entitlement management.
AlmaLinux and ELevate
AlmaLinux is another community Enterprise Linux distribution, and ELevate is directly relevant to teams evaluating migration tooling. The exact support matrix must be checked before selecting a source and target. ELevate should not be treated as proof that Rocky Linux itself supports the same operation.
Oracle Linux
Oracle Linux offers its own tooling and commercial support options. It may suit organizations already invested in Oracle software, Oracle Cloud, or Oracle support contracts. Migration utilities, supported source systems, and pricing should be verified for the exact environment.
Free tools Windows power users keep installed
One-click scans. No signup required.
Commercial Rocky support from CIQ
CIQ offers commercial Rocky-based products, including RLC Pro, with features such as long-term support, priority support, compliance-related capabilities, direct bug fixes, and commercial guarantees. Its documentation is available at docs.ciq.com/rlc.
Pricing information listed by CIQ on August 16, 2026 included RLC Pro self-support at $350 per node annually, standard support at $600, and premium support at $825. Hardened and AIOS variants were listed at higher rates. Prices, eligibility, and volume agreements can change, so buyers should confirm current terms directly with CIQ.
Commercial CIQ support does not automatically mean that the community Rocky project has adopted an official in-place major-upgrade path. The key purchasing questions are whether the subscription covers major-release migration, who performs it, what rollback assistance exists, which applications and hardware are covered, and whether support provides maintenance only or a tested transition procedure.
The bottom line for infrastructure teams
Rocky Linux’s missing major-version upgrade path is not fatal for modern infrastructure. If a server can be rebuilt from automation and its state can be restored or replicated, a fresh installation may be safer than an in-place upgrade.
Recommended Free Tools
It is a serious disadvantage for long-lived, stateful, manually configured systems. Those environments must budget for parallel capacity, migration labor, testing, downtime, hardware validation, and rollback. The software may be free, but the lifecycle work is not.
Choose Rocky when your team is prepared to own that migration model. Choose a vendor-backed platform when formal support, certified compatibility, and lifecycle accountability are worth paying for. Either way, make the decision before the next major release—not when an unsupported server is already past its maintenance window.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
