Windows 11 24H2 End of Support: A Business Upgrade Checklist

You replaced the Windows 10 laptops, the fleet dashboard says Windows 11, and the monthly update report looks reassuring. Then a supplier asks whether every workstation is on a supported release. “We have Windows 11” is not enough information to answer.

Windows 11 24H2 Home and Pro reached end of updates on 13 October 2026. Enterprise and Education have a different timetable. For a Luxembourg SME, the immediate job is to identify affected devices and move them through a tested upgrade, while keeping the systems people depend on available.

This checklist is current as of 29 October 2026. The support facts below come from Microsoft; the inventory, pilot and handover steps are our recommended operating approach. Check the linked release information again when scheduling your own rollout.

Which Windows 11 24H2 editions are affected?

Use the edition and feature version together. Microsoft's 24H2 release health notice distinguishes the ended Home and Pro release from Enterprise and Education, which continue receiving monthly security updates until 12 October 2027.

The computer does not stop working because its release reaches end of updates. The operational concern is the support and servicing position of the installed system. Do not assume that an update appearing in a management console proves continued coverage for every edition sharing a version number.

Build an inventory that answers the actual question

For a single device, inspect Settings, System, About and the Windows specifications. For a fleet, export the equivalent information from the management system and reconcile it with the asset register. Include the last successful check-in so an old inventory record is not mistaken for the device's present condition.

Use one row per device with these fields: asset identifier, assigned user, business owner, edition, feature version, build, hardware model, last check-in, update source and next action. Add critical applications, remote-working requirements and any recorded update error or compatibility hold.

Include spare laptops, part-time staff, field equipment and machines that connect only occasionally. Agree how personally owned devices accessing business systems are handled. An inventory limited to machines currently on the office network cannot close those gaps.

Give each affected row an owner. “The IT provider is looking at Windows” is too vague to manage a rollout. Ask for a decision per device: upgrade, investigate a blocker, replace, retire or confirm that a different support timetable applies. Our infrastructure management service can help establish that operating record.

Choose a supported target using compatibility evidence

Microsoft's Windows 11 release information lists the current releases and their servicing dates. Its 24H2 notice points affected users towards 25H2 or 26H2. Choose the release your hardware, software suppliers and management tools can support, with enough servicing time for your next planned review.

Do not select a target solely because its version number looks newest. Microsoft describes 26H1 as intended for new devices rather than an in-place feature update for existing 24H2 or 25H2 systems. The deployment path matters as much as the support date.

Write down the decision and its dependencies: accounting software, VPN client, endpoint protection, specialist peripherals and any supplier support conditions. If evidence is missing, give that question to an owner rather than silently treating the application as compatible.

Buying a different edition should not be the default answer to a delayed upgrade. If an edition change is being considered, confirm licensing rights, deployment requirements and its wider cost first. A supported target that the organisation can maintain is more useful than an unexplained licence purchase.

Why is the feature update not being offered?

Separate policy, compatibility and device health. An update might be paused, the device might still be targeted at an older release, a safeguard hold might apply, or the endpoint might not be checking in correctly. Capture the actual status before changing settings.

Microsoft's Intune documentation states that feature update targeting remains in effect until modified or removed. Review the assigned target and group membership where Intune is used. Do not assume that waiting for another monthly quality update will change the feature release policy.

Safeguard holds protect devices from known upgrade problems. Treat a hold as a compatibility investigation: identify it, review the affected configuration and establish a supported resolution. A manual installation is not a substitute for understanding the reason for the hold.

If a device is remote or rarely online, agree a practical route to support it. Check available storage, power, connection quality and the ability to recover if access is lost. Keep the person using it informed; an unexpected restart during a customer appointment is an avoidable operational failure.

Test business tasks, including the awkward ones

Pick a pilot that represents the fleet's variety. Include different hardware models and people who use the applications that would cause real disruption if they failed. IT's own laptops alone are a poor sample of the organisation's work.

Prepare a short acceptance sheet with a named business tester for each critical workflow. Ask the person to perform a realistic task and record the result. “The application opens” is weaker evidence than successfully completing a test invoice, authorised signature or remote support session.

• Sign in, lock, unlock and reconnect after a restart.
• Connect through the normal remote-working route and open required resources.
• Test printing, scanning, docking and specialist hardware where used.
• Complete a representative finance or line-of-business transaction with safe test data.
• Check endpoint protection, backup or synchronisation, and management check-in.

Include the relevant language settings and keyboard layouts for a multilingual workplace. If staff use certificates, smart cards or electronic signature tools, test those with the responsible supplier. These are suggested checks, not a claim that any particular application has a current compatibility fault.

Microsoft's deployment preparation guidance provides the broader vendor process. Turn it into evidence for your own environment rather than a copied checklist nobody signs off.

Prepare recovery before expanding the rollout

Confirm where business data is stored and whether the recovery process works. A synchronisation icon is not, on its own, a tested recovery plan. Establish who can retrieve authorised disk-encryption recovery keys and how support will reach a remote user if the normal VPN or sign-in route fails.

Choose a recovery method for the deployment you are actually performing. Confirm whether an operating-system rollback is available and under what conditions; do not promise a universal recovery window. Have an alternative, such as a prepared replacement device, for work that cannot wait.

Document the decision to pause a deployment. Define which failures would stop the next group, who makes that decision and how the business will be told. “Continue unless someone complains” puts the burden on staff to discover and explain a shared fault during their working day.

Roll out in groups and verify the result

After a successful pilot, group devices by business risk and support needs. Schedule each group with a clear user message, an available support contact and an agreed recovery route. Review the results before expanding to the next group.

Verify the installed feature version and edition after the restart. Then check the latest applicable security update, endpoint protection and management check-in. Record failed and offline devices separately so a high overall success rate does not hide a small set that still needs action.

Ask business owners to confirm their acceptance checks. Keep evidence proportionate: a completed task checklist and relevant device status are usually more useful than a folder of screenshots with no conclusion. Record any issue, workaround, owner and follow-up date.

Our technology services connect deployment work with ongoing administration. The handover should leave someone responsible for the next release review, not merely a completed installation job.

Keep exceptions visible and time-limited

If an affected device cannot yet move, record the reason, business dependency, interim restrictions, responsible owner and next review date. Ask whether the device still needs the same access while the blocker is being resolved. Reducing exposure is an interim measure, not a renewal of Microsoft's support.

Agree an exit route for each exception. That could be a supplier fix, replacement application, replacement device or retirement of an unused workflow. Escalate a recurring blocker as a business decision rather than allowing it to disappear into the helpdesk queue.

Our earlier article on IT operations and resilience covers the wider ownership problem. This checklist addresses a narrower deliverable: knowing which Windows endpoints remain supported and showing that the affected ones have been moved successfully.

What to request from your IT provider

Ask for the reconciled inventory, chosen target release, pilot results, deployment status and exception register. Require a clear explanation of any devices still on 24H2 Home or Pro. Completion means that the business has usable devices on an appropriate support path, with remaining risks explicitly assigned.

For help checking a Windows fleet or planning the upgrade, contact ObsidianCorps with your approximate device count, management tools and business-critical applications. We can scope an assessment and a practical rollout around the systems your team actually uses.