[4.4] Windows Backup for Organizations: The Second Migration

Replacing a Windows device has always been two migrations wearing one name. OneDrive owns the files. Windows Backup for Organizations finally owns the settings, and at 26H2 it becomes the default.


Replacing a Windows device has always been two migrations wearing one name. The files come across cleanly, because OneDrive owns them. Everything else, the display scaling, the paired headset, the Wi-Fi profiles, the language settings, the accumulated small decisions that make a machine feel like yours, died with the old hardware and got rebuilt by hand. Windows Backup for Organizations exists for that second migration, and with the next Windows release it stops being something you turn on and becomes something you would have to turn off.

This belongs in the provisioning phase because it completes the story Autopilot started. Provisioning has long delivered a correctly configured device; it has never delivered a familiar one. A quick note on names before anything else: Microsoft shipped this as Windows Backup for Organizations and has since begun renaming it Windows settings backup and restore. Both names refer to the same feature, and I will use the original here since it is the one practitioners know.

What it is, and what it deliberately is not

The scope is narrow on purpose: Windows settings and the list of installed Microsoft Store apps, backed up on a rolling schedule roughly every eight days, stored in the Exchange Online region your tenant maps to, and offered back to the same user during setup of a new or reset device. Settings means the real texture of a profile: display, sound, and notification preferences, Bluetooth pairings, Wi-Fi profiles, personalization, taskbar behaviors, language and accessibility choices, File Explorer preferences. The Store app list restores as pins that reinstall from the Store rather than as binaries carried across.

Just as important is what it excludes, because every exclusion is another system’s job and your migration design has to name all of them. Files are OneDrive’s job, through Known Folder Move; this feature backs up no user data at all, though a desktop background can ride across via OneDrive. Win32 and MSI applications are Intune’s job, redeployed by assignment after enrollment rather than restored. Edge favorites and passwords are Edge enterprise sync’s job. And a few things are currently nobody’s job, the pinned taskbar layout among them, which is worth saying out loud to whoever writes the user communications. A device swap in a well-run tenant is therefore three systems agreeing: OneDrive for data, Intune for applications, and this feature for the long tail of settings that used to be a morning of fiddling.

The asymmetries that shape the design

The requirements are not symmetric, and the asymmetries are the design. Backup is generous: Microsoft Entra joined or hybrid joined devices, Windows 10 or Windows 11 on current builds, the user signed in with their Entra identity. Restore is choosy: it surfaces during the out-of-box experience only on Windows 11, only on Entra joined devices, and only for the same user in the same tenant. Windows 10 can be a backup source but never a restore target, and that one-way door is the point. It is a migration ramp off the retired OS, aimed squarely at estates still carrying Windows 10 hardware toward replacement.

Windows 10 can be a backup source but never a restore target. The one-way door is the migration ramp.

Two refinements arrived this year. A first sign-in restore now offers the backup at the first interactive sign-in rather than only during the out-of-box flow, on current Windows 11 builds, and that path supports hybrid joined devices where the out-of-box restore does not. And a user who deliberately declined the restore is not nagged again, which is the correct behavior and also means a helpdesk cannot simply tell someone to reboot and try again. The other constants to plan around: restores stay inside the tenant, backups belong to the individual user, and the eight-day cadence means the freshest backup on swap day is the one you had the user trigger manually the afternoon before.


The default flips, and roaming moves house

Two platform decisions in 2026 changed this from an optional nicety into part of the baseline. First, starting with Windows 11 version 26H2, the backup side is enabled by default for eligible devices. Any policy you have explicitly set, enabled or disabled, continues to be honored, and the restore side remains off until an administrator turns it on, but the resting state of an unconfigured tenant flips from nothing-backed-up to settings-backed-up. Microsoft frames this as settings backup becoming a resilience baseline rather than an opt-in, and I think that framing is honest: the recovery half of endpoint management has always been the neglected half, and defaults are how neglect gets fixed. If your organization has reasons not to back up settings, the time to express that as explicit policy is before 26H2 reaches your rings, not after.

Second, Enterprise State Roaming, the decade-old Entra feature that synced a small set of settings across a user’s devices, has been folded into this feature. Its portal-based management ended in mid-2026, its old behavior survives on a one-year grace period, and its roaming capability now lives inside the Windows Backup policy surface, still gated by the licensing that always applied to it. If your tenant has ESR enabled and nobody remembers why, that is now a loose end with a timer on it: the roaming behavior your users may quietly depend on needs to be re-expressed through the new policies before the grace period runs out.

Where it meets Autopilot

The restore page appears during setup after the user authenticates, which means it lives inside whatever provisioning flow you run, and not every flow qualifies. Classic Autopilot supports it only in user-driven mode; self-deploying mode and the technician flow of pre-provisioning are explicitly out, as are hybrid join enrollments during the out-of-box experience. Autopilot device preparation, the go-forward path for cloud-native Entra join that the Autopilot article describes, is by its nature a user-driven Entra join flow, and restore works within it in practice, though Microsoft’s documentation supports this mostly by not listing it among the exclusions. The pairing is clearly where the design is heading: device preparation removes the hardware-hash logistics from provisioning, and settings restore removes the personalization loss, which together make device replacement approach the experience of signing into a new phone. One operational footnote: on builds that predate the July 2025 updates, the restore experience depends on quality updates landing during setup, so keep update installation enabled in your enrollment status page profile.

The design I recommend

Enable backup broadly and ahead of the default flip, so the flip becomes a non-event you already own rather than a change that happens to you. Leave the granular opt-outs alone unless a specific data-governance concern names a specific category, because a partially backed-up profile mostly delivers a partially disappointing restore. Turn on the restore side deliberately: the out-of-box restore is a tenant-wide setting rather than a targeted one, though the newer first sign-in restore can be piloted by group through its own policy, and treat that switch as the real go-live decision. Confirm Known Folder Move is universal first, since a settings restore next to missing files reads to the user as a failed migration no matter how well it worked. And write the expectation-setting sentence for your service desk before the first swap: settings and Store pins return, applications reinstall from Intune over the following hours, and files were never on this train because they ride OneDrive.

None of this changes what provisioning is. It changes what provisioning feels like, and that is not a small thing. The gap between a correctly configured device and a familiar one is where users form their opinion of every migration you will ever run, and this is the first Windows feature that closes it as a matter of platform default rather than heroic scripting. Take the default, shape it with policy, and let the trunk unpack itself.


Intune Deployment Guide · Phase 4: Provisioning
‹ Previous: [4.3] Co-Management