System migration is a difficult and time consuming process, only your boss’s boss thinks otherwise. They never spent all those weekends freezing in the data center wasting countless hours doing migrations, waiting for backups and restores to complete, reconfiguring system settings, testing, tweaking, promising the family that you’ll be home soon. This is migration and anyone that says otherwise, hasn’t really worked in IT. In-fact, that should be my next litmus test for an interviewee. “So, how long did your last migration take?” An immediate shrug and drooping of eyes will indicate an affirmative of real world experience and not another paper certified semi-professional. If the candidate immediately throws their coffee into the wall, then they’ll get an offer immediately. Do not pass Go; please go directly to HR and begin doing your new hire paper work.

I guess that it’s hard for most non-IT people to understand the pain and suffering that comes with migrations because they probably have misconceptions like:

Can’t you just copy the files? – Yes, absolutely, all 5,934,182 and 2,000,000,000,000 Bytes of them. That’s 2 Terabytes by the way, a lot scarier when you see all the zeros huh? Oh, and we’ll have to kick all of the users off of the system because although we have a Gigabit network, we’ll only have access to about half of that realistically, so at best that “copy” will take no less than 4.4 hours. Except that the system bus and disks probably can’t even come close to that sustained rate of throughput, so they’ll be the big bottleneck. If we get disk performance of around 75 Megabytes per second then that’s going to take 7.4 hours, or what many refer to as “a work day”.

We’ll also have to kick all of the users off of the system while we do this “copy” because we don’t want them to make changes to files that we’ve already copied to the new system or those changes won’t make it across. Most of the users and management won’t mind much since they’ll probably be barbecuing with their family on a Saturday. Now, let’s kick off the users, start the copy process and watch to make sure that no errors occur. If an error does occur, then we’ll have to start the copy from the beginning again because we won’t know where it stopped when it crashed. No problem, except that it probably won’t fail in the first 30 minutes, it’ll fail at around the 5 hour mark for some vaguely decipherable reason like a process lock or something. Better use backup and restore software to have a higher probability of success since they’re more resilient than a straight copy.

Once we do finally complete the data migration then we’ll have to recreate all of the shares and, uh oh, we did remember to recreate any local user accounts, but they’re not showing up because security was copied by SID. Ack! “What time is it?” Got to fix all of those permission issues now and audit the file system to make sure that you caught them all. An hour later… Think we found them all, and the shares are working, now for the user updates and some more testing. Finally, we’ve fixed any remaining issues with a total time of around a day and a half if most things went well, and that was migration of our File Server. Can’t wait for the business critical application servers, especially that machine which no one quite knows how it’s configured or stays running.

So, hopefully you’ve gained a little more insight into the trials and tribulations of system migration. If only there were a set of tools to allow users to stay connected while the entire system is migrated regardless of hardware vendor…

Get ready for some serious relief for your migration woes from Double-Take Software, check out some of the details in my post to our group blog too.