A few days ago, we launched our brand-new Windows-as-a-Service (WaaS) Project Plan, a fully customizable template with nearly 700 action items to speedily and efficiently manage your Windows 10 upgrades. We have already walked you through the entire plan and shown you what to expect when downloading it. But if you have managed your initial Windows 10 migration using our project plan, you might wonder what is different and whether downloading this one is worth your time.
SPOILER ALERT: The short answer is, "Yes, it is definitely worth it to download the new one!" About 30% of the project plan is new or overhauled to accommodate the WaaS management component. Still, you can also reuse all the work you have previously done in the old project plan and combine them into one.
If you have used our Windows 10 Migration Project Plan before, you will notice some differences immediately. Today, I want to introduce some of the new functionality, highlight some of the changes we made, and explain how these updates will improve your service management.
[Download the WaaS Project Plan Here!]
One of the first differences you will notice right away is the distinction between one-off set-up tasks and repetitive (Evergreen IT) action items. The secret to successful Windows-as-a-Service management is creating a solid and stable project framework that allows you to not only run the same process repeatedly but also manage multiple Evergreen IT streams at the same time.
This first part, which encompasses about 300 action items, is doing exactly that: building your process framework. As in the original project plan, you will still find the planning and mobilization phase first — followed right away by the technology, process, and tooling design and build stage, which comes later on in the original plan.
We also added some additional tasks related to application inventory, packaging and testing, compatibility management, and workflow tools (see below).
Windows Analytics and its soon-to-be-released successor, Desktop Analytics, have gained a lot of traction recently as they supply a wealth of additional information that can be very useful in your upgrade cycles. We added them as another complimentary option for gathering inventory data in the assessment and rationalization phase.
Essentially, this gives you the option to decide whether to test the application packages or rely on telemetry to understand which apps are installed and how compatible they are. We have seen in the past that organizations that just use packages have issues, as that doesn't give you driver compatibility. But if you need that kind of information, Windows or Desktop Analytics can help you get it.
We are considering adding a step for enterprises that plan to use Microsoft Autopilot, but it still is not entirely clear if you can use it for standard in-place upgrades. Our current understanding is that Autopilot is better suited for wipe-and-load scenarios and new machine provisioning.
Speaking of hardware and drivers, we also added a new section that deals with driver and hardware assessment, which allows you to plan for creating a hardware compatibility list. This new section aims to gather all required information about compatible vs. incompatible desktops, laptops, virtual infrastructure, and peripherals before assessing them against a predefined set of rules. At the output, you will walk away with a list of clearly identified replacements and in-place upgrades.
Another section we have added to help with virtual client management as an upgrade to virtual clients is managed slightly differently from fat clients — especially if you are working with a non-persistent virtual environment. We added this section because many of our clients run hybrid environments, which can complicate things. You need to upgrade the image once and then deploy it to everyone. This can be quite a big change from what you are used to, as you now need to know which users will get the new image and which ones will not.
Another important new section we have added is the "Hand Over Into Service Delivery" phase in the "Operate" stage of the project plan. This section is important in order to get the new Windows 10 platform supported and your ticket routing set up correctly. Additionally, there is a small section around Windows 10 Version 1809 and Version 1909 readiness for service delivery.
Probably one of the biggest changes that we made is to redesign the deployment section to utilize the Windows 10 Deployment Rings. This approach is the Microsoft recommended way to run upgrades, but we have found some customers have struggled to translate the concept into actual action items. The project plan includes now concrete tasks on how you actually define your deployment rings and utilizes the concept throughout the deployment phase.
Because of the nature of the upgrade, we don't consider wipe-and-load a viable option anymore for Windows 10 Servicing, but your deployment will probably see a mix of in-place upgrades and replacements. This is reflected in the project plan by splitting the deployment into broad rings. Each ring will have several devices that will give us a percentage of application coverage. Once completed, we will move on to the next ring. All of this is, of course, capacity-constrained.
Historically, application compatibility has been one of the major roadblocks to IT transformation projects, such as an OS upgrade. However, since the Windows-as-a-Service upgrade process is centrally and much tighter managed than ever before, you will have to create a repeatable process that improves your application management hygiene every time.
This means categorizing your application estate into which applications are business critical versus which are non-critical and barely used apps. Here you will have to decide which type of testing you want to run for each application category (e.g., a full functionality test for business critical applications, or simply a smoke test that asks "Does it launch without errors?" for less critical apps). Also, you will need to determine if you will require a proper sign-off from different business units or divisions. Essentially, this adds a setting to your plan of defining which type of testing your applications need to go through.
Then, to determine ‘how’ you are going to manage the testing, you must answer questions like: Will you automate it using a tool like Access Capture, or will you manage this process manually? Are you automating the application test process end to end or are you initiating a business process each time?
Ultimately, the new project plan allows you to either build a repeatable process from scratch or turn your already existing project management plans into a repeatable process for each feature release. While the initial migration project plan had a larger section on tooling and process discovery and definition, this plan enables you to get your one-off set up tasks out of the way and focus on constantly improving your continuous management — always driving it towards maximum velocity using smart tooling and automation.