What’s the W10 situation?
We've calculated that we only have about 400 working days remaining for W7 support.
The year 2020 was once far away, but now in the spring of 2018, it’s hurtling towards us. As a Project Manager, in my mind 2018 is already over; it’s essentially June right now, we have the summer starting soon with vacations, and no one works in August, and then it will be Thanksgiving and Christmas where nothing happens. So it’s basically 2019 already, meaning we don’t have much time left.
Everyone all realizes as well that automation is essential. Customers need the ability to do a mass migration in order to meet deadlines and save money. Any company with more than 100 machines and more than 1 location, it becomes counterproductive to serve machines individually.
In summary, we know we need it automate and we need to make the migration quick. It's time Get 'er Done.
The Question: How fast can we go?
The logical question from customers planning for their W10 migration, and it's a good one, is 'How many OS migrations can we do each day?’. Basically how fast can we go? As a project manager, you want to tell the business the schedule of the migration from start to finish and the speed. It’s much better to be prepared with a schedule rather than have nothing ready and summarily get assigned an end date (which probably will happen anyway).
So in essence, the question is “What can or what should be our migration velocity?” We will measure this in Migrations Per Day, MPD.
The answer, of course, is what no one wants to hear–it depends!
This drives project managers crazy as it makes it impossible to plan a migration, but MPD does actually depend on a lot of factors. Company complexion, strategic direction, office locations, user makeup, apps, aggressiveness, and more will dictate migration speed. Even Acts of God will impact the speed. Customers in the northeast US doing migrations in the winter will get impacts of snow and blizzards that will shut down offices for several days a year where you can’t do the migration for days at a time.
But we are not going to give this answer ‘IT DEPENDS’ here. We are going to go out on a limb and provide some numbers.
What does velocity look like?
What do we mean by speed / velocity or what should velocity look like? From experience during the XP -> 7 days and for customers in W10 migration right now, this seems to be a healthy deployment speed profile.
If we break this into 3 phases, the beginning of the migration process will slowly build up after doing pilots and working out the kinks to harden the solution.
The migration will reach some speed during the height of migration. It's in this velocity arc that will carry on until the virtual end of the project where we declare project complete. Even within the velocity arc phase, you’ll have some peaks and troughs. The end of the migration will have a long tail of machines that are special, difficult, unique or white glove. It’s the middle where we want to take off and reach high speeds because we have a lot of machines that are reasonably similar, available, co-located, etc., and the OSD solution is battle ready.
This is the number we are talking about for MPD.
Give me a number
We think a good number to aim for when reaching that velocity arc is 2% of the number of machines in the environment migrated each day. Some customers will be higher, some lower, but 2% might be a good target for which to strive.
To save from doing the math, here is what that means by estate size:
We have been involved in a lot of migrations during the XP -> 7 days with various speeds, ranging up to 30k machines a month which is essentially 1500 – 1800 machines a day. For the W10 migration, customers are reporting velocity from 100 machines per day to 20k per day. To date, we are seeing speeds in the neighborhood of 1 – 5% of machines per day. From our poll, customers are you trying to sustain velocities. With 2% does this mean you'll be completed with the migration in 50 days? Perhaps. For this discussion, it’s more of a measure of velocity goals.
Why 2%: Factors
Where does 2% come from? Here is everyone's favorite IT triad: people, process, technology. These are factors in pretty much any IT project we do.
The base assertion is that migration technologies such as 1E Windows Servicing Suite (WSS) have no theoretical limits and can support very high daily deployment velocities. In theory, using the tech, the speed of electrons and bits is the limiting factor. If a customer has 50,000 vanilla machines in a warehouse they can be migrated all at once without a problem. Instead, the 2 other factors around people and process are going to limit how fast we can go.
Why 2%: People and Process
When talking Process, one of the main factor related to speed is going to be the migration Failure Rate, meaning when we do our automated migration to W10, how many of these machines are going to fail and require heavy touch to remediate.
As we’ve illustrated in the past blogs and we know from experience, there are going to be inherent environmental hurdles that will present themselves during the migration. These are the known unknowns and the unknown unknowns. Things are going to go wrong that can’t be anticipated. A user will for no good reason turn off their machine while the TS is running–it’s going to happen!
As a result, a number of migrations will not succeed, but the question is at what percentage.
Note: I’m positioning failures as a Process item, not a tech item which may be considered at first blush. Yes some tech is involved but as mentioned, the migration tech is not going to limit the velocity, this is more on a process.
On the PEOPLE side, as a result of this failure rate, the thought is that we’ll need field techs available to remediate failures so that users aren’t left w/o a working machine. The assumption here is the business can’t go a day w/ a user not having a machine, it’s too much productivity loss and ultimately too much money lost. We need these machines remediated as quickly as possible via a human. The question becomes, how many field techs do we need as part of the project to visit these failures and migrate via a manual process
