This is the part I like: Unpacking the new machine. Hooking it up to the cheap mouse and keyboard that it comes with. Plugging in the power cord, hitting the switch, and breathing a sigh of relief as it boots into the setup screen. Configuring a few basic options. Right-clicking on the Computer icon, selecting properties, naming the computer and telling Windows that you want to join the network. Typing in the Admin password, waiting a minute, and seeing the “Welcome to kasson.com” window. Rebooting and checking the error log. Total elapsed time: fifteen minutes.
This is the part I don’t mind: Taking off the cover. Finding a good set of hard disk bays. Installing hard disks. Cutting the cable ties to free up power cords. Snapping the power cords into the hard disks. Finding the right SATA cables (Oh, I need a half-meter cable with a ninety-degree connector on the disk drive end that bends that way? Hmm…). Connecting the SATA cables to the motherboard. Finding a route for the SATA cables. Plugging SATA cables into the disk drives. Putting new cable ties on all the cables. Putting the cover back on. Powering on the box. Smiling when the POST sees the new drives. Formatting the drives. Total elapsed time: half an hour, most of that looking for cables.
This is the part I hate: Getting all my data, fonts, images, file structures, applications, passwords, peripherals and their drivers, bookmarks, backup scripts, etc onto the new machine. Total elapsed time: maybe a month.
Over the years the task has gotten easier in some ways. Gone are the funky printer cables that I used to use to transfer data, replaced by Ethernet connections. However, the amount of data involved has risen dramatically, as has the number and complexity of the applications. I’ve worked out a routine, but it doesn’t make it fun.
I’ve tried shortcuts in the past; none of them has helped much, and some of them have caused big problems. The programs that purport to automate the process are the worst solution. They don’t offer much flexibility for changing configuration as you port. Many aps fail to work after the transition, and those that basically work often have licensing problems. When the OS’s differ between the two machines, the registry is often badly messed up by the time you’re done. And maddingly, those subtle misconfigurations that plagued you on the old system are often ported perfectly to the new one.
The best way is conceptually the simplest: decide which of the old programs you really need, and install them cleanly on the new system, then do the same for fonts, data, peripherals, etc.
I first set up the new machine in a work area in the same room as my old machine, using a small monitor and the mouse and keyboard that came with the new machine. . Then I load the aps that I use 90% of the time (which is only about 10% or 20% of the aps I use), and bring my data over en masse with Vice Versa, guarding against data corruption by having it do a CRC check on each file at it makes the transfer. To bring my mail, contacts, and calendar across, I just log into the Exchange server and let it do a synch. Then I hassle with licenses, calling the vendors if necessary, until the aps all work. The work is so tedious that I can’t do it for much more than an hour at a sitting. Since in this case I’m going from a 32-bit OS to a 64-bit one, I had to look for 64-bit versions of the aps. I install backup software, and set it to back up the data to a new set of directories on the server. This seems like overkill, since I’ve got basically the same data in four places (on the old workstation, on the old workstation’s directory on the server, on the new workstation, and on the new workstations directory on the server), but it avoids the problem of inadvertently overwriting a file that you want to keep while you’re using both machines. The only reason not to do it this way is if you don’t have space on the server.
After two or three days, the new machine is ready for real work, so I move the new computer to my usual work spot, hook it up to the big monitor, and move the old computer off to the side. Then I start working mostly on the new computer, installing a new ap every day or so. I hook the old one up so that it’s usable; I’ll need it for the aps I haven’t moved yet, and also incase I find I’m missing something on the new machine.
Until I get everything working on the new computer, I’ll be working on both machines. Each machine starts out with the same data structure (more on why that’s a good thing later), but as time goes on, files are added, deleted, and changed on both machines. I use Vice Versa to synch the data. I could use a different approach: copy all the data to the server, and point both machines at the same data. I don’t do that because it’s not that easy to redirect applications to new data locations. Lightroom is a prime example; if it can’t find an image folder where it thinks it should be, the only way to get it working right is to tell it where the folder is manually. Having done that, it can’t figure out that all the other missing folders share the same top-level path as the first one; you have to go through the whole process for each folder. There’s a way around this for networked folders: reset your drive letters until there’s a hole where Lightroom expects to find the images, and then map the networked files to that drive letter. I’m not sure why I don’t do things that way; somehow it seems fragile, and I worry about performance when I don’t have images stored locally. The inflexibility of Lightroom with respect to file structure makes if hard to clean things up as you move over to the new machine. It’s much simpler just to use the old file structure.
Over a month or so, the old machine gets used less and less as its functions are transferred. Eventually, it stays powered down for a month and I figure I’m done. I power it up, scrub the data off it, and give it away.
During the transfer this time, I ran into a few interesting situations and had some random thoughts on the process.
Where are my files? I try to keep data separate from the programs files. The main reason: it makes it easier to back up the computer. Not all programs default to this arrangement. In fact, it is quite common for older programs to store the data they use in a subdirectory of the directory in which they are installed. Modern versions of Windows are intended to be used by several people. The Windows designers, realizing that allowing programs to store their data where the programs are installed won’t allow different users to have different data, came up with a fix that involves storing the data elsewhere, in separate folders for each user, and lying to the program about where it’s stored. I had forgotten about this programmer-versus-programmer trickery. I loaded my weather monitoring program on the new computer, then went back to the old one to get the weather history files. I opened the program, and it said the files were at Program FilesWeatherlink. I looked around and couldn’t find them. Vaguely remembering something about Windows lying to programs about where their data is stored, I fired up the Windows Explorer search engine, which is a much duller tool for searching for file names now that it’s been enhanced to do indexed searches. After a few false starts, I got it to display hidden files and folders, and searched the whole OS disk. I finally found the files at C:UsersUsernameAppDataLocalvirtualStoreProgram FilesWeatherlink. I copied them over to the new machine, this time installing them with all my other data so that a) they’re properly backed up, and b) I don’t have to go looking for them next time I upgrade hardware.
Where are my Lightroom presets? Upon installing Lightroom on the new computer, I noticed withou surprise that that my presets were gone. I found them on the old machine under C:UsersusernameAppDataRoamingAdobeLightroom. If you have a different OS, you can find where yours are by going to Edit, then Preferences, clicking on the Presets tab, and clicking on the button that’s labeled “Show Lightroom Presets Folder”.
Moving Photoshop plugins is a crap shoot. Sometimes you can get away with just copying them over into the right plugins folder, and sometimes you have to run the installation program all over again. It seems to hinge on licensing provisions.
USB dongles are great things for license portability, but finding a 64-bit dongle driver (or even a Vista driver) for an old program can’t always be done.
It’s always nice to be able to say sayonara to an overly intrusive utility, virtually useless plugin, or an applet that has an obnoxious GUI, and switching machines provides the shove to make you go look for a replacement rather than just reinstalling the program you hate.
Sometimes you don’t need a driver. I have a Logitech wireless mouse that I like a lot, but the driver and associated software that’s part of the Logitech installation package is big and intrusive. When I moved the new machine to its permanent location I plugged in the transmitter for the mouse and fired it up, expecting to get just enough mouse functionality so that I could install the Logitech driver. To my surprise, the mouse does everything I want it to do with the standard Microsoft mouse driver.
Programs that help you move userids, passwords and bookmarks are a godsend. MozBackup, which works with Firefox, even brings over your autocomplete library.