Support Lifecycle

A support lifecycle is a vendor’s schedule for a product version: what assistance and updates it provides, for which components, and for how long. A service may continue running after coverage ends. Track the policy and installed components instead of inferring support from successful operation.

Read the coverage behind the phase name

Red Hat’s detailed RHEL 8, 9, and 10 policy places Full Support and Maintenance Support within a ten-year window, followed by an Extended Life Phase. The phase names describe different commitments; they are not security ratings.

In Extended Life, the base subscription retains limited technical assistance and access to earlier content without new fixes. That is a narrower service, rather than no support of any kind. It does not meet a requirement for ongoing security fixes by itself.

Paid extensions can supply eligible fixes under separate terms. Check the precise minor release and package or Application Stream lifecycle as well as the extension purchased and enabled. Some components expire before the OS major version; a valid subscription is not proof that every installed component is covered.

The numbers differ by product and by what you buy

Ubuntu releases every six months. Its LTS versions arrive every two years with five years of standard security maintenance for Main; interim releases have nine months of updates. Ubuntu Pro provides additional coverage, with duration and package scope determined by the selected services and add-ons.

Use those schedules to plan transitions and coverage:

• Support starts at release. Nine months of interim updates does not mean a new nine-month window starts when you install or upgrade. Plan against each version’s end date, the six-month release cadence, and supported upgrade paths. LTS commonly fits long-lived estates; frequent rebuilds can make interim versions practical for shorter-lived environments.
• Coverage can require a contract decision. Compare eligible extensions with the cost, timing, and risk of migration before the current window closes. Review the actual terms rather than assuming that every extension has the same duration or price.
• Component scope matters. Packages outside covered repositories or streams need their own maintenance source or replacement plan. Check that scope in the policy and installed inventory.

Making the date a managed item

Vendor tools can surface coverage and subscription status; Ubuntu Pro provides such MOTD messages. Those signals still need to reach an owner who can act. A running service and an unread warning are both poor substitutes for a maintained inventory.

For each installed version, record coverage and phase dates, relevant component exceptions, the transition owner, and the lead time for testing and migration. Where coverage has ended, document the chosen upgrade, eligible extension, or authorized temporary risk acceptance, subject to mandatory requirements.

Set the decision deadline before support ends by allowing for testing, transition, and contingency time. A twice-yearly review may fit a stable long-support estate, but short support windows or long migrations require earlier checks. Review new installations, policy changes, and lost coverage as they occur.

A dependency’s age does not establish its vulnerability or whether anyone has reviewed it. A team may retain an older version after assessment, and its distribution may backport fixes. Check the installed revision, relevant advisories and code paths, and the latest assessment date, owner, and decision. Keep application dependencies visible alongside the platform lifecycle. Prioritizing updates uses the threat and vulnerability distinction together with the exposure in this deployment.

The costs a lifecycle creates — upgrade projects, extension purchases, testing — belong in total cost of ownership, and they are a legitimate argument for moving a workload to something where the provider owns the operating system. How the lifecycle interacts with images, patching, and standardization is worked through in The Server That Outlived Its Support Window.

References

• Red Hat, Red Hat Enterprise Linux Life Cycle
• Canonical, Ubuntu release cycle
• Canonical — Ubuntu releases
• Red Hat — Backporting Security Fixes
• Canonical — Ubuntu Pro-related MOTD messages