On July 1, 2026, Microsoft pulled the plug on managing Enterprise State Roaming (ESR) through the Entra portal. For over a decade, IT admins used that familiar toggle to decide which users could sync their Windows settings across devices. That control panel is gone. The settings themselves aren’t going away – they’re now governed by the same policy engines that manage Windows Backup for Organizations, recently rebranded as “Windows settings backup and restore.” The handoff is complete. The question now: has your organization caught up?

What Just Happened to Enterprise State Roaming

The change is at once simple and easily misunderstood. Microsoft hasn’t retired ESR’s core capability – the synchronization of personalization, accessibility, and app settings that moves with a user from one PC to another. But it has relocated the management plane. The Entra portal (formerly Azure AD) no longer offers the ESR configuration blade. Instead, you express your organization’s intent through Intune, another mobile device management (MDM) platform, or Group Policy (GPO).

Microsoft flagged the transition in May 2026, but July 1 marks the point where policy-based management became the only supported method. At the same time, the product name is shifting: “Windows Backup for Organizations” is being replaced by “Windows settings backup and restore.” During the transition window, you might see both names in documentation, policy interfaces, and logs.

Crucially, the change doesn’t expand what gets synced. Roaming still covers a curated set of Windows settings and, when backup is enabled, the list of installed Microsoft Store apps. It is not a full image backup, a general application migration tool, or a user file backup solution.

The Real-World Impact: Why This Matters Now

For the average Windows user, nothing changes – unless their employer fails to adapt. If your IT department misses the handoff, a replacement PC won’t bring over the personalized desktop layout, browser favorites, screen magnifier preference, or centrally approved Store apps that the user relied on. That’s the operational danger: a silent break in the refresh chain.

The accountability gap is the first risk. Identity administrators who traditionally ticked the ESR checkbox in Entra may assume nothing more needs doing. Endpoint engineering teams might not realize the old intent was never translated into a new policy. The result: settings that roam for some users, silently stop for others, and produce a confusing helpdesk spike during the next device refresh wave.

Microsoft says that existing ESR and GPO/MDM roaming controls will coexist for about a year, with policy-based controls taking precedence. That bridge gives you time, but it isn’t a permanent dual-management model. Without a clear handoff, you’ll be troubleshooting inconsistent behavior between devices governed by different authorities.

The Path That Led Here

Enterprise State Roaming launched as a way to make Windows more user-centric in a world of multiple devices. Under Entra, admins could enable or disable the feature for all users or selected groups. As cloud management matured, Microsoft began investing in a broader “Windows Backup for Organizations” service that would handle not just settings but also app lists, with an eye toward accelerating PC refreshes and Windows 11 migrations.

The backup service initially felt separate from ESR, but Microsoft’s strategy has been to fold roaming under the same policy umbrella. The Learn page now explicitly states: “Starting July 2026, Enterprise State Roaming (ESR) management has moved to Windows settings backup and restore.” This consolidation clarifies the product line: one policy surface for both backup and roaming, with restore handled separately.

The rename from “Windows Backup for Organizations” to “Windows settings backup and restore” aligns the product with its actual scope – it’s about user settings, not full device backup. That nuance is critical when planning your refresh, as we’ll see.

Your Seven-Step Transition Checklist

