Windows 11 24H2 End of Support: An SMB Update Plan

Windows 11 version 24H2 Home and Pro reach end of updates on October 13, 2026. If those PCs run your accounting, scheduling, customer service, or field operations, the deadline belongs on the business calendar—not just the IT dashboard. The goal is a supported fleet that still does its job, with a documented recovery option for machines that do not upgrade cleanly.

Microsoft says affected devices will stop receiving monthly security and preview updates, fixes for known issues, time-zone updates, and technical support. It also says the automatic move to 25H2 applies to Home and Pro devices not managed by IT departments. A managed fleet needs its own targeting and verification plan. Microsoft's 24H2 end-of-updates notice establishes both points.

Guidance checked September 23, 2026. Product facts below come from Microsoft; the rollout checklist is ITECS planning guidance, not a guarantee that a particular device or application will upgrade successfully.

First, identify which deadline actually applies

“We use Windows 11” is not a sufficient inventory answer. Edition, version, and servicing channel determine the support date. Separate standard Enterprise and Education installations from Home and Pro, and check LTSC or specialized editions independently.

These dates are from Microsoft's Windows 11 release table. That table also explains why the higher version number 26H1 is not the answer for this fleet: it is designed for selected new hardware, not offered as an in-place update from existing 24H2 or 25H2 devices.

A PC does not automatically stop working when support ends. Continuing to operate, however, is not the same as remaining supported. Security tools and a valid Windows license do not replace operating-system fixes.

Build one inventory that business owners can act on

Export the device list from the management platform, then reconcile it with purchasing records and department owners. Include spare laptops, shared PCs, rarely connected field devices, and home-office computers that still access company systems. A device missing from a dashboard is an unresolved item, not a successful upgrade.

• Identity: device name or asset ID, assigned owner, department, location, last check-in, edition, version, and build.
• Management: Intune enrollment, update authority, existing target-version policies, group membership, pauses, and exclusions.
• Business dependencies: critical applications, versions, application owner, peripherals, VPN, authentication, and vendor support status.
• Readiness: free disk space, power, connectivity, encryption status, recovery-key availability, and backup or rebuild readiness.
• Disposition: pilot, production wave, remediation, replacement, or an approved exception with an owner and expiry date.

For a small fleet, verify uncertain machines directly in Windows Settings rather than trusting an old spreadsheet. Finance should see replacement and technician-cost exceptions; operations should see which business functions depend on each rollout wave.

Check hardware, applications, storage, and recovery access

Updating from 24H2 to 25H2 uses an enablement package on the documented path, activating features on a shared servicing foundation. That can make the update smaller than a full operating-system replacement, but it does not eliminate compatibility testing. Confirm the required cumulative-update baseline using Microsoft's 25H2 enablement-package requirements.

Check the PC manufacturer's firmware and driver support, hardware eligibility, storage health, and critical application compatibility. Test endpoint protection, print and scan workflows, smart cards, accessibility tools, and industry-specific peripherals. Do not bypass hardware requirements simply because a machine already runs 24H2.

Measure actual free space before assigning the upgrade. Microsoft explains that space requirements vary by update path and installed features; download size alone does not describe the working space required. Use the device's readiness result and preserve needed recovery files rather than applying one universal cleanup threshold. See Microsoft's update storage guidance.

Verify that authorized support staff can retrieve the correct BitLocker recovery key through the approved escrow system. Record that the recovery process was tested—not the key itself—in the change ticket. Do not email keys, put them in rollout spreadsheets, or routinely disable encryption. Microsoft's BitLocker key-rotation guidance explains the supported control for keys used or potentially exposed during support.

Deliberately target managed devices with Intune or Windows Update policies

The automatic unmanaged-device rollout is not proof that company PCs have a target or deadline. Establish which system controls updates: Intune, Windows Autopatch, Configuration Manager, Group Policy, or another approved tool. Resolve competing assignments before expanding a rollout.

In Intune, feature-update policies choose the Windows version; update rings govern behavior such as restarts and active hours. When both apply, Microsoft recommends setting the ring's feature-update deferral to zero and ensuring feature updates are not paused. First verify licensing, enrollment, and policy prerequisites. Apply the documented policy-transition sequence to pilot devices before changing fleet-wide deferrals. Microsoft's feature-update overview describes these controls.

There is a deadline trap in the console: a feature-update profile's Support End Date uses the Enterprise/Education date. It is not the support deadline for a Pro fleet. Multiple feature-update policies can also offer the latest applicable targeted version, while selecting an older target does not downgrade an already newer PC. Check effective assignments, not just policy names. Microsoft documents these policy behaviors.

For Windows Update for Business environments using Group Policy or MDM settings, record the approved product and target release alongside restart and deadline settings. Microsoft now documents these as Windows Update client policies. Having a policy configured is only the start; verify that each device receives and follows it.

