This post is part of the "Definitive Guide To Windows 10 Servicing" blog series.
Recently, I had two very different conversations that really struck a chord with me.
The first was with an IT guy from a local firm looking to migrate a couple of thousand users to Windows 10. Even though he could have pulled off a successful migration with a set of spreadsheets and some elbow grease, he wasn't going to risk anything. He was eager to implement our migration project management tool, Dashworks, because he wanted a platform that was going to guarantee him a successful project.
A short while later, I spoke to a young, gung-ho enterprise IT project manager who was tasked to migrate over 80,000 users in a well-known enterprise. He was convinced that he would be "just fine" if he just rewrote the system he had previously used for Windows 7 and hand-cranked a bunch of databases, spreadsheets and sharepoint sites.
Having been part of these kinds of projects for more than a decade, I know which of the two guys sleeps well at night.
A Dangerous Migration Myth Causes Many To Struggle
Why am I telling you this? Well, over the past 12 months, we have seen a dangerous trend of larger organizations planning on "winging" their Windows 10 migration — either as part of a hardware refresh as part of Business-as-Usual or by using a complete Do-it-Yourself approach (a.k.a. self-written tool) — without dedicated resources, budget, or proper project governance.
And, honestly, this move, as detrimental as it may be, is understandable.
Microsoft's marketing material and some of their handpicked customer success stories paint a picture of an easy, go-with-the-flow migration that won't need much application testing and uses self-service to speed things up. And if you have a tight handle on your application portfolio while migrating a tech-savvy and enthusiastic user base that cannot wait to go onto the next OS version, that might actually be the case.
But for most mainstream organizations, this path might become a treacherous dead-end street.
If going rogue isn't such a great idea, you might wonder why this is such a popular approach. The problem is that many IT project managers who are tasked to spearhead their organization's Windows 10 rollout have not actually done this before. And if you haven't gone through this, you might be blissfully unaware of what you might be in for.
What If You Fail?
While we have approached this subject many times from a positive angle, for example by highlighting how to plan an enterprise desktop migration project from beginning to end, or by revealing what the key criteria for success for an IT project manager are, we haven't looked at the flip side of things yet: What if it all goes wrong? What happens to you and your team if this migration fails? And what are the early warning signs of failure that you should be looking out for?
Unlike other IT projects, a Windows 10 migration (and subsequent branch updates) are not all that cut and dried because failing is not an option. You cannot simply declare defeat, walk away and try something else. One way or another, your organization must upgrade to the new OS. But that doesn't mean that your project can't (or won't) fail.
Today, we will look at the four most common scenarios that would constitute a failed Windows 10 project. While there are many other ways to get stuck, stall progress, or become overwhelmingly inefficient, these are some of the dead-end streets that we see failed projects end up in.
So, when you are ready, ask yourself: Am I willing to:
Prepare To Fail Because I Failed To Prepare?
I know that sounds harsh, but unfortunately, the phrase "failing to prepare is preparing to fail" rings very true for any type of complex IT Transformation project, especially a desktop migration project like a Windows 10 migration.
One of the most common ways that enterprises set themselves up to fail is also one of the most certain to backfire: undergoing a Windows 10 migration without a proper project and, therefore, without adequately trained and skilled resources, a dedicated budget, and the right tooling.
Without proper project definition, planning, and management, you will most likely not dedicate sufficient time to "plan for the plan" — e.g., identify and agree on key objectives and a project start and end date, gain buy-in from all relevant stakeholders, or set guardrails for resource and budget needs. This leaves an unspecified project with unspecified timelines. Never a good place to be.
Also, since the new OS is Windows-as-a-Service, you need to prepare for a mini-migration project at least every 6-12 months after the initial migration to stay up-to-date with the latest versions. Therefore, you will want to create a repeatable and scalable project process that you ramp up and down quickly and automate most of the migration tasks down the road.
Consequently, the lack of adequate planning and strategy will result in inefficiencies while increasing your risks and costs significantly. As the project stalls due to a number of bottlenecks and dependencies, desperate project managers usually have two choices: throw more people at the problem, which will just increase inefficiencies, or switch directions completely, which can be very disruptive and risky.
In this scenario, management might decide to outsource the entire migration to a service provider and/or replace the responsible IT project manager and parts of the migration project team, effectively putting the initiative back to square one.
Completely Lose Control Of The Project?
It is really hard to determine when you actually have completely lost control of your project, but I would say a good indication that you are in trouble is if you are six months into it and you still have yet to get numbers on the board. However, that isn't always the case. Sometimes, a migration starts off fast, but stalls indefinitely once you have gotten past the first bunch of low-hanging fruit.
Lost control is often caused by a tangle of bottlenecks and scheduling spiderwebs resulting from disorganization. Once you are in the middle of it, it is pretty much impossible to untangle.
For example, what do you do if you have x number of users scheduled for migration next Tuesday, but their laptop shipments are delayed for another four weeks. You will probably push them out for another four weeks. But your migration isn't one-dimensional either. Once the laptops have been shipped and received, you find out that certain apps have proven to be incompatible and have to be repackaged, retested, and recertified before these users can be migrated. In addition, some of the users are out-of-office, have moved departments, or have left your organization.
These are just a few very likely bottlenecks that you will encounter. How do you update your rescheduled migration dates? How will this rescheduling impact the rest of your migration timeline? How do you even start to plan for capacity in this chaos? It's impossible. You have lost control of your project, which means you are running late or stall completely, go over budget (if you even have one), and have to explain the situation to angry executive management, business unit managers, and other key stakeholders.
Cause Massive Business Disruption Due To App Compatibility Or Hardware Issues?
If the average enterprise desktop migration project touches 1,500 applications, you can imagine that testing for application compatibility is no small feat. However, with Windows 10, we are told we can wing it. We can only test a few critical ones that are relevant to this particular Windows 10 version. But how do you know which ones to test?
And given the scenario above, confidence on application compatibility will become a huge issue. You will have to have an efficient application testing process in place that will ensure that everything is working as it should — or you risk causing massive business disruption! Imagine the first trading floor application that breaks because you didn't bother to test it properly!
This is a perfect example of what I am talking about: When asked, "Do you think businesses should start large-scale Windows 10 deployments this year?" as part of the TechRepublic CIO Panel, Lance Taylor-Warren, CIO at HAWC Community Health Centers said:
While we have rolled out about 10 percent of our workstations with Windows 10, we have run into issues with the issue of drivers from some of our vendors not being compatible with Windows 10 yet, so it prevents us from making the large scale push. Performance of Windows 10 on some of our older hardware is also proving to be a bit of a challenge."
A stalled project does not only cause chaos in your team, but in the entire organization. As you know, end users are often wary of having their device upgraded in fear that something that worked before isn't going to work as expected after the migration. And this fear is completely justified — especially if you go with a DIY approach in which you test apps for compatibility only once something breaks. Can you afford to have hundreds or even thousands of users not have access to a specific application or be able to send or receive emails for even a day?
Maintain A State Of Complicated And Costly Coexistence?
We have talked to hundreds of IT pros in the past 12 months and most underestimated the time it will take them to complete this process simply because they skip or skim over the planning phase. They think, "If we just do this upgrade as part of our planned hardware refresh, we don't even need dedicated resources, budget, or project. The migration will basically just happen as we replace everyone's hardware." And theoretically, that is true — for small companies and home PCs. But it is a little more complicated for larger organizations.
Let's assume an enterprise plans to roll out Windows 10 by business units in a BAU hardware refresh cycle. Now, if all business units upgrade as they see fit, some might start the migration earlier than others, as they have leftover budget or see a stronger pull from their users.
Realistically, an upgrade project like this will take you about three years if you stick to your asset depreciation or lease cycle. This, however, has dire consequences: If you take longer than 24 months, you will have to consider at least 4 OS updates and potentially even more SCCM releases! Many forget that the organization will need to upgrade some devices before the new OS is completely deployed.
In other words, you could end up with hardware of various ages running two to three Windows 10 versions (assuming you skip every second one), with two or three different branches (Windows Insider Preview, Current Branch, and Current Branch for Business), and four to five deployment rings.
How will you be able to maintain these multiple states of coexistence? For example, how will you ensure that all of your applications are tested for compatibility in the various states? How will your IT help desk staff support users on all these different application versions?
Conclusion
This was a difficult article to write as this is a scary subject that hasn't really been touched by anyone else before. I did not want to monger baseless fear, but I feel strongly that — after having had many conversations like the one I mentioned in the beginning — the topic had to be broached.
While coupling a Windows 10 migration with a hardware refresh or just "winging it" without proper tooling, resources, and budget might seem like a good idea now because of potential cost savings and project synergies, it is a risky proposition. For most larger organizations, this spells disaster as you have to deal with hundreds of dependencies, bottlenecks, and setbacks simultaneously while trying to move forward as fast and as efficiently as you can. So before going it alone, consider the consequences of what happens if you do fail.
