How to Upgrade Debian 12 to Debian 13 on a Production Server

Answer first: yes, it's time

Two facts decide the timing. First, Debian 12 "bookworm" left regular security support on 10 June 2026 — it's now maintained by the LTS team (until June 2028), which covers most packages but is a narrower guarantee than the security team's full support. Second, Debian 13 "trixie" is nearly a year old and five point releases deep (13.5 at the time of writing) — the early-adopter phase is long over.

The upgrade itself is classic Debian: unglamorous and reliable. The short version:

1. Bring bookworm fully up to date, clean out holds and third-party repos.
2. Point APT sources at trixie.
3. apt update → apt upgrade --without-new-pkgs → apt full-upgrade → reboot.

On a production server the work is in the preparation, not the commands — especially for a machine you only reach over SSH. Commands and addresses in this guide are illustrative; substitute your own values, and read the official release notes alongside — they remain the authoritative source, and this guide follows their procedure.

What you get: Debian 13 in one table

Support runway is the other half of the picture: trixie gets full security support to roughly August 2028 and LTS through June 2030 — four more years of patches than the box you're upgrading.

Pre-flight checklist

Do all of this before touching the sources. Half an hour here is what makes the upgrade boring.

1. Get current, and audit package state

Skip-release upgrades are unsupported — you must be on the latest bookworm point release first:

apt update && apt full-upgrade    # finish updating Debian 12
dpkg --audit                      # must be silent (no broken packages)
apt-mark showhold                 # holds will sabotage the upgrade — clear them

Then remove what doesn't belong: third-party repositories (disable them; re-add trixie-compatible versions afterwards), anything from bookworm-backports (no upgrade path), and packages you no longer use — every package you remove now is one that can't conflict later.

2. Back up the things that make restore possible

A real backup of your data, plus the cheap system-state copies the release notes call for:

tar czf /root/pre-upgrade-etc.tar.gz /etc
cp -a /var/lib/dpkg /root/pre-upgrade-dpkg
dpkg --get-selections '*' > /root/pre-upgrade-selections.txt

Be honest with yourself about rollback: there is no supported downgrade path. If the upgrade goes irrecoverably wrong, the way back is your backup (or reprovision-and-restore, which on a fast-provisioning host is often quicker). Decide now what your recovery plan is, not at 2 a.m. mid-incident.

3. Remote-server specifics — the part that saves you

These three items are what separate "upgrading a server in the rack" from "upgrading a laptop", and the first one is the sharpest trap in this cycle:

• Pin your network interface names. The trixie release notes warn that some NICs (notably on the i40e driver, and some ACPI systems) change interface names under the new kernel. If your /etc/network/interfaces says eno1 and the new kernel calls it enp5s0, the machine boots with no network — on a remote box, that's a dead server. Pin the name to the MAC address before upgrading with a systemd .link file:

# /etc/systemd/network/10-persistent-eth0.link
[Match]
MACAddress=aa:bb:cc:dd:ee:ff

[Link]
Name=eth0

