Did you know that most organizations run on devices that are between two to four years old — making them a prime candidate for a complete (or partial) hardware refresh initiative on the back of their Windows 10 rollout?
In fact, 31% of all enterprises asked as part of a recent 1E study are planning to rely on swapping out old hardware to migrate to Windows 10. Another 36% of companies plan to combine in-place upgrades and hardware refreshes, while the remaining 33% will do an in-place upgrade. In the large enterprise space, many are looking at a combination of hardware refresh and wipe and load to achieve their rollout plans.
Many big companies are combining their Windows 10 migration (migrating from Windows 7 or earlier to the new operating system) with a hardware refresh (buying new laptops or PCs that come with your image or are imaged on-site). But is it easier to migrate to Microsoft's latest operating system through your Business as Usual (BAU) hardware refresh plans than to manage a big bang rollout? Many IT project managers are asking themselves the same question.
This method is certainly a valid one, but what are the underlying implications? Will it really be easier because you won't need a project? What are the consequences of this approach? Today, we will explore the answers to these questions in more detail as we go through the most common upgrade scenarios and point out some important "gotchas" that go with managing migration as BAU.
In general, Microsoft recommends for all PCs running on Windows 7, Windows 8 or Windows 8.1 to perform an in-place upgrade using the Windows 10 installation program. According to the software giant, this choice automatically preserves most applications, drivers, and settings from the existing operating system and therefore requires the least IT effort per PC. Microsoft deems to be extremely reliable as you can quickly roll back the operating system using the recovery information automatically created during the upgrade process. This alternative is faster than other choices because most applications do not need to be reinstalled.
Unfortunately, many corporations will find that this method may not work with their custom build images because the installation process cannot deal with application version issues, changes to the infrastructure, or user profile migration. Even if the IT team updates the company image or creates a new Windows 10 image, the installation process will not use it.
You should also be aware that you cannot use the in-place upgrade method to change from a 32-bit to a 64-bit version of Windows, or to change from legacy BIOS to UEFI booting without an appropriate process like an SCCM task sequence to manage the job. Windows 10 operates fine with legacy BIOS booting, but it precludes the use of some new features such as Secure Boot if you are not able to switch it on during the upgrade process. Further, the use of third party encryption tools is not supported — with the exception of BitLocker. This is the main reason why many enterprises would consider a wipe and load approach instead of an in-place upgrade.
For most smaller organizations, the in-place upgrade option is the fastest way to get to Windows 10. They are more likely to accept the risks of application issues after the update. However, for large enterprises, the in-place upgrade requires as much planning as any other migration type. There is a dependency chain of application readiness, hardware readiness (e.g. enough free disk space), infrastructure readiness (e.g. SCCM upgrades) and other items that can block a successful update. So while the technical process is, in theory, simpler, the practical part of managing and scheduling the deployment remains as complicated as ever.
If the in-place upgrade is not an option, the preferred route is typically to either rebuild the device from scratch, or to replace it with a new piece of hardware. Both of these approaches are similar in terms of the methodology required to support the migration to Windows 10.
Most large organizations use a custom image for Windows 10 because they need a specific set of security and compliance settings, supporting applications and corporate branding. It is against this image that applications are tested, validated and packaged for the new OS if required. User profiles and data, often managed through third party tools are retained and updated to work on the new OS at rollout time. The build will also often only contain the necessary elements specific to the organization, removing any bloatware and drivers that are known not to be required. This reduces image size and complexity. However, simply creating a suitable build image is usually just the first step.
If there is a need to migrate user data from an old machine, then the refresh process needs to include the backup and restoration of the existing data and settings. The process also needs to layer on the applications that the user will require to perform their job role. These should be both layered on at build time, but also provisioned within the standard environment so that any future break-fix rebuild work will retain the correct applications for the user.
There is also a question of project management. While it sounds exciting to procure thousands of new devices that utilize latest technology, have a much greater battery life, and other technological advances that hopefully require less support and maintenance, the question is how will you manage the readiness and scheduling of the device rollout? It starts by getting an exact picture of your IT estate to determine which users qualify for a new device as part of this refresh initiative, and ends with automated user sign-off when the user logs in to the new laptop running Windows 10 to ensure all applications run as they should.
What Are The Consequences Of A BAU Hardware Refresh Approach?
For most companies, IT project Managers will find a mixture of device ages as they embark on their Windows 10 migration. Some will be in their depreciation cycle, and other assets will be on their 'sweat' period. In this instance, a combination of hardware refresh and in-place upgrade or wipe and load may seem like the obvious solution. The newly purchased hardware can be imaged at factory or on-site, and the user’s settings and data can be applied using the techniques described above in the hardware refresh section. Hardware that isn’t yet due for replacement can be left in place or upgraded as resources allow.
Many corporations consider this to be the ideal upgrade path since it theoretically minimizes IT efforts. It is also perceived as a budget-friendly alternative to big bang overhauls as this approach does not unnaturally accelerate hardware replacement or creates additional work that wasn't already planned. However, the perception that this method requires fewer overall resources may be significantly flawed.
When the company has a mix of different hardware running Windows 10 and older versions of the operating system, your IT team will have to maintain a state of coexistence for much longer than you would when utilizing the 'big bang' project approach. Now you have to test all your existing applications (and any new applications) for every operating system version that you are running — as well as the different Windows 10 branches your devices might be on.
In addition to the added complexity, timing is another issue: An average Windows 10 migration can take more than 24 months, but a hardware refresh driven upgrade will probably take much longer. Remember that a three year refresh cycle would see six new Windows 10 feature releases, multiple SCCM mandatory upgrades and potentially now, even some mandatory Office upgrades!
For companies managing upgrade in BAU, the coexistence issue just got very large. There could easily be four or five supported release versions. A consequence of having devices on multiple different releases running the same applications is that the application testing overhead increases exponentially, and support issues become much more complex to diagnose and fix.
To summarize, here are the main pros and cons of Big Bang vs. BAU Hardware Refresh Windows 10 migration approach.
| Big Bang Project | Hardware Refresh (BAU) | |
| Pros |
|
|
| Cons |
|
|
No matter which migration approach you choose, you will do well to plan your entire migration project from beginning to end. Consider how you will manage the countless interdependencies between users, devices, applications, locations, and departments.
Most organizations underestimate the complexities and the sheer workload of this massive project because doing a single in-place upgrade sounds so easy or a hardware refresh so logical. However, this can be far from the truth. It is only after the executive management gets nervous after seeing hardly any progress after six months (e.g., because applications are not ready for the purchased hardware), that the full scope of the project becomes apparent.
And the proliferation of operating system versions and possibly branches only amplifies the complexity of the IT landscape and further complicates security, compliance, and support. The result may be an even heavier demand on resources. The massive demand will continue over a longer time than if the company had only chosen to upgrade or refresh all systems at one time.
Since rolling out Windows 10 will be different than any other OS rollout you have ever done and result in mini-migrations every six months, it is advisable to set up your project management in an easily repeatable fashion (e.g., automatically assigning your user base to deployment rings that best fit their characteristics) so that most of the workload is completed by the time you have to upgrade to the next branch version.
Sources: