Upgrading an operating system in place, without losing the machine

Why this matters

An in-place upgrade is the highest-stakes routine job in this objective. It touches every part of a working machine at once, it runs unattended for an hour, and when it goes wrong it goes wrong on a machine somebody was relying on.

It is also the job where preparation and execution are most unequal. The upgrade itself is a progress bar. Everything that determines whether it succeeds happens before it starts — compatibility, space, backup, and knowing which route is even available. This lesson is the domain's capstone because it uses almost everything in it: editions, boot modes, partitioning, file systems, drivers, accounts and update behaviour all show up in a single hour's work.

The lesson

Checking compatibility properly: hardware, firmware, storage and applications

Compatibility is checked in four places, and the vendor's own tool covers only the first.

Hardware. Processor generation, memory, and the requirements that are enforced rather than advisory. Modern Windows enforces a processor list and a TPM requirement, and a machine that fails those will not be offered the upgrade at all — which is a very different symptom from one that fails during it.

Firmware. Two settings decide eligibility on many machines: whether the firmware is in UEFI mode rather than legacy, and whether the TPM and secure boot are enabled. Machines frequently have the hardware and have it switched off. Checking this first turns "this machine cannot be upgraded" into a two-minute firmware change — though note that moving a legacy/MBR installation to UEFI/GPT needs a conversion, and that is a separate operation with its own risks.

Storage. A feature upgrade needs substantial free space, commonly 20 GB or more, plus room for the rollback copy. This is the most common cause of failure and the easiest to check.

Applications. The category the tools are worst at. Security software, backup agents, VPN clients, disk encryption and anything with a driver are the usual blockers. Line-of-business software may be supported only on the old version, and the honest answer is sometimes that the machine should not be upgraded until the vendor catches up.

The order to work in: firmware and hardware first, because they decide whether this is possible at all; then storage; then applications, which decide whether it is wise.

Backing up before an upgrade, which is the step that is always skipped

This is the step everyone knows about and most people skip, and the reason they skip it is that they have done twenty upgrades that went fine.

What the backup has to cover:

• User data, including the parts that are not in the obvious folders: browser profiles and bookmarks, mail stores for clients that keep them locally, application settings, and anything on the desktop.
• The licence position. Which software will need reactivating, and where the keys are. An upgrade that succeeds and leaves the user unable to reactivate their design software has still cost them a week.
• The encryption recovery key, if the machine is encrypted. An upgrade can trigger a recovery prompt on the next boot, and without the key that is the end of the machine.
• Network and application configuration that is not stored with the data — mapped drives, printers, VPN profiles, certificates.

How to do it well in the time available: a full image if you have somewhere to put one, because it restores the machine rather than the files. Otherwise a file-level copy to an external disk, verified by opening two files from the copy rather than by trusting the progress bar.

The sentence worth saying out loud to a user before you start: "If this goes badly, what would you need back?" It takes thirty seconds, it produces a better list than any checklist, and it moves the decision about acceptable risk to the person whose data it is.

The upgrade paths that exist and the ones that require a clean install

Not every route between versions exists, and knowing which do saves attempting the impossible.

Available in place:

• Edition upgrades within the same version — Home to Pro is a licence change and a short reconfiguration, with everything kept.
• Version upgrades within the same architecture and the same language, where the source version is recent enough to be supported. Very old versions must hop through an intermediate one or be clean-installed.

Requires a clean install:

• 32-bit to 64-bit. There is no in-place path, ever.
• Changing the installation language of some editions.
• Downgrading an edition — Pro to Home is not an in-place operation.
• Moving between firmware modes with a partition scheme change, unless the conversion is done separately first.
• Windows to another operating system, obviously, and macOS and Linux have their own equivalents of all of this.

One more that catches people: an upgrade requires the same installation type. An installation that was heavily customised, or one whose component store is damaged, may refuse; the repair install described earlier in this domain is often what unblocks it.

The professional habit is to establish the route before promising a timescale. "I will upgrade it this afternoon" and "this needs a rebuild, which is a day and you will need your licence keys" are very different conversations, and having the second one late is much worse than having it early.

What an in-place upgrade keeps, what it resets, and what it quietly removes

The three categories are worth separating because users notice all three and attribute them all to the same thing.

Kept: user files, installed applications, most application settings, accounts and their profiles, network configuration, drive mappings, and activation.

Reset: some privacy and default-application choices, occasionally personalisation, and any setting the new version has moved or redefined. Default browser and default file associations are the most-noticed of these.

Quietly removed: this is the category that generates the complaints. Feature updates remove features that have been retired, and they do it without a prominent warning. Historically that has included applications that shipped with Windows, optional features that were deprecated, and — the one that bites technicians — older components that a line-of-business application depended on.

There is also a leftover: the previous installation is kept in C:\Windows.old, which is what makes rollback possible and which consumes substantial disk space. It is deleted automatically after the rollback window, and it can be removed early through disk cleanup — at the cost of giving up the rollback. A machine that is suddenly short of space after an upgrade is usually holding this, and deleting it is a legitimate answer as long as the user knows what they are giving up.

The support habit: after an upgrade, check the default browser, the default applications for the file types the user cares about, the printers, and that any specialist software still starts. Five minutes there prevents most of the follow-up tickets.

Rolling back within the window, and what happens when the window closes

The rollback window is roughly ten days, and what it offers is a return to exactly the previous installation — applications, settings and files as they were, minus anything created since.

How it is used: from the recovery options, "Go back to the previous version of Windows". It requires C:\Windows.old to still exist, which means it requires that nobody has run disk cleanup on it.

What closes the window:

• The ten days elapsing, after which the previous installation is deleted automatically.
• Disk cleanup removing previous installations.
• A disk that filled up and triggered automatic cleanup.

When the window closes, the only route back is a clean installation of the old version and a restore from backup — which is precisely why the backup section of this lesson is not optional. An upgrade with no backup and a closed rollback window is an irreversible change to somebody's machine.

The practical consequence for how you schedule work: do not upgrade a machine on the Friday before somebody's leave. The problems that justify a rollback appear when the user tries to do their actual job, which may be several days later, and the window needs to still be open when they do.

And the operational habit that the last domain of this course will name properly: write down the version you upgraded from, the date, and where the backup is. A rollback decision made a week later by a different technician depends entirely on that note existing.