Almost every organization is scrambling right now to get employees set up to work from home — bringing many Windows 10 migration projects temporarily to a halt. While the current pandemic might possibly result in support deadline extensions from Microsoft down the road, it is important to be aware of an emerging problem that almost every company will encounter: what happens when your migration is over?
Many organizations who have completed their migration have encountered the very common pitfall of the chaos created when the migration project team passes the reins to the Business-as-Usual (BAU) team who is expected to proceed as always.
But now, in addition to their normal day-to-day jobs, they are also responsible for upgrading Windows 10 (and possibly Office 365 ProPlus, hardware, SCCM, Windows 10 servers, and much more). Most face this new challenge with no additional budget and resources!
It is important to be aware of this as soon as possible to not cause further delays and additional chaos for your already stretched thin IT team. Today, I want to take a closer look at the problem and go through some ways you can minimize the damage right now.
Be Aware Of Potential Problems & Manage Expectations
Generally, when you are running large IT Transformation initiatives, you aim to migrate at least 80 percent of your users. But for asset or licensing migration with the Windows Operating System, you tighten this 80/20 rule from a general project management perspective to only have 5% of users (or less) left to conclude.
Because these last 5% are your really tricky users (e.g., an application is waiting to still be remediated, a new version for the application is coming, or there are some hardware issues like a peripheral card that is not supported on a newer version of the operating system), this can often can take as long as the previous 25% to 30%. This overflow is difficult, but to be expected.
In addition to migrating those stragglers, BAU teams now have to create scalable and repeatable Evergreen IT processes that are required to upgrade Windows-as-a-Service in an ongoing manner. Oftentimes, this means they have to clean up a huge mess first, e.g., put the right processes, policies, and protocols in place, centralize application and project management, and much more.
This issue is often exacerbated by wrong expectations on the management level. At the handover, BAU is often expected to jump into action and keep the machine running smoothly. Usually, these initial clean-up and set-up efforts are completely ignored or falsely minimized.
Integrate Your Teams As Quickly As Possible
By having a migration team and a BAU team, a massive amount of institutional knowledge is lost at the handover, resulting in wasted time spent reinventing the wheel, relearning processes, and walking into avoidable pitfalls. The BAU team, while often involved in the process, is shielded from the behind-the-scenes chaotic reality of every day migrations.
Having a program team around feels almost like having a massive comfort blanket. For example, some odds and ends projects get diverted to the program team because of their sheer volume of resources and available manpower. This loss is often keenly felt as well.
Some organizations might choose to have a very agile team that would take over the Windows-as-a-Service role, making sure everything is in tip-top shape, whether it is an asset, VDI, data center, or virtual machine refresh. This team would also keep the OS build up-to-date, verified, and tested through the QA teams before releasing it in a small pilot and then across the entire organization until they have mopped up the remaining users.
Once all users are migrated, they keep that cycle going to make sure apps (or at least the real high risk or money making apps) are retested across the different platforms. This might be just a small team that does this consistently.
Of course, this requires a dedicated project budget with each upgrade wave being treated as a mini-project. The nice thing about these repeatable processes is that the budget needs can be forecast very easily as they are predictable.
Have A Dedicated BAU Team & Budget
My recommendation is that most larger organizations should have a dedicated Windows-as-a-Service team, whether as a managed service or a dedicated permanent staff, in order to manage this process as efficiently as possible. This includes not only the desktops and applications, but also your desktop management platform (e.g., your SCCM) and other infrastructure.
The same team is also looking after keeping everyone on the right or latest version and the right patch, making sure certain VBA runtimes are eliminated by development, everything is standardized on certain versions of PowerShell/.NET, and much more.
As an alternative to a dedicated team, an organization could also decide to split a few resources between operational management, engineering management, and support as they go hand in hand. The third option could be to keep your current support groups managing the process, but they would carry the very heavy burden of the migration and the repeat change after.
In summary, to avoid massive slowdowns and bottlenecks, be sure to:
- Manage expectations now while you are still undergoing the initial migration,
- Plan to set up repeatable, scalable, and automated processes wherever possible,
- Integrate your BAU team early on into the migration process and let them be part of it without shielding them,
- Retain some of the project team and incorporate them into the BAU team — before they lose their job and all their knowledge goes away, and
- Create a dedicated team and budget to manage your Evergreen IT.
I hope this helps to smooth your transition into Evergreen IT Management. Please feel free to post any questions below and I will answer them as best as I can.
