A major version upgrade: this is not an update, it is a migration

A major version upgrade is not a big update. An update replaces a part; a major upgrade replaces the family itself. On paper the distinction looks thin, but it decides how the work must be planned from the start.

Why it counts as a migration

Everything moves at once. The kernel, the tooling, the storage layer, sometimes the configuration format. These are not parts tested one by one, they are a whole that arrives together.

Everything built on top assumes the old one. Your virtual machines, your automation, your monitoring setup, all of them were built around the behaviour of the previous family.

The meaning of going back changes. In an ordinary update, going back means "put the package back to its earlier version". In a change of family, going back usually means "restore from backup". Same word, two very different jobs.

The plan is really a backup plan

The question to ask is not "what if the upgrade fails", because an upgrade that fails outright announces itself and you stop there. The real question is: what do I do if it half succeeds. If the upgrade looks complete but one component stayed on the old behaviour, do you have a point you can go back to.

If the answer is no, the first job is not the upgrade, it is the backup.

The order that survives

Read the official upgrade notes for your exact jump. They are version specific and they are the one true source; general recipes on the internet may belong to the previous jump.

Get everything on the current family fully up to date first. Changing family from a half-updated system means trying to solve two separate problems at the same time.

If the vendor has its own pre-upgrade check, run it and read the output rather than skimming past it.

Take the backup you would need, and make sure it has been tested. On upgrade day, an untested backup is not a backup, it is a wish.

And do the work while you have physical or out-of-band access. Do not change family remotely without a second way in.

The good news nobody expects

The new kernel family does not take the place of the old one, it is installed alongside it. The old kernel stays on the machine. After the reboot the new family becomes the default on its own; if you want to stay on the old family you have to say so explicitly.

This is the most reassuring part of a major upgrade: on the boot side, the way back is usually still there.

Do not rush afterwards

Do not delete the old family right after the upgrade. The cost of keeping it is disk space; the cost of removing it is your way back. Clean up after it has run for a few weeks and you have genuinely seen that everything is fine.

What Atlas does

Atlas does not mix a change of family in among ordinary updates, it shows it in its own category. Next to it, it states plainly what will happen: this update does not replace the current kernel, it is installed alongside it, and after the reboot the new family becomes the default.

It also has a cautious default: if it cannot reliably determine which families are present on the system, the update is not treated as ordinary, it is marked as a change of family. So in case of uncertainty it does not slip past quietly, it comes up in front of you. That choice was deliberate: the cost of mistaking a family change for an ordinary update is far higher than the cost of handling an ordinary update with extra care.