Sponsored by Liquidware
Many things have changed in the IT world over the 32 years (wow! That’s a long time) since Microsoft shipped Windows 1.0. One thing that has not changed is that desktop migrations and upgrades are still complicated and painful—perhaps more so now than ever. If you ask users what they want from a migration, they’ll tell you they want the smoothest possible transition with little downtime, plus a familiar desktop experience. (Some of them will tell you they don’t want to migrate at all, but you can probably ignore them.)
Why migrate?
There are many reasons to migrate at the desktop level. The two biggest are security and operating cost. Microsoft has steadily improved the security of its desktop operating systems; it’s a little horrifying to look back and see the list of security technologies we didn’t have access to in older versions. As security threats grow and evolve, Microsoft has been forced to keep up by adding features such as early-launch anti-malware (ELAM) and controlled folder access (a superb way to protect against ransomware, and perhaps a good reason to consider migration all by itself). Security is a particularly large issue for organizations that are still on Windows 7 (or even Windows XP), as the security landscape has changed significantly since then and the improvements in Windows 10 now represent the entry level inadequate security in some ways.
Operating cost is another large factor; desktop migrations are often tied to hardware and Microsoft Office update cycles, and so a growing number of organizations are seriously examining the use of virtualized desktops to break the dependency between hardware and desktop OS updates. Even for organizations that want to stay on physical desktop hardware, the potential cost savings from current-generation Windows running on modern hardware can be compelling.
The migration process
Figure 1 shows a simple schematic of the major phases of the migration process. There are many different schools of thought on how to conduct each of these phases; entire books have been written about just how to run pilot IT projects, for example. We can quickly summarize each of these phases from the desktop migration perspective, though.
Environmental inventory
Some organizations have robust inventory and management systems that can answer questions such as “how many actively used desktops are running Windows 8.1 service pack 2?” or “how many Dell XPS 13 laptops do I have?” Management systems such as System Center Configuration Manager (SCCM) or Microsoft Intune can be used to conduct inventory operations if you can afford them and have them deployed. If not, you may have to resort to less effective methods such as asking users to self-report, writing an inventory tool and pushing it via group policy, or manually inventorying systems and their configuration. The key requirement for this phase is that you have an accurate model of what systems exist so you can properly plan the desired state.
Desired-state planning
“Desired-state planning” is a fancy term for deciding what you want your future environment to look like. More than that, this phase encompasses creating a road map to help you get there. A desired-state plan for a desktop migration should include information about:
- What you’re migrating from (that’s why you need the environmental inventory)
- What you’re migrating to. This needs to include answers to a large number of questions such as: what version of Windows are you moving to? Are you staying on physical desktops, moving to an on-premises virtualized desktop environment, or moving desktops to the cloud? How will the target environment be configured? How will you handle migration failures or systems that cannot be migrated for business reasons?
- Your schedule. Most organizations have to perform desktop migrations over time, not in one giant spasm. Which users will you migrate when? What does the overall schedule look like, and is it affected by external events (such as the start of the school year, the end of the fiscal year, or the holiday shopping season?)
- Your business. Are you migrating in order to meet specific business requirements? Perhaps there are line-of-business applications that must also be migrated, or specific regulatory or compliance requirements that the new environment has to meet.
The goal of this phase is specifically to help you understand what the finished environment must be capable of doing, and how you’ll get from where you are now to where you want to be. You can almost never spend too much time, or provide too much detail, in this phase to ensure that you get it right—the old adage “measure twice, cut once” is completely applicable. This phase doesn’t usually require you to do anything to the environment.
Buildout
The buildout phase is easy to describe: it’s when you start building the environment you designed in the desired-state planning phase. Think of building a house: you start with an empty patch of land, prepare the soil, pour the slab, and then start building the house. There’s a certain minimum amount of work that has to be done before you can move in, but you can live in a house that isn’t completely finished. The same standard applies here: before you can conduct a pilot, at least some of your new environment will have to be designed, built, and tested. For example, in-house VDI deployments will require you to build out an appropriately-sized hypervisor environment, get the right licenses, and so on before you can migrate even one pilot desktop—but you don’t have to have the entire desired-state environment completely built. This phase is often scheduled so that different components of the environment roll out according to when the migration is actually taking place.
One of the nice things about the buildout phase is that it’s a good place to stash extra schedule padding. That’s because, depending on the nature of your migration, you can usually sneak a small number of pilot users (including yourself, of course) onto the new platform fairly early in this phase. That gives you a chance to proactively monitor the environment and fix any problems that arise, plus you can experiment with tools and configurations that you want to evaluate before committing pilot users to them.
The buildout phase is also the right place to remediate any problems in your existing environment that must be fixed before deployment begins.
Pilot
During development of new aircraft or missiles, engineers schedule a very large number of test flights. Each test flight has a very specific objective, which may be simple (verify that the landing gear goes up and down at various speeds) or complex ( 2-vs-2 basic fighter maneuvering). The test pilots don’t improvise when flying; they rigidly follow a syllabus for each flight to make sure it meets the objectives. Your pilot should work exactly the same way: define objectives for what you want the pilot to prove, test, or verify, then ensure that everything you do in the pilot is oriented at meeting those objectives. Too often “pilot program” really means “throw some random users on it and see what breaks.” A good migration pilot will start with structured testing of basic functionality—migrating a single user, migrating a group of users, testing the resulting desktop environment for everyday tasks—and then move on to more complicated scenarios. This structured testing is especially important if you’re moving from a traditional desktop environment to one with cloud or virtualized components; you will need to allow time to learn to manage the cloud environment or hypervisor, including getting vendor support if you run into problems during the pilot.
Although it’s not called out as a separate phase, this is the best possible time to train users on the new environment. It’s lovely to imagine that you could deploy a new desktop environment without having to train users on it, but in reality, you’ll need to account for the time required to show users what’s different about the environment. Having a stable pilot means that you can do hands-on demos, record training videos, or give users limited sandbox access to the new environment as part of their training. Don’t forget that your support team will probably need training, too, and may even need additional staffing to handle an increased volume of support requests (“I can’t find feature X!” is a common support complaint during early migration stages).
Production rollout
The production rollout phase is where the magic happens. This phase is not much different for desktop migrations than it is for any other complex technology project: you define a schedule for when you are going to migrate various groups of users, then crank through the schedule, dealing with problems as they arise. If you’ve done a good job with your buildout and pilot phases, you shouldn’t encounter serious new problems here. In general, it is better to plan this phase conservatively; if you plan to migrate 100 desktops per week, and you’re actually able to migrate 150, that is much better than planning 150 but only being able to complete 100. Be sure to account for holidays, vacations, and other personnel-related constraints when you’re planning this phase—an effective rollout must take into account that you’re moving the work environments that users depend on, so you have to do it in a way that has the least possible impact on them.
By the time your production rollout starts, your support staff should be manned and trained to support the volume of users you’re migrating each week; your new environment should be stable and performant, and your pilot users should all be working happily in the new environment. If any of these things are not true, that’s a warning sign that you should stop and fix whatever issues are present before going full-throttle with your migration rollout.
Sustainment
The sustainment phase is a little boring because it takes you back where you started: ordinary support and management operations against a stable environment. In this phase, you’re doing the everyday work of supporting the new environment, including fixing broken stuff for users, testing and applying regular vendor security updates, and so on. If the pilot is like an on-ramp for the migration process, this phase is the highway itself: you reach a steady speed and just cruise along (at least until the next big release from Microsoft!).
Easing the process
Having the right tools will dramatically ease the pilot and rollout phases. Users need to be able to work with minimum disruption and disturbance, and the best way to meet this need is with the advanced planning, profile migration and management solutions from Liquidware. Their Workspace Environment Management suite can assist you with every step of a Windows migration including assessing and planning with Stratusphere, and migration with ProfileUnity User Management. Stratusphere discovers installed and in-use applications and helps you scores and compiles your desktop hardware for Windows 10 readiness. With ProfileUnity, you can seamlessly migrate user profiles between any version of Windows, speed user adoption by drastically reducing the overhead required for a migration. ProfileUnity’s Profile Bridge technology feature lets you containerize user profiles and make them seamlessly work with multiple versions of Windows, both forward and backward compatible. ProfileUnity has features that slash roaming and synchronization time, and you can deploy it with desktop, laptop, virtualized, and cloud desktops to give users a faithful translation of their familiar desktop environment from all devices at the same time. Find out more about Liquidware’s migration capabilities here.
