Separate the support layers
Kernel.org lists active longterm branches and projected maintenance dates, while a distribution may support its packaged kernel longer through backported fixes. Hardware vendors separately qualify drivers, firmware and storage adapters, and application vendors publish supported operating systems and libraries.
An old-looking kernel is not automatically vulnerable, and a new kernel does not guarantee support for the complete system.
Maintain a fleet matrix
For each node class, record distribution and channel, kernel package, critical modules, firmware, Secure Boot, backup, monitoring and security agents. Add every supplier's end-of-support date and the owner of the transition decision.
Automated inventory is more useful than a spreadsheet updated before an audit. It should show both version and deviation from the approved base image.
Verify backports, not just CVE versions
Distributions frequently move a fix into an older branch without changing its main version number. Check the advisory and package build rather than comparing only with upstream. For third-party modules, confirm that a kernel update does not break boot, networking, storage or an endpoint agent.
The test environment should reproduce drivers and workload, not merely boot a clean virtual machine.
Plan the transition as a service change
Choose a supported target, validate applications and hardware, and prepare a fallback boot entry and tested rollback. Deploy in waves beginning with low-risk nodes, measuring errors, performance and recovery.
LTS does not remove the need for regular updates. It provides a predictable base, while package delivery, testing and reboot remain operational responsibilities.