The immediate task isn’t to locate a hidden Entra checkbox – it’s to transfer the old intent into an owned endpoint policy and validate the outcome. Here’s a practical sequence:

  1. Document the former ESR scope. Before the Entra blade disappears completely, record which users or groups had roaming enabled and any custom restrictions. This history must be preserved; once the portal removes the configuration interface, reconstructing it will be harder.
  2. Inventory existing policy controls. Check your GPO and MDM environments for any existing settings synchronization policies. Microsoft’s guidance confirms that existing controls will continue to be honored for approximately one year, but you need to know what’s already in place to avoid conflicts.
  3. Choose your management authority. Decide whether you’ll use Intune, a third-party MDM, or GPO to enforce the new policy. While you can use multiple, WindowsForum’s analysis recommends a single authority to reduce ambiguity. If you deliberately mix them, document the division of control and the escalation path for conflicts.
  4. Separate backup from restore. This is the single most common pitfall. Enabling backup does not automatically configure restore. You must independently approve and test both. The backup policy tells Windows to periodically save settings to the cloud; the restore policy controls whether and when a new device offers to apply that saved state.
  5. Assign clear ownership. Identity team records the old Entra intent and target population. Endpoint management handles the new policy configuration and monitoring. Desktop engineering defines the restore experience and pass/fail criteria for a replacement device. Service desk needs a diagnostic script that distinguishes backup failure from restore failure from policy precedence tangles.
  6. Pilot from source to replacement. Don’t just check policy assignment reports. Take a source PC, verify that its settings and Store app list are backed up (you can check via the Windows Backup app or Microsoft’s Graph APIs), then provision a replacement device using your normal process – Autopilot, OOBE, or custom imaging. Confirm that the restore page appears and that after setup, the expected settings and apps are present.
  7. Escalate cleanly. If the old Entra target population can’t be reconstructed, if GPO and MDM records contradict each other, if a device reports policy but backup evidence is missing, or if restore doesn’t appear during the planned refresh workflow – stop. These conditions demand cross-team investigation, not a wider deployment ring.

Test Before You Trust: The Separate Reality of Restore

Restore is the trickiest part because it depends on so many moving pieces. Microsoft documents two restore triggers: during out-of-box experience (OOBE) for a new or wiped device, and at first sign-in after enrollment for an already-enrolled device. Each requires specific Windows builds and configuration steps.

For OOBE restore, the device must run Windows 11 22H2 build 22621.3958 or later, 23H2 build 22631.3958+, or 24H2 build 26100.4770+. Additionally, if you use Autopilot, the profile must be user-driven, not self-deploying. The restore policy must be applied before enrollment – in Intune, that means using the tenant-wide enrollment policy under Devices > Enrollment > Windows Backup and Restore. Post-enrollment device configuration policies won’t take effect in time for OOBE.

For first-sign-in restore, the device must already be enrolled and running 24H2 build 26100.7922+ or 25H2 build 26200.7922+. In this case, a standard Intune device configuration policy (or GPO) works, because it applies after enrollment.

Make sure the following policies are NOT disabled in your environment, as they are prerequisites for Windows Backup to function:
- EnableActivityFeed, PublishUserActivities, UploadUserActivities (under System > OS Policies)
- EnableCDP (Cloud Data Protection)
- AllowConnectedDevices (Connectivity)

If any of these are set to Disabled, backup silently fails.

Also watch for Conditional Access interference. If your tenant blocks authentication to the obscure Microsoft service with app ID d32c68ad-72d2-4acb-a0c7-46bb2cf93873, the restore flow will fail. You may need a custom Conditional Access policy to exempt that app.

Finally, acknowledge the product’s limitations. Restore won’t bring over classic Win32 apps, files in Downloads or Documents, or unsupported settings. It’s a settings-and-Store-app-list service. If your refresh playbook assumes a full-machine transfer, you’ll be disappointed.

Looking Ahead

The July 1 milestone is part of a broader push to simplify Windows lifecycle management. With Windows 10 support ending and AI PCs arriving, Microsoft is betting on cloud-first, policy-driven configuration. The renamed “Windows settings backup and restore” will likely see tighter integration with Windows Autopilot and the Microsoft Graph, giving admins better reporting and automation.

For now, treat the one-year compatibility period as a countdown, not a cushion. Reconcile your old Entra intent, assign policy ownership, and run a realistic pilot. The next time your procurement team orders a batch of laptops, your users’ settings should move with them – no Entra portal required.

That’s the whole story: a handoff, not a retirement. But only if you catch it.