With Windows 7 rapidly approaching the end-of-support deadline, it’s time to get cracking on upgrading your organization to Windows 10. Use this planner to help ensure a successful migration.
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).
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 2003, 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); 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.
Creating and managing deployment groups
There are essentially two ways to manage deployment groups for this new “Windows as a Service” approach: by using System Center Configuration Manager, a tool that if you are in a large organization you probably already have working, or Microsoft Intune, the cloud-based device management service that is aimed at smaller shops that do not want to invest in System Center licenses. There’s a bit of a “hacky” way to control updating, too, which I’ll also cover.
System Center Configuration Manager
System Center Configuration Manager is a beast, and every deployment is different. Getting System Center up and running is well beyond the scope of this article, but happily, Microsoft has some great resources detailing how to configure Windows 10 update and deployment settings. Here are a couple that I suggest you take a look at if you are interested in using System Center to manage Windows 10 deployments:
Windows Intune
On the other hand, with a credit card and a couple of hours’ worth of work with Group Policy, Microsoft Intune can be a great way to test controlling your deployment groups. Intune farms out the Windows as a Service components to Windows Update for Business, or WUB, which is a bit like the next version of Windows Server Update Services.
WUB lets you set up a rollout strategy and set up channel selections and deferral timeouts for different groups of devices, called rings, to fully manage and stage a rollout of new releases of Windows 10. In addition, WUB can halt the rollout of new releases to any of these groups if your testing groups stumble upon compatibility issues in your environment, and you can also customize how the updating happens, including what hours the update takes place, whether it is silent and runs unattended, and whether reboots happen automatically or not.
First, sign into the Azure Intune portal. Navigate through More Services, Monitoring + Management, and down to Intune. From the Intune blade, choose Software Updates, and then choose Manage, and then click Windows 10 Update Rings. Next, click Create to start a new ring.
1. Enter a name and a description for the ring.
2. Choose Settings.
3. On the Settings screen, choose from the following selections and make your choices known:
- Servicing channel: Pick the channel for this ring.
- Microsoft updates: Choose whether this ring gets Microsoft updates as well as new releases.
- Windows drivers: Choose whether to include new device drivers for the components on the systems in this target group.
- Automatic update behavior: Pick how the systems in this group scan, download, and install updates.
- Quality update deferral period (days): Pick the number of days, up to 30, that quality updates are deferred after their initial release. These generally come out the first Tuesday of every month.
- Feature update deferral period (days): Pick the number of days, up to 180 (six months!), that feature updates are deferred for systems in this ring after their initial release.
4. Once the initial configuration is complete, then you can set up how long feature updates are deferred. Here, in a nutshell, is how this works. Take, for instance, the following scenario: You have chosen the Semi-Annual Channel and a deferral period of 60 days. If a feature update becomes publicly available on January 15, devices will not take part in the update until March, 60 days later. That is fairly straightforward.
However, if you picked the Semi-Annual Channel (NOT targeted) and the deferral period is 60 days, then if any given feature update is first available publicly via Windows Update as a Semi-Annual Channel (Targeted) in January, then three months later in March that same feature update “graduates” to the regular Semi-Annual Channel, and then your devices will receive the Feature Update in May, 60 days after that January release hit regular the SAC channel.
5. Also don’t forget to choose a delivery optimization choice. I’d recommend selecting HTTP Only, or 0, for the most security. The other options involve other devices on your network caching updates among peers for easier delivery, which strikes me as a potential security risk.
Once you are done, click OK. When the Create Update Ring screen comes back, click on the Create button.
The low-budget way: Windows Server Update Services
Feature upgrades in a typical corporate installation are delivered via Windows Server Update Services and not straight from Microsoft Update. That means the machines on your network talk to WSUS and can only be delivered updates that your individual installation of WSUS has in its repository.
Thus, since these machines depend on what your WSUS installation synchronizes from Microsoft Update, you could refuse to download the feature update through the WSUS administration console, and then that would eliminate the possibility that the machines that find their updates through your WSUS deployment would update to a new release — that is, until you allowed your WSUS deployment to synchronize any feature updates in question. This eliminates the granularity you get with establishing target groups to test updates and the official rings to deploy updates to, but it also is perhaps the simplest way to exercise absolute control over your update timelines.
It is fairly simple to enable and disable the updates. Use the Windows Server Update Services admin tool, which is typically found in the Start menu under Administrative Tools, and then once the MMC utility loads, on the left, expand Options, and then click Products and Classifications. Check and uncheck Windows 10 and Windows 10 LTSB in the Products tree as you see fit (check to synchronize and make the feature updates available; de-select the checkbox to make them unavailable) and then click OK. Once your selections are complete, click the Synchronizations node in the left-hand pane and then choose Synchronize Now, and WSUS will pull down the updates you need.
Application compatibility testing
One of the key tasks of orchestrating an overall migration to Windows 10 is making sure the applications you regularly use are compatible with the new build. Traditionally, this has been sort of a one-time deal, since, say, moving from XP to Windows 7 was a single deployment. But now that Windows 10 is continually serviced, admins must monitor compatibility considerably more than in the past.
The first step is to create a list of all of the applications in use in your organization, from the obvious candidates like Microsoft Office and SAP to the smallest utilities used on a remote workstation somewhere in a branch office. You’ll want to use some kind of software inventory system for this, like System Center; this is a great opportunity to actually create one if you don’t have one of these master lists for your organization. You should also include web applications, since Microsoft Edge is the default for users who get upgraded to Windows 10; Edge has some compatibility issues with certain pages that you will need to test to mitigate or eliminate.
Now, create a version of this list that is prioritized by how business critical the application is. I would suggest the criteria here be non-mainstream software sorted by the number of users, given that we can expect most off-the-shelf software to behave acceptably with Windows 10 at this point. It is the homegrown apps that may cause problems, and if you sort by the number of installed instances, you will approach the most-used applications and can tackle the testing that way.
Microsoft claims on its Servicing Strategy web page: “Only the most business critical applications should be tested before the pilot phase; everything else can be tested afterwards,” which seems very aggressive (and foolish) to me. Unless your employees like disruption, you should test popular homegrown applications ahead of a pilot phase as well, especially if they are heavily reliant on web pages or are older, making them more likely to rely on procedure calls and components that are no longer supported in Windows 10.
Then, you can use a combination of tools to really dig out the differences:
- Testing by hand, meaning taking your applications through use testing on your own or with a pilot group of users, typically in conjunction with your update rings and your pilot group. This is time-consuming but very effective.
- Upgrade Analytics, which is a surprisingly comprehensive set of automated tests available to you if you subscribe to the optional Microsoft Operations Management Suite (OMS). This works by analyzing an executable’s code and looking for “hot spots,” common markers of procedures and API calls that won’t work with Windows 10’s new security models.
User training
There will be a fair amount of complaints from users regarding “moved cheese” with Windows 10, but Microsoft smartly provides a great deal of information for IT, including how to communicate about your migration and servicing, and also print-ready end-user guides to connecting printers, how to use the desktop, how to use AutoVPN to tunnel into an organization, and more. You can find all of those materials on Microsoft’s “Windows 10 end user readiness” site.
And don’t forget Computerworld’s own “Windows 10 cheat sheet,” a guide for users that covers the interface, features and shortcuts in Windows 10. Finally, our article “5 ways to make Windows 10 act like Windows 7” has some tips for configuring Windows 10 so it seems a little more familiar to Windows 7 users.
The last word
Migrating to Windows 10 is an event. Between making sure your applications are compatible, getting the right release choices, understanding the support lifecycle, controlling Windows as a Service from this point forward, and educating your users, your migration will be a lot of work. Hopefully, it pays off for your business.
This article originally appeared on ComputerWorld.