Every major software release has a lifecycle – the end point of which being when the developer no longer can support bugs or changes to the code because of age. Twenty years ago, a new operating system was often deployed a year or two after the consumer version was released, in many cases after the first service pack had been released. This meant that “end of life” was often timed to many years post release, in some cases a decade. (Windows XP, for instance, was supported for 12 years post release!) After end of life was reached, the developer would no longer issue security updates or patches, which meant that these dates were critical for folks to know. These lengthy support times caused three downstream effects among businesses: Many businesses faced with a hardware or software requirement to upgrade simply postponed, forcing staff and partners to use older software and creating large security vulnerabilities over time; new functionality was positioned as “risky”, even if the functionality was security related Because deployment of a new operating system (or even a new application) required major changes to user experience, staggering releases over 3-5 years was positioned as both fiscally prudent and easier to plan change management around. Every customer has a different mix of applications – when combined with a “choose which patches to apply” model on the security and features front, and even a single organization might have thousands of different types of code deployed on machines. This meant that when problems occurred, it was nearly impossible to replicate the exact mix of OS and application information to get to the root cause, even with accurate telemetry. The longer software was deployed, the worse this problem became. With the advent of the cloud, the ability to update software and collect telemetry, including the operating system itself, became quite trivial. This caused major software developers, including Microsoft, to start to shift the landscape of support – instead of attempting to support an OS for 3-5 years, developers moved the support window to 1-2 years. This wasn’t a change made in a vacuum: the ability to generate smaller releases containing code that had already been proven to work, tied to real-time telemetry, is part of the broader landscape shift from waterfall based development to more agile “dev/ops” aligned approaches. For a software developer, all of these changes are broadly positive: less financial risk, greater customer engagement and the ability to make changes quickly before products are marketed. For consumers and businesses, there are key benefits as well: security is now baked into software rather than being bolted on, features that enter the consumer space can be brought into the business more quickly, and because changes are smaller, change management can be more easily adopted. Despite all these benefits, these are still changes, and with any chance, businesses will take different amount of times to adopt. What has become clear over the past three years is that many organizations haven’t fully grasped the support implications that accompany a faster pace of versions and improved security. Many organizations, when Windows 10 was originally released, decided to continue deployment and patching via “images” instead of the new modern management methods. This has created a big challenge: if an organization deployed Windows 10 back in August of 2016, the version they deployed hit end of life April of this year. Even more important, if they waited until 2017 to deploy Windows 10, but chose to deploy the version of Windows 10 from August of 2016 then they were in the same boat: end of life happened in April of this year, which meant no new security patches or updates. This has caused confusion among some customers, especially because with Windows 7 and Windows 8.1, the lifecycle was much, much longer. Windows 7 (with service pack 1; the original version hit end of life in 2013) will hit end of life in January of 2020. But the more important date is that for Windows 10, versions 1507 – 1607, have already hit end of life. Even newer versions, starting with releases in the year 2017, are going to hit end of life prior to 2020. Here are the key expiration dates: Windows 10 version 1703 (released in March of 2017) – expires October 9th for consumers and March 9th, 2019 for enterprises Windows 10 version 1709 (released in September of 2017) – expires April 9th of 2019 for consumers, and October 9th of 2019 for enterprises Windows 10 version 1803 (released in March of this year) – expires November 12th of 2019 All three of these dates occur before 2020. That means customers need to not only deploy current versions of Windows 10, but to also have systems in place that allow existing machines running Windows 10 to be seamlessly upgraded to a newer version at a minimum every 18 months. That leads to a simple conclusion: if your organization lacks the ability to deploy new versions of Windows 10 quicker than every 18 months, then you will find yourself outside the end-of-life window. If it takes your organization over six months to perform application remediation today, then you need help. If wrapping your mind around how you’d be able to upgrade Windows 10 (and apps) every six months is causing you friction – you need help. Ultimately, these end-of-life dates may drive the right behavior at customers and partners to work collaboratively together to modernize the way Windows 10 is deployed and maintained. The alternative, to go beyond end-of-life, simply isn’t viable.