A strategy to manage your Windows 10 lifecycle

In case you missed it, Windows 10 isn’t the last version of Windows, really it was the first release of getting a new version twice a year! The above chart shows the releases in the past two years.

The concept is called Windows as a Service, but what it boils down to is the fastest pace of Windows version releases ever seen. And with each version release, there is a version retirement (indeed, the first version of Windows 10, 1507, is already end of life).

For any organisation this upgrade pace will be a challenge that will need a management strategy.

This post provides an example strategy for consideration.

Historically, Windows 10 has not ha been a set release and retirement rhythm, but going forward Microsoft is targeting two version releases per year.

This means you could rapidly get a fragmented Windows 10 environment.

This is important as it will increase the support overheads.

For example, Windows 10 updates are version specific, if you have three versions of Windows 10 you will have three sets of updates to manage. You will also have three sets of Windows images to manage.

A significant way to reduce support overheads is to minimise the operating systems in your environment.

The charts that follow illustrates an approach of having just one target Windows 10 version (in pink).

To achieve this you need to have a continuos process of pilot and migration as described next.

You start by piloting the next version of Windows 10 (which will be in the Current Branch release) for 2 – 3 months (in yellow) while having just one current Windows 10 version for your users.

As soon as pilot is complete, you migrate off the previous version and retire that version from your organisation (red arrow).

As soon as migration is complete you immediately start step 1 again and pilot the next version of Windows (you can trust there will be a new version to pilot given the planned releases in March and September each year).

Now you repeat the process, continually.

Per the below chart, you will be doing two pilots and two migrations every 12 months.

In parallel to the above, you will have monthly quality updates to manage (at least if you follow the above strategy you can limit the quality updates to just two versions of Windows 10 – your current version, and your incoming version).

This process may sound a lot of work, but it is actually the path with the least work, because:

  • Microsoft will only support two Current Branch for Business versions. Operating on non supported versions only results in security issues and operational overheads.
  • By keeping a continual cadence of pilot and migrate your teams will get more efficient at the release process rather than doing two big bursts per year.

With that said, the process will require a fundamental mindset shift for IT departments that do not have a mature release management process. Thus, if you have not yet deployed Windows 10, consider the capability changes you  need to support it successfully.

1 Comment