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 already walked you through the entire plan and showed 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 as well 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, but you can also reuse all the work you have previously done in the old project plan and simply combine them into one.
How This New Project Plan Differs From The Original Windows 10 Migration Project Plan
If you have used our Windows 10 Migration Project Plan before, you will right away notice some differences. Today, I want to introduce some of the new functionality, highlight some of the changes we made, and explain how these updates are going to improve your service management.
1) Distinction Between One-Time Vs. Repeatable Tasks
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 around application inventory, packaging and testing, and compatibility management, as well as workflow tools (see below).
2) Add-in For Windows Analytics / Desktop Analytics And Possible Microsoft Autopilot
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 in as another complimentary option for inventory data gathering in the assessment and rationalization phase.
Essentially, this gives you an option to decide whether you are going to test the application packages or whether you want rely on telemetry to understand which apps are installed and how compatible they are. We have seen in the past that there are issues when organizations just use packages, as that doesn't give you the driver compatibility. But if you need that kind of information, Windows or Desktop Analytics can help you get that.
We are considering adding in 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 understanding right now is that Autopilot is better suited for wipe-and-load scenarios and new machine provisioning.
3) New Sections: Driver & Hardware Assessment, Virtual Client Management
Speaking of hardware and drivers — we also added in 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 around 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 replace 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 to fat clients — especially if you are working with a non-persistent virtual environment. We added this section because many of our clients are running hybrid environments which can complicate things. You would 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 are going to get the new image and which ones are 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.
4) Windows 10 Deployment Rings Concept
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 really consider a wipe-and-load an option anymore for Windows 10 Servicing, but your deployment probably will see a mix of in-place upgrade and replacements. This is reflected in the project plan by splitting the deployment into broad rings. Each ring will have a number of 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.
5) Continuous Application Packaging & Testing
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.