The title is one of the biggest questions enterprises face when deciding on a Windows 10 migration and/or upgrade approach for their estate. In other words, how will they determine when to migrate whom?
Generally, there are two ways you could do this:
- Assign everyone a migration date and work towards that date (we call this approach right-to-left), or
- You dynamically calculate the best candidates and provide migration dates accordingly (we refer to this as left-to-right).
While both ways have their pros and cons, one is definitely better suited for today's fast-paced changes and to manage Evergreen IT. Let's take a closer look.
The Traditional Right-To-Left Migration Approach
Traditionally, during big bang IT Transformation projects that lasted three to five years, it was easier to divide your in-scope end user base by location, building, or department. This way every user was given a specific migration target date at the very beginning of the process and capacity plans built around an assumption of assets being ready to migrate in time to hit that date. At this point in time, the users are nowhere in the readiness process yet, e.g., no application readiness has been done yet, and you have no idea how much activity is required to get to that point.
Essentially, you build this massive roll out plan (think Gantt-Chart and Waterfall method in terms of project plan) but because you have to base everything on assumptions, the plan is unrealistic from the start. It would only take a couple of things to slip and the migration date has to move. But now the clock is ticking and IT needs to figure out how they can work up to that scheduled date by getting everything ready.
While this approach always ends up in a scramble to get everything done and almost always causes schedule delays, IT managers often feel more comfortable with this method, as this is what they have always done and it gives them the feeling of having control.
The New Left-To-Right Upgrade Approach
In contrast to that, the left-to-right approach onboards all in-scope users and devices without a set migration date. While there are certain capacity restraints, as well as deployment ring criteria (e.g., a small number of users will always be upgraded early in the Preview Ring or last because they are VIPs) that must be taken into consideration, upgrade dates are provided as obstacles are cleared — or, as we say at Juriba, "as things turn green". Rather than a rigid workflow towards a set date, this process is more of an automated workflow. You don't actually know when any of these assets are going to get scheduled until they're at the final stage of the process. That's why we call it left-to-right.
Now, with the new recommended Windows-as-a-Service deployment ring concept, you have an opportunity to manage the vast majority of your estate dynamically. While you still would have to upgrade people within certain rings together (e.g., Preview Ring users get migrated before Broad Deployment Ring users), when these users get migrated depends on their readiness status rather than an artificially set date.
The difference is that you are managing by volume. You get as much ready as you can because you are prioritizing the things that mathematically give you the biggest bang for the buck. As a result, you are automating the workflow. You start the process knowing that a lot of things will change within the project. Once all user and device upgrade milestones have been met (are set to green), you move to the next phase automatically — under a capacity constraint.
As a result, you keep going after the easiest wins all of the time, which is the best way to achieve velocity. You drive the activities based on prioritization and readiness, and the only thing holding you back is your team's capacity in terms of support bandwidth, service desk capacity, and possibly network bandwidth.
Almost all IT Transformation projects I have seen over the last years were managed right-to-left. Project managers are simply more comfortable with Excel Sheets or MS Project-generated Gantt-Charts and project plans.
(That's why our Evergreen IT Project Plan Template is using this format, yet it lays out a dynamically managed process. I very much encourage you to download it and have a closer look through the steps to get a detailed understanding of how some of our most successful customers are driving maximum velocity upgrades in a matter of months rather than years.)
The problem with this is that it is almost inevitable that your deadlines slip. By planning on assumptions and working towards artificially set dates without taking velocity-fueling changes into account, you will always take longer and end up with a heavier workload compared to an iterative, more agile left-to-right approach.
Admittedly, this move does not happen overnight. It does take a huge internal culture shift to make this happen successfully — but the benefits to your organization would be enormous. I strongly encourage you to learn more about Evergreen IT and how it fits into your long-term IT strategy, understand how you can manage your deployments in an agile manner, and how Dashworks can help.