I recently wrote a post about considerations for an international deployment – key items that need to be planned for or mitigated to avoid trouble down the road. To follow up on that post, I wanted to discuss some additional items that aren’t necessarily specific to an international deployment, but really are more relevant for any migration, large or small, local or global.
1. Backup, Backup, Backup!
At the end of the day, either the business must be comfortable with the risk of data loss during migration, or it must do something to mitigate the risk. Our recent client had a requirement that we not only migrate user data from PC to PC, but also that we capture backups of every workstation so they could be rolled back. While I originally thought that was a little overprotective, it ended up saving user data and preventing user down time on a few occasions. For any “in-place” upgrade, where a laptop or desktop was being upgraded without any hardware swap, we captured a full image of the local disk before ever modifying any data on the machine, enabling us to roll the user back to Windows XP in the event of an imaging failure or an undiscovered issue, and also enabling us to recover any errant user data that fell outside the folders our USMT migration process was checking.
Storing these backup images required large NAS arrays to be deployed at many of our client sites (I would guess not many locations will have enough disk space for potentially hundreds of 30+ GB images), and the backup process added time to each machine migration; in some cases by 2-3 hours depending on the amount of data each user had. But it meant that in the course of over 2000 workstation migrations, only once did a user lose any data. Without the backups, that number could potentially have been much higher.
If taking full backups like this is not an option for your deployment, consider a rolling swap-out of the hard drives in each machine, only re-using an old hard drive after a grace period has expired and the user has confirmed (as best they can) that they have their data and are able to perform all their daily tasks. If budget allows, hard drives can even be completely replaced and old drives archived.
2. Have a Plan for Legacy Processes
There were instances during our recent deployment where software support for the upgrade (and the associated “bit width” change from x86 to x64) was still being investigated, or a business process didn’t support the upgraded software we were deploying. In some cases, a concurrent project was migrating to a new application or process that would support the new OS, but the current process did not. In all of these cases, we had to “leave behind” Windows XP machines to support these legacy processes.
Your deployment plan should include a way to document and justify these skipped machines, as well as a way to handle them so they’re not forgotten once the major migration effort at the site is finished. Where possible, we pre-built spare workstations (even using a handful of hardware chassis to image dozens of replacement hard drives in one case) and left them behind in order to speed deployments by local site staff once an upgrade was possible. We also shifted our focus at some locations away from “migrate every machine” and towards “train local IT” when we identified that machines would need to be left behind – basically making sure that the local resources were very comfortable with our processes and able to finish up the machines that the migration team was unable to migrate during their visit.
3. What About Smaller Sites?
Sometimes you’re dealing with large sites that have local server infrastructure and local site IT staff, and there may already be a local server that can be used for image deployment, or the size of the site justifies the purchase of new equipment. But what about when the site is small? There may be 15 people on site with no dedicated IT resource. For several past clients, WMP has built portable deployment servers to enable a couple of IT resources to travel to a small site and image workstations, rather than forcing all users to travel to a central site or ship equipment around. These portable deployment servers have ranged from very high end laptops loaded with memory and SSDs, all the way up to what we called “The Pod” for one client: a ruggedized, fully enclosed 6U rack on wheels with a deployment server, large disk array for data backups, gigabit switch (to speed imaging at some sites that still had older 100Mbps switching) and even a VPN router that allowed us to make our own connection back to the corporate network where needed. We ended up building a couple of these and shipped them all over Europe and the United States with great results.
If you’re replacing user hardware at the small sites, a good option is to centrally image systems before shipping to a remote site, or even have the hardware vendor apply the image for you, but chances are you won’t always be replacing hardware completely. These portable deployment systems have worked very well for us in the past, especially since the IT resources that come on site get to spend more time with the users and have the opportunity to address other issues at the site.
4. What About Remote Workers?
It’s one thing to go from office to office and migrate the machines that are on site, but there are almost always users that work from home, in addition to traveling sales force, field workers, or other users that may never return to an office. These users present an additional challenge to the logistics of a major migration. If you are lucky and there are conveniently timed events such as sales force annual meetings or other gatherings where you have the opportunity to get remote workers together in a single place, you have a great opportunity to perform these upgrades. This is another use of the portable deployment systems mentioned above: West Monroe was able to leverage the “Pod” portable systems in hotels and at conferences as well as within the client’s smaller offices. We collected laptops from users as they checked in to the hotel, perform the upgrade of workstations while the users were attending training sessions, and return the laptops during a training session late in the conference. Believe it or not, the client actually appreciated that users did not have laptops to distract them during meetings and training sessions.
But if there isn’t such a meeting, you may be forced to get creative. For another client, we were able to have users ship their laptops to a central location, where they were migrated and turned around in a single day. Training was then conducted over video conference calls. The advantage of this process was that users did not need to travel to a central location, saving money and time. Unfortunately, users were without their laptops for 2-3 days during shipping and upgrades. In addition, the migration process needs to be exceptionally well proven – there’s very little room for error when machines have to be turned around in a single day, and cannot miss shipping deadlines. That risk can be mitigated if users are due for hardware replacement – even in cases where hardware is not yet due for replacement, it may be worth paying to accelerate replacement in order to help simplify the upgrade process.
What other things have you run in to over the course of your recent deployments or migrations? Have you used alternate methods to work around any of the issues I’ve discussed?