<img src="https://secure.leadforensics.com/51024.png" style="display:none;">

Understanding The Windows-as-a-Service Timeline (As of September 2021)

(Please note: This post is part of the "Definitive Guide To Windows-as-a-Service Management" blog series and will be updated periodically as the latest information is available. Last Update: September 2021)

A while back, we took a closer look at the Windows-as-a-Service Support Model, formerly known as Windows Branching — a topic that has been causing much confusion since the launch of Windows 10. Because many people felt they didn’t know enough about it, we are covering this topic extensively by:

[Learn how to use Dashworks for your Windows-as-a-Service Management.]

In this article, we will pick apart the confusion around the Windows-as-a-Service release and support timelines and keep you updated on the latest news on terminology and rule updates.

Planning Your Upgrade & Support Timeline

So, let’s talk about the exact timing. Please note that we will only talk about Semi-Annual Channel updates for Windows 10 Enterprise and Education editions below. Long-Term Servicing Branch does not receive any feature upgrades and the Windows Insider Preview precedes each release.

Windows Update May-01

(Image Credit: Juriba, Updated: May, 2021)

As you can see from the graphic above, Microsoft published their initial release of Windows 10 in July 2015. Feature updates are named (e.g., "Initial Release", "Fall Creators Update") and each one received a version number (“1507”) that is based on its release date (YYMM). However, due to the actual timing of the releases not falling into the planned release month, and the difference in seasons between the Northern and Southern Hemispheres, Microsoft has now adopted a new version number system starting with the October 2020 release. It is now 20H2, where the first two digits are the year, and the last two digits are the first half (H1) or second half (H2) of the year. Since that initial release, there has been a total of eleven (11) feature updates released.

After multiple EOL extensions, as well as name and policy changes, Microsoft has the following policy outlined for feature updates. There are two (2) releases a year, one in the spring and one in the fall. The spring update (now H1) is serviced for 18 months from release, while the fall update (now H2) is serviced for 30 months from its release date. The last two second half updates, versions 1909 and 20H2, were minor updates, akin to a service pack in previous versions of Windows. It is not conclusive if this pattern of major/minor updates will continue into 2021. Version 21H2 will also be a scoped release.

New call-to-action

CB, CBB: A Little Windows 10 Servicing History

There is a lot of outdated information floating around and, for that reason, we have decided to add a little background context to explain Microsoft's original approach to the service timeline for Windows 10 before we discuss the Support Timeline Logic going forward.

Initially, Microsoft announced that it would only ever support two subsequent Current Branch for Business (CBB) versions (e.g., 1511 and 1607), that is a feature update that was previously released into the Current Branch (CB) but now deemed enterprise-ready by Microsoft and republished as a Current Branch for Business, at one given point in time.

That means that as soon as N+2 version is published into the Current Branch for Business, the 60-day grace period countdown to end-of-life for version N kicks in. To calculate the end-of-life date of the version you were upgrading to, you had to know the release date of the two versions ahead, and add the four months for releasing the version into the Current Branch for Business as well as the grace period.

For example, if you are on CBB 1511, based on this schedule, you have 10 months to upgrade starting from the release of 1703 into Current Branch (April 2017) — which brings you to January 2018Consequently, if you are currently on the initial release, you have to upgrade as soon as possible, since 1507 reaches its end-of-life on May 9, 2017 and security updates will no longer be delivered! In extreme cases, businesses do not have more than 16 months on one version and will be on a perpetual upgrade cycle to ensure security compliance.

Things got very confusing very quickly. And even if you could figure it out, release dates slipped all the time. For example, following this logic, 1507 should have lost support in January of 2017, but the EOL date was pushed to March and actually went end-of-life on May 9, 2017.

New, Simplified Windows-as-a-Service Support Timeline Kicks In

Microsoft announced in April 2017 significant changes to its Windows-as-a-Service support model to align the Office 365 ProPlus release cycle with the Windows 10 and Microsoft SCCM support calendars. With the release of the Fall Creators Update in October 2017, all feature updates would be released in March or September and have a set support window of 18 months with no additional grace periods.

However, in November 2017, Michael Niehaus, the former Director of Product Marketing at Microsoft, announced that the software giant will grant enterprises and educational institutions who are currently running version 1511 an additional six months of patches for 'critical' and 'important' security vulnerabilities. And in February 2018, Microsoft announced that it will also grant the 6-month EOL extension for versions 1607, 1703, and 1709.

Much of the originally simplified support timelines were revised to a new support model: Starting on September 6th, 2018, Microsoft extended the support windows for all currently supported Windows 10 Enterprise and Education editions (versions 1607, 1703, 1709, and 1803) to 30 months. In addition, starting with 1809, all Fall Feature Updates will also receive 30 months of support, while all Spring Feature Updates only get 18 months.

Additionally, versions 1709 and 1803 were granted an additional extension due to the Covid-19 pandemic.

To keep up to date, please see our post on the release and EOL dates of all Windows 10 versions.

Windows 10 Deployment Rings & Skipping An Update

To improve the release quality and simplify deployments, quality updates as well as feature upgrades are cumulative; meaning, they get bigger with each new update as they include the previous updates as well as new updates. This means that by installing the latest version, your device is completely up-to-date. In addition, unlike earlier versions of Windows, the new servicing options cannot be deployed as subsets but must be installed entirely or not at all. Consequently, many IT project managers are wondering whether or not it is feasible to just skip one or two upgrade cycles.

If you are debating whether you should go ahead and install every one as they come or skip some, you will be happy to know that, theoretically, you can skip an update. This has now been made even easier by Microsoft with the new extended support.

But since the versions are supported only for a limited amount of time, the clock is now ticking much faster before you will have to install all fixes and features. No matter what the exact details are for when each release goes end-of-life, the cadence is faster than it has ever been and IT project managers must have upgrade plans in motion way in advance of a feature upgrade EOL date.

However, before you decide to go down that road, read our article on Windows 10 Deployment Rings which goes into more detail regarding why, if you decide to skip one release, the majority of your business users would be left unprotected while you are trying to play catch-up.


It is clear that with so many management options and the forced nature of updates and upgrades, IT departments need to prepare themselves for a significant culture shift in managing Windows-as-a-Service.

Every month, assets on old OS versions will get nearer to their end-of-life, and a constant plan of action is required to ensure that your organization is ready for the latest feature upgrade. In the future, this could mean an entirely new version of Internet Explorer, or depreciation of an old OS feature used in some of your critical applications.

Understanding your application estate (both fat client and web apps) and its readiness for the latest feature upgrade will be of paramount importance to ensuring minimal impact to your end users. We're building Juriba's Dashworks software to help you navigate these uncharted waters, so look out for release announcements in the near future.

New Call-to-action