Use pilot rings and respect safeguard holds

Choose a pilot that represents how the business works: an office user, a remote user, a shared device, and the machines running your hardest-to-replace applications. Do not use only IT's newest laptops. Ask application owners to complete real tasks—opening an application is not the same as completing payroll, generating a report, printing labels, or processing an order.

Agree on these gates before moving from pilot to production:

• Sign-in, network access, critical applications, and required peripherals pass their documented tests.
• Encryption, endpoint protection, management check-in, and backup status remain healthy.
• No unresolved business-blocking failure affects the next group.
• Support capacity, user notices, and a tested recovery route are available for that wave.

A safeguard hold means Microsoft has identified a compatibility or quality risk and is withholding the offer through Windows Update. Record the hold, affected devices, vendor dependency, and next review date. Do not use an installation image to sidestep it merely to meet the deadline: hold protection does not automatically cover every alternative delivery channel. Microsoft recommends waiting for the issue to be resolved.

Pause expansion when a pilot finds a critical problem. A hold or failed test should trigger an owned exception and remediation decision, not an unrecorded indefinite postponement.

Plan for remote users, bandwidth, and the service desk

Schedule downloads and restarts around real work patterns. Confirm that remote PCs will be powered, plugged in, and connected during the rollout. Give traveling staff a support contact and a fallback for losing VPN access. Avoid concentrating every department's critical workstations in one wave.

Review home-connection limits, office bandwidth, proxy access, and VPN routing. Delivery Optimization can reduce repeated downloads, with configurable bandwidth and peer behavior; use the approved network design rather than casually opening new sharing paths. Microsoft's Delivery Optimization reference covers those controls.

Send one plain-language notice stating the affected devices, maintenance window, expected restart, preparation steps, support channel, and how to report an application problem. Never ask users to email passwords or recovery keys. Give technicians the target version, known issues, recovery decision tree, escalation owner, and a way to associate incidents with the rollout wave.

Prove rollback for the actual installation path

Do not promise that an Intune rollback button will reverse every 25H2 upgrade. Microsoft's update-ring documentation explicitly says feature-update uninstallation is unsuccessful when the update was applied using an enablement package. That matters for the documented 24H2-to-25H2 path. A pause does not restore an upgraded PC, and scheduled updates may still install before a device receives the pause policy. See Intune's uninstall limitations.

For installation paths that support it, Windows' usual Go back option is available for ten days and depends on retained recovery files. Apps, drivers, and settings added afterward can be removed. Administrators can configure an eligible OS uninstall window from 2 to 60 days, but that setting does not make an ineligible upgrade reversible. See Windows recovery guidance and DISM's uninstall-window documentation.

During the pilot, test the recovery method for the exact hardware, installation path, and management setup. Where uninstall is unavailable, plan an approved rebuild or replacement device and a verified restoration of required data and applications. Identify who can authorize it and how the employee continues working. Do not delete recovery files before the agreed decision point.

Returning to 24H2 Home or Pro after October 13 does not restore support. Treat any such recovery as a temporary business-continuity exception with a prompt supported-state plan, not the final destination.

Close with evidence, not just an “installed” count

Monitor every wave after restart. Confirm the actual edition, version, build, and latest check-in; then review application incidents, failed updates, encryption and security-agent status, and user sign-off. Track never-connected devices separately from failed installations. Intune's feature-update reports can help distinguish deployment states, but they do not replace business-function tests.

Maintain a small evidence packet: dated inventory, target policy and assignments, pilot results, change approval, communications, recovery test, completed-device list, and unresolved exceptions. Assign each exception a business owner, technical owner, temporary controls, remediation action, cost decision, and next review date.

Unsupported systems can leave gaps against your organization's patching requirements and customer or insurer expectations. Have the responsible owner review the actual obligations; this article is not a compliance determination. An exception record makes the decision visible, but does not itself make the device secure or compliant.

A practical finish line for October

With the deadline approaching, set a completion date before October 13 and reserve time for failed devices. Work backward from business-critical applications, staff availability, and recovery capacity. If that schedule cannot be met safely, escalate the precise remaining devices and decisions now.

1. Confirm every affected device and its owner.
2. Select a supported target and reconcile update policies.
3. Validate readiness, application behavior, and recovery in a representative pilot.
4. Expand in controlled waves with clear communications and stop criteria.
5. Verify the supported state and resolve or explicitly own every exception.

Need help turning the inventory into an executable update plan? Explore ITECS Microsoft 365 consulting or discuss your Windows fleet with ITECS. Bring the device count, editions, critical applications, and known blockers so the next conversation can focus on scope and responsibilities.

Editorial note: This article was prepared with AI assistance and checked against the linked Microsoft documentation. The graphic is an illustrative planning comparison, not a Microsoft product interface. Recheck release health and device-specific guidance before implementation.