I previously worked as the CIO for a hospital chain. Not long after being hired, I was directed to bring all computers into year 2000 compliance, which meant migrating all machines to the latest Windows OS. Of the facilities that I administered, six were across town, seven were within a 90-minute drive, and eight were much farther away—some as far as a five-hour drive. This distance proved to be the biggest challenge during the Windows client migration.

If I left a tool or a disk at my office, there was no running back to get it. And most of the more-remote facilities were in rural areas where computer stores didn’t exist. When traveling to the remote locations, I had to be prepared for anything. I also needed the migrations to go as quickly as possible because of the long travel times involved.

I used several techniques to optimize the migration process, including:

  • Taking a complete hardware/software inventory.
  • Solving any preexisting hardware/software problems before the migration.
  • Ensuring OS compatibility.
  • Testing, testing, testing.
  • Starting the migration locally and expanding outward to the other locations.

Take an inventory
Prior to hiring me, the hospital chain had relied purely on outside consultants for technical support. This meant that there was absolutely no hardware or software inventory. Before I could upgrade anything, I needed to compile a report of who had what so I would know exactly what needed to be migrated.

Initially, I thought that I could compile such a report without having to travel to the facilities. I sent a letter to the person running each facility stating that I needed a full hardware/software inventory of each PC. I also set a deadline for the information to be faxed to me. Unfortunately, I found that these individuals often knew little or nothing about computers and most of the faxes I received were incomplete or inaccurate.

This meant I would need to take the inventory myself. Because different facilities were running different network types and different operating systems, I couldn’t just run a utility to automatically compile the inventory. Instead, I traveled to each facility and each computer, manually entering the data into an Excel spreadsheet that I kept on a laptop.

I assumed that compiling the inventory would be an easy process and decided to start with the six local facilities the first day and then move to the more distant locations. This strategy also allowed me to refine the inventory process before traveling to the remote locations.

Fix existing problems first and upgrade when necessary
While taking the inventory, I discovered several problems that needed to be resolved prior to the migration. Because many of the computers were used only to run network applications, the floppy drives often didn’t work because of dust contamination, and most machines didn’t have CD-ROM drives. Furthermore, almost all of the machines were infected with viruses—the company had no antivirus software or software-control policies prior to my arrival. Still other PCs didn’t work at all or didn’t have functional network connections. Also, many PCs didn’t meet the necessary hardware requirements for the new operating system.

As I went from facility to facility, I made note of the various problems that I encountered. By about the third or fourth facility, I realized that I was finding the same sort of problems at each place. I decided that prior to visiting a facility, I should fill the trunk of my car with floppy drives, CD-ROM drives, RAM chips, processor upgrades, keyboards, mice, a couple of new PCs, and a spare monitor or two. At each facility, I began preparing PCs for the migration process by fixing any problems that I found as I was compiling an inventory. If a machine was beyond repair, I simply replaced it.

After a few weeks, every computer in the organization was functional and virus free. It was then time to perform the migration process. In this particular situation, creating an image file and restoring it to each PC was out of the question because virtually every PC was different. Part of what I was trying to accomplish through the migration was to standardize the PCs. This meant that I would need to perform the installations manually.

Test, test, test
Even though I had done extensive preparation work in getting the PCs ready for the migration, I decided that I should test a couple of machines at my office prior to doing onsite migrations. I called a facility that was down the street and arranged to borrow a couple of computers belonging to people who were on vacation. I took these computers back to my office and upgraded them there. This gave me a really good idea of the software I would need to have with me during the migration process.

When I finished migrating these machines, I returned them to their locations and asked several users to work on the PCs and report any problems they had. This technique let me work out the kinks without heavily impacting user productivity. Because the users who owned the test PCs were on vacation, if the PCs malfunctioned, the users acting as my guinea pigs could always go back to using their own PCs.

Start locally and expand outward
Once I got the bugs ironed out of the migration process, I decided that it was time to begin a full-scale migration. Again, I started at the local facilities and gradually spread out. The idea was that I could gain experience at the closer locations, and by the time I made it to the more distant places, I would have the process completely optimized and bug free. This allowed me to get in and out of those locations very quickly. Yet even with this planning, I still took spare parts and a spare computer with me. I just never knew when something was going to break, and I really didn’t want to have to drive hundreds of miles to get replacement parts.