All good things must come to an end, and the reign of Windows 7 as an actively supported, good-enough operating system is no exception. While it may feel like you just finished the heavy lifting of migrating your Windows XP machines to Windows 7, it turns out that Windows 7 is now more than ten years old, at least two and a half versions behind Windows 10 (depending on whether you consider Windows 8.1 to be a version of Windows all its own), and quickly approaching end of Microsoft support in January 2020.
All of this is to say that you need a plan. Except in some edge cases, it makes little sense to spend the time and money to migrate from Windows 7 to Windows 8.1, since that only buys you a couple more years of supportability. The smart money is on moving to Windows 10, buying everyone expensive Macs, or (gasp!) deploying Linux on the desktop. And while small businesses might be able to buy everyone MacBooks or move to Linux, large companies with lots of software investments in the Microsoft stack will continue running Windows, thus leaving Windows 10 as the only option.
NOTE: If you absolutely have to stay on Windows 7 for any meaningful length of time after the end of support, then you should seriously consider subscribing to extended support for Windows 7, which is available to companies of all sizes and offers security updates through January 2023 — for a fee, of course.
Of course, moving any large quantity of users from one operating system to another, especially one with as many differences, shiny new objects and moved cheese as Windows 10, is no small feat. That’s where this guide comes in. I want to help shine light on the considerations and actions you need to take in order to make your migration successful.
What’s in this guide?
Let’s start with a list of things to consider:
- Which releases to choose. Windows servicing these days is unlike Windows servicing has ever been, with Patch Tuesdays, patch rollups, security-only rollups, quality-only rollups, security plus quality rollups, semi-annual channels, long-term servicing channels, and more. Understanding which Windows 10 train to sign up for and board is more than half the battle.
- How to manage the update cycle, including automated management tools to create update rings, controlling membership of machines in those rings, and how to defer feature upgrades so you don’t get caught on the bleeding edge of updates and instead maintain a prudent, supported update cadence.
- Application compatibility. While at this point most versions of popular, off-the-shelf software have been proven safe to use with Windows 10, internally developed software and web applications may be incompatible with parts or all of Windows 10 clients. Rigorous compatibility testing is necessary, and I will include some tips and tools to help you achieve that in this guide.
- User training. In my estimation, the Windows 10 user interface is about 70% the same as Windows 7, but that last 30% can be a real killer, especially when it comes to wireless networks, control panel settings locations, joining domains, and the Start menu and attendant searching. In this guide, I will provide some links to good user training materials that ought to serve you well as a baseline resource.
Without further ado, let’s dive in.
Choosing Windows 10 releases
One of the most important decisions you will make is choosing the right release. Microsoft wants to deliver Windows 10 as a service, with the idea being that Windows is always updated and continually refreshed, unlike when you bought a wholesale number of licenses to Windows 7 and then you sat there running that until you needed to upgrade to another major version.
Of course, there need to be some marks of delineation between releases of Windows 10 if Microsoft isn’t going to increment the version numbers (Windows 29, anyone?), so there are a couple of ways Microsoft marks these “versions” of Windows:
The release number itself, which is generally in YYMM format, so the 1709 release of Windows 10 was targeted for September 2017 (although it wasn’t made generally available until October 2017), and the 1803 release was targeted for March 2018 (and actually began to roll out in late April).
For the past several years, release numbers in the semi-annual channel (more on that in a moment) have followed the same pattern: YY03 for the spring release and YY09 for the fall release. The exception will be the spring 2020 release, which Microsoft has announced will be version 2004, not 2003 as many expected. The reason? To avoid confusion with past Microsoft products such as Windows Server 2003. As far as we know, all other Windows 10 releases will follow the YY03/YY09 numbering convention.
The channel, which refers to the frequency of release. Imagine Windows being delivered via two pipes — one with more regular, frequent releases but with shorter timeframes for support, and another with much less frequent releases but a much longer supportable period. Windows 10 now has two channels:
1. A Semi-Annual Channel, or SAC, which targets two releases per year, one every March and one every September, although these are just targets and may slip or be pulled forward. Key here is that there are two releases a year, spaced about six months apart, and each is expected to be in production for no more than either 18 or 30 months, depending on whether you pick the spring or the fall update. After that period expires, you are required to move to a newer supported release in the channel to continue getting updates and support.
For those folks who have been paying attention for a while, there is no longer a Semi-Annual Channel (Targeted) release branch — there is only a single SAC release for each release. The decision to target early adopters and test groups with the SAC release is entirely up to you, and the bits with which you would do so are the same.
2. A Long-Term Servicing Channel, or LTSC, which gets a new release dropped every two to three years. (You may be more familiar with its previous name, Long-Term Servicing Branch, or LTSB.) Microsoft intends LTSC releases to be used on special devices like appliances, point of sale machines, medical devices, ATMs, and the like. These LTSC releases will be supported for ten years from the date of each release, making LTSC the closest thing to Windows of the past — at least in terms of support — that exists today.
So which one should you choose? It depends on a few things, really. For one, Microsoft’s advice is to use the SAC releases in any instance where users actually interact with their machines on a regular basis — knowledge work, as they like to call it. Microsoft claims the LTSC should be used only for appliance-like work, for single-purpose industrial machines, kiosks, and the like.
The LTSC does not include Microsoft Edge, Microsoft’s new browser intended to replace Internet Explorer, and it does not have Cortana, the personal assistant that is Redmond’s answer to the Amazon Alexa. There are a few other “creature comforts” LTSC does not have, but it is also important to note that the core OS is the same in the LTSC channel as the SAC, and it’s supported for over six times as long as the SAC.
Edge is by all accounts a less capable browser than Firefox or Google Chrome (although now that it has assumed the Chromium open-source codebase, it may become more useful in the future), and Cortana has limited enterprise appeal, so you may not be losing much in terms of functionality by deciding to deploy LTSC releases in your organization, and at the same time you are able to get off the 18- or 30-month upgrade hamster wheel that accompanies the choice to use SAC throughout your shop.
Unfortunately, LTSC is not all roses. Updates, including important security changes, that are included in SAC releases and patches do not always get backported to the LTSC releases, critical security mitigations excepted. We have already seen this when it comes to the new memory protection features like Control Flow Guard, Structured Exception Handling Overwrite Protection, and Windows Hello for Business (the on-premises edition) — these all got updated in earlier SAC releases, but they won’t appear for machines running the LTSC edition until they are upgraded to LTSC version 1809, which came out in November 2018 and as of this writing is the latest LTSC build. The next LTSC release is due at the end of 2021.
Even your choice of Microsoft Office versions needs reconciling against your Windows channel choices. Office 2019 is supported on LTSC, but not its predecessor Office 2016, and the subscription-based Office 365 “ProPlus” version (what most people are purchasing these days) is not supported on any LTSC build – which appears to me to be a purely artificial restriction designed to push you into SAC and away from LTSC.
I think the idea of restricting LTSC to devices and appliances is a little heavy-handed. If you have machines in a call center, school computer lab, or other mass computing environment that do not change often, run a relatively locked-down set of applications, and in general are more static in nature, then think about deploying an LTSC release. This is an especially powerful tactic if this group of machines does not rely on a locally installed copy of Microsoft Office, particularly in environments where either the free LibreOffice would work for local installs or there is a Remote Desktop Services deployment available that could provide access to Office suite applications.
On the other hand, for knowledge workers, mobile professionals, and telecommuters, running the SAC releases is the way to go simply to stay within the good graces of Microsoft support.
But which SAC releases? It depends on the season, really. All fall Windows 10 releases (those xx09 version numbers) for Windows 10 Enterprise and Education editions will have 30 months of support, up from 18. I think it’s reasonable to assume that these fall releases are the equivalent of service packs, with quality updates and fixes that deserve installation sooner rather than later. That’s the approach Microsoft is taking with Windows 10 1909, and Computerworld expects future fall releases to follow this pattern.
Theoretically, that’s two years, six months of support for a specific fall semi-annual channel release, but unless you install the new update immediately (which has been a problematic strategy in the past), you won’t actually get that long of a support window. The clock starts ticking as soon as each update is released, so if you wait six months to install it, the support window will run out 24 months later. Nevertheless, that’s significantly better than you’d get with an 18-month window; waiting six months to install a release in that scenario gives you only 12 months of support.
Let’s look at an example: Windows 10 version 1909 is due to be released this month, in November 2019. If you upgrade your users to it in spring 2020, you can stay with it until the spring of 2022, when its support window expires. At that point you can skip right over releases 2004, 2009, and 2103 and move directly to Windows 10 version 2109, which will have been released six months earlier in the fall of 2021. That way you’re staying behind the bleeding edge and letting others run into the huge problems and stability issues that are sadly part of Windows updates today, yet getting a solid two years of support for each version.
But be careful, because this 30-month courtesy is not extended to spring SAC releases (that is, those with xx03 version numbers, or in the case of the spring 2020 release, 2004); those still have a mere 18 months of support from the time the update is released. That said, Microsoft did extend the support window for two previous spring releases to 30 months: Version 1703, released in April 2017, was supported until October 8, 2019, and version 1803, released in April 2018, is supported until November 10, 2020.
Here are my recommendations:
Avoid spring releases entirely. Pretend they don’t exist, for the purposes of the enterprise. They are generally consumer-oriented feature updates, and they do not enjoy the extended support window that fall releases have.
Move up to the 1809 release as soon as is practical. Build 1809 was designated as “ready for business” on March 28, 2019, and is overall a fine target for current upgrading efforts. There’s really no sense in moving to any earlier build at this time, given dwindling support timeframes and the overall quality of the 1809 build and its post-release quality updates.
Pick a cadence. If you want to upgrade all of your machines every two years, you could try to get one fall release behind, and then upgrade after 18 months to the next fall release that’s behind by half a year. (After that you can upgrade every two years.) After you get up and running, you’ll always be installing fall releases in the spring, six months after they’re released.
Written out explicitly, the plan looks like this, with upgrades scheduled at the end of the support window for each build:
- Build 1809 is ready for deployment now and should be upgraded in Q1 2021 to build 2009.
- Build 2009 should be ready for deployment in spring 2021 and should be upgraded in Q1 2023 to build 2209.
- Build 2209 should be ready for deployment in spring 2023 and should be upgraded in Q1 2025 to build 2409.
For larger shops, you might want to consider staggering your cadence so perhaps half of your machines are in production at 1809 as of fall 2019 (that is, now). In the spring of 2020, half move to 1909 and half remain on 1809. Then in the spring of 2021, you’d upgrade your remaining 1809s to 2009, and in spring 2022, you’d move the 1909s to 2109, so on. In this cadence, you are upgrading something every year, but you’re only touching a fraction of your machines, so any problems will be on a smaller scale, and you’ll gain more experience with builds as you deploy them.
If you wanted this staggered cadence, then you could use the following guide:
Group One
- Whatever you have out there now should be upgraded in Q1 2020 to build 1909.
- Build 1909 should be ready for deployment in spring 2020 and should be upgraded in Q1 2022 to build 2109.
- Build 2109 should be ready for deployment in spring 2022 and should be upgraded in Q1 2024 to build 2309.
Group Two
- Build 1809 should be deployed now to all machines in this group and should be upgraded in Q1 2021 to build 2009.
- Build 2009 should be ready for deployment in spring 2021 and should be upgraded in Q1 2023 to build 2209.
- Build 2209 should be ready for deployment in spring 2023 and should be upgraded in Q1 2025 to build 2409.
Managing the Windows 10 deployment
Once you’ve chosen a channel, it’s time to manage the meat and potatoes of the migration: how to get the new bits onto machines. Most of us have imaging systems set up already, and they typically work just fine with Windows 10, so you would approach the initial migration — replacing Windows 7 and Windows 8.1 with Windows 10 code on the hard drive — using whatever imaging tool you like.
The next step is deciding what to do once you have initially put Windows 10 on your organization’s machines. Microsoft’s official guidance involves evaluating and deploying new SAC releases in three main phases:
- Plan and prepare, which mainly consists of deploying the Windows Insider test builds to a select group of test and development machines so you can keep an eye on what’s coming and do some initial compatibility testing.
- Targeted deploy, which consists of choosing a group of savvy users or machines in a variety of different configurations to receive the latest SAC you intend to deploy first, so that its use can be validated and issues documented before a wider release.
- Broadly deploy, which is the final stage after your “beta” users and your Insider testing has left you satisfied that a build will not introduce any foreseeable errors or issues in your organization.
Microsoft does not offer suggested timeframes for each of these phases, but I would suggest that you evaluate the Insider builds as often as you like — perhaps the Insider Slow Ring is most useful here, as the Insider Fast Ring tends to be full of bugs that generally get fixed before builds move on to the Slow Ring. (For more info on Microsoft’s Windows Insider program and its rings, see “How to choose the right Windows 10 release channel.”)
Then spend about a month to six weeks (not around holidays) in the targeted deployment phase. A month here lets your savvy users and your well-selected group of “crash-test dummies” really work through the SAC release and identify major issues that crop up.
But how do you configure that group of crash-test dummies? That’s where deployment groups come in.