(Use your NIC's MAC from ip link; then reference that pinned name in your network config.)

• Run the upgrade inside tmux or screen. If your SSH connection drops mid-full-upgrade, a detached session keeps the upgrade alive instead of leaving dpkg half-run.
• Confirm out-of-band console access works — IPMI/KVM-over-IP. Test the login before you need it. It converts every worst case in this article from a reprovision into a ten-minute fix.

4. Check the sharp edges that apply to you

From the known-issues list, the ones that bite servers:

• OpenSSH 10 removes DSA keys entirely. If any authorized key or host key is still DSA (it would have to be ancient), replace it with Ed25519 before upgrading, or you're locked out at the first post-upgrade SSH attempt.
• Databases and mail: shut MariaDB down cleanly before upgrading (cross-version crash recovery fails); Dovecot's config format changed incompatibly; RabbitMQ has no direct upgrade path. If you run these, read their entries first and plan the service-level migration.
• Encrypted root? Ensure systemd-cryptsetup is installed before the reboot.
• Disk space: apt will tell you what full-upgrade needs on /; also confirm /boot has ~300 MB free — undersized boot partitions from old provisioning templates are a classic upgrade-stopper.

The upgrade

Step 1: point APT at trixie

Bookworm systems typically still use the classic one-line format. Edit /etc/apt/sources.list (and anything in /etc/apt/sources.list.d/) replacing bookworm with trixie — note the security suite's naming:

deb http://deb.debian.org/debian trixie main
deb http://deb.debian.org/debian trixie-updates main
deb http://security.debian.org/debian-security trixie-security main

(APT 3.0 prefers the new deb822 format, but converting is cleaner after the upgrade — one change at a time. apt modernize-sources will do it for you then.)

Step 2: the three commands

Inside your tmux session:

apt update
apt upgrade --without-new-pkgs    # minimal upgrade first — safer ordering
apt full-upgrade                  # the real event

The two-phase structure is deliberate and straight from the release notes: the minimal pass upgrades what it can without installing or removing anything new (packages "kept back" at this stage are normal), which reduces the amount of simultaneous change when full-upgrade then handles the kernel, ABI transitions, and removals. Expect a few conffile prompts — the safe default answer is to keep your version (N) and review the differences afterwards; full-upgrade will also propose removing obsolete packages, and it's worth actually reading that list before confirming.

On a typical server this downloads a few gigabytes and takes somewhere between fifteen minutes and an hour depending on package count and disk speed.

Step 3: reboot and verify

systemctl reboot

Then confirm the basics the moment it's back:

cat /etc/debian_version   # expect 13.x
uname -r                  # expect a 6.12 kernel
systemctl --failed        # what didn't come up?
ss -tlnp                  # are your services listening?

If it doesn't come back: this is the KVM console's moment. The two most likely culprits on a remote box are the interface rename (fixed by the .link pinning above — or fixable at the console) and boot-loader/initramfs issues, both diagnosable out-of-band.

Step 4: post-upgrade cleanup

apt autoremove --purge     # dependencies nothing needs anymore
apt purge '?obsolete'      # packages no longer in any repo
apt modernize-sources      # optional: convert sources to deb822, now that things are stable

Trixie changes to check after the upgrade

Three behavioural changes catch people who upgraded rather than fresh-installed:

• /tmp is now a RAM-backed tmpfs (up to 50% of RAM), activated on your first post-upgrade reboot, with automatic cleanup — files unused for 10 days in /tmp (30 in /var/tmp) are deleted. If an application writes large temporary files, either point it elsewhere or revert to disk-backed /tmp (systemctl mask tmp.mount and reboot). Note that upgraded systems get a compatibility tmpfiles.d snippet preserving old cleanup behaviour — check /etc/tmpfiles.d/tmp.conf to see which regime you're in.
• /etc/sysctl.conf is no longer read. Kernel tuning you kept there silently stops applying; move it into /etc/sysctl.d/*.conf files (the firewall/tuning settings from our hardening checklist live there anyway).
• Small tool removals: last/lastlog are gone (use lslogins, wtmpdb); isc-dhcp-client is deprecated. Plain ping now works unprivileged. Scripts that assumed the old tools need a touch-up.

Server network configuration is unchanged territory: trixie server installs still use ifupdown (/etc/network/interfaces) by default, so your existing config carries straight over — renaming risk aside.

Frequently asked questions

How long does the whole process take?

Budget a maintenance window of one to two hours for a straightforward server: the package download and installation is usually under an hour, one reboot, plus your verification time. The preparation (backups, audits, pinning) adds half an hour beforehand but doesn't need the window. What blows the budget is skipped preparation — a held package or full /boot discovered mid-upgrade turns a routine job into an afternoon.

Can I upgrade straight from Debian 11 to 13?

No — skip-release upgrades are explicitly unsupported. The path is 11 → 12 → 13, completing each hop (including the reboot) before starting the next. If you're two releases behind on a machine, honestly weigh reprovisioning on Debian 13 and restoring data against doing two sequential in-place upgrades; on a host with fast provisioning the fresh install often wins on both time and confidence.

Is it safe to do this over SSH?

Yes, with the three precautions from the checklist: run inside tmux/screen (so a dropped connection doesn't kill dpkg), pin interface names before upgrading (so the new kernel can't rename your NIC out from under the network config), and have out-of-band console access verified in advance. Thousands of remote Debian boxes are upgraded this way every release cycle; the horror stories are almost always one of those three precautions skipped.

Should I convert my APT sources to the new deb822 format?

Eventually, yes — it's the default for new installs, APT 3.0's tooling assumes it, and the one-line format is deprecated (though supported for years yet). But do it after the release upgrade, with apt modernize-sources, not during: bundling a config-format migration into the same change window as a distribution upgrade just makes any breakage harder to attribute.

Debian 14 is coming — should I wait for it?

No. "Forky" is expected sometime in 2027 with no dates announced, and waiting for it means running bookworm on narrowing LTS support for another year-plus. Upgrade to trixie now, enjoy full security support, and when forky has a point release or two of maturity you can make this same jump again — that cadence (upgrade roughly a year into each release) is the comfortable rhythm for production Debian.

Deploying on Serverside

Two things on our platform take the fear out of this procedure: KVM-over-IP console access on every Debian dedicated server — so an interface rename or boot hiccup is a console session, not a support ticket — and sub-minute provisioning on ASN 55285, which makes the reprovision-and-restore fallback a genuinely fast plan B (and fresh Debian 13 installs the easy plan A for new machines).

More Debian and upgrade-adjacent reading: how to choose a Linux distribution, the first-hour hardening checklist to run on any freshly upgraded box, and sensible default firewall rules.