Do-release-upgrade is Ubuntu’s guided tool for moving a system from one supported release to another. It checks the target release, updates package sources, handles prompts, and coordinates the restart of services and the reboot needed to complete the upgrade safely.
What do-release-upgrade actually does during a release transition
do-release-upgrade is not a generic package update command. It is Ubuntu’s guided release migration path, so its core job is to move the system from one supported Ubuntu release to the next while preserving a coherent operating state. That means it evaluates whether the target release is valid, adjusts package sources, and orchestrates the changes needed for the new release to take over cleanly.
The practical value of the tool is that it treats the upgrade as a controlled lifecycle event rather than a simple software install. For administrators, that matters because release boundaries can change package availability, service behaviour, kernel versions, and repository metadata in ways that a normal update flow does not handle on its own.
How the upgrade process is coordinated
The tool works by sequencing the upgrade steps that would otherwise be easy to miss or run in the wrong order. It updates release references, prompts for decisions where local configuration may be affected, and manages the transition so that dependencies can be resolved against the target release rather than the current one. In practice, this reduces the chance of mixing packages from multiple releases, which is one of the fastest ways to create an unstable system.
That coordination is also why the reboot is part of the process. A release upgrade often includes kernel, library, and service changes that only become fully active after restart. The upgrade is therefore not complete when the package download finishes, it is complete when the new runtime state is in effect.
Where do-release-upgrade fits in Ubuntu maintenance
For operations teams, do-release-upgrade sits between routine patching and full reinstallation. It is the path you use when the system is still worth preserving, but its release train has moved on. Because it is release-aware, it helps maintain a supported posture without forcing a manual rebuild.
That also means it should be treated as a maintenance milestone, not an incidental background task. A release transition can expose package conflicts, deprecated configuration, or service restart dependencies that do not appear during ordinary updates. The tool reduces manual effort, but it does not eliminate the need to understand what the target release changes.
What success and failure look like in a release upgrade
A successful upgrade leaves the system aligned to the new Ubuntu release, with repositories, packages, and services consistent with that target. A failed or interrupted upgrade can leave the machine in a mixed state, which is where administrative problems usually begin: stale package sources, partially upgraded services, or reboot issues that delay recovery.
For that reason, the most important practical signal is not whether the command starts, but whether the environment is ready for the transition and can finish it cleanly. Release upgrades are sensitive to held packages, local modifications, and changes in service behaviour, so operational certainty comes from controlled execution rather than automation alone.
Risk and Threat Considerations
Release upgrades can create exposure if package sources are changed incorrectly, if the process is interrupted, or if the system is left in a partially upgraded state. The main risk is not usually an external attack on the command itself, but operational drift that weakens integrity, availability, or supportability.
Failure mechanism: A mismatched repository, unresolved dependency, or interrupted restart sequence can leave the system with inconsistent packages or services, which makes later maintenance and troubleshooting harder and can extend outage time.
Impact: The system may lose stability, fail to boot cleanly, or run with a blend of old and new components, increasing the chance of service disruption and complicating rollback or recovery.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | CM-2 — Baseline Configuration | Release upgrades change system baselines and package state. |
| CM-3 — Configuration Change Control | The tool performs a controlled system-wide change that needs approval and sequencing. | |
| SI-2 — Flaw Remediation | Ubuntu release migration is a remediation and update pathway for supported systems. | |
| Recommendation — Update the authorized baseline before and after the release transition. Control the release upgrade through approved change management and rollback planning. Use the upgrade window to remediate known issues and keep the host on a supported release. | ||
| CIS Controls v8 | CIS-4 — Secure Configuration of Enterprise Assets and Software | The upgrade redefines the host configuration and package set. |
| CIS-7 — Continuous Vulnerability Management | Moving to a supported release is a vulnerability-reduction activity. | |
| Recommendation — Validate hardened configuration after the release upgrade completes. Prioritize release upgrades for systems that have fallen behind support windows. | ||
Practitioner Guidance
Why practitioners should care: do-release-upgrade is the right tool when the goal is to move cleanly to the next Ubuntu release, but it assumes the operator is prepared for a real maintenance event. Treat it as a controlled change window, not a background updater.
What to watch for: pay attention to held packages, local repository overrides, and service restart prompts, because those are the points where a routine upgrade turns into a manual decision. If the system has critical workloads, verify recovery and reboot tolerance before starting the upgrade.
Related resources from NHI Mgmt Group
- Who is accountable when insecure .NET release practices reintroduce risk after an upgrade?
- How should teams plan an OAuth or OIDC provider upgrade when the release includes schema changes, token model changes, and directory sync changes?
- How should enterprises manage macOS upgrade rollouts when a new release drops support for older hardware?
- How should security teams plan a PHP runtime upgrade before a major password manager version release?
