Inventory Debian version, architecture, packages, third-party repositories, custom kernels, boot mode, storage and critical services. Confirm control-panel and application support for the target. Take a recoverable full backup plus application-consistent database copies, and test access to a rescue console.

1. Read the target release notes, especially known issues and upgrade limitations. If the machine is more than one supported release behind, plan the documented intermediate upgrades or migrate to a freshly built server instead.
2. Bring the source release to its current supported point-update state and resolve broken packages, unfinished transactions and unexplained holds. Record installed packages and important configuration outside the server.
3. Test the upgrade on a representative clone with isolated networking. Exercise application dependencies and identify configuration changes needed for the new PHP, database, TLS and system libraries.
4. Prepare disk space, including boot partitions, and review obsolete or third-party packages according to the release notes. Disable or update outside repositories deliberately; do not mix arbitrary Debian release suites.
5. Schedule the maintenance window and use a reliable console or persistent session. Update APT sources to the specific intended release according to its documented format, retaining a copy of the original files.
6. Perform the release-note upgrade stages in order, reviewing proposed removals and configuration prompts before accepting them. Preserve the transcript and avoid unattended blanket confirmation for unfamiliar changes.
7. Reboot only after the package and bootloader stages have completed successfully. Use the console to inspect boot, then validate networking and each critical service before reopening traffic.

Run these read-only commands on the server you intend to upgrade. They identify the installed operating system, running kernel and packages held back from normal package-manager changes. Collect this baseline before editing repositories or booking the maintenance window.

cat /etc/os-release
uname -r
apt-mark showhold

Read the result: Use VERSION_CODENAME and VERSION_ID from os-release to select the matching official release notes. The kernel version describes the kernel running now; it can differ from an installed kernel awaiting reboot. A held database or control-panel package needs investigation before a distribution upgrade.

Check the control panel and application vendors against the destination release. These commands do not establish that an in-place upgrade is supported. Keep the baseline with the backup and restore plan so the migration can be assessed against the actual original system.

An explicit release codename makes the intended upgrade boundary clearer. A moving suite name can begin pointing at a new major release later. Follow the release notes and your maintenance policy rather than allowing that change to happen unnoticed.

Confirm the running release and kernel, clean package state and intended repository suite. Test application login, data reads/writes, mail or scheduled jobs as applicable. Review removed packages and new defaults, then establish a new tested backup baseline.

If the upgrade stops, preserve the error and package state. Do not reboot a half-configured system merely to clear a package-manager message. Use the release-note recovery guidance or restore/migrate from the tested backup. Downgrading packages individually is not a general rollback strategy for a major OS upgrade.

• Diagnosing a Linux package repository signature failure
• Reading logs from the previous Linux boot
• Testing a Linux server restore before an emergency
• Planning bootloader recovery on a Linux server

• Debian: Release Notes
• Debian: Upgrading.en
• Debian: Errata