My least favorite server management task is migration. I really hate migrating servers. No, wait… hate is far too mild a term. There isn’t really a term that gets to the depth of my feelings, probably not even in Klingon. It follows, then, that I more than love it when a migration is done. There are a number of reasons why I hate them, but there are two in particular.
First, all of the testing, re-testing, and re-re-testing things that already work where they are. It’s not only tedious but frightening. There always seems to be a couple things that can’t be properly tested until after the migration is complete, and sometimes you don’t even realize it until then.
Second, migrations lay bare all of the cruft and crap that you’ve built up over the years and months. It’s like moving a couch that hasn’t been cleaned under for years, it’s shocking to realize what a slob you are. It’s good that it’s getting cleaned up, since it wouldn’t otherwise be, but it’s just a bit depressing.
Recently I was involved in the migration of a web site from two hosts to three different hosts with very different capabilities. I wrote most of the software behind the site and I never anticipated the way in which the site would be carved up. For example, the SSL certificate was created for the www host, but the new www host couldn’t run the secure pages so there needed to be a new host created and the secure pages separated from the rest of the system. Naturally, this broke a bunch of external links that needed to be mapped over to their new counterparts. It was a time consuming job that wouldn’t have been necessary if I’d had the foresight to build the secure pages separate (not a mistake I’ll make again.)
It would be easy to respond by living each day as though each server is going to be migrated someday, and try to anticipate every conceivable problem that may arise (easy to say, much harder to do.) But I don’t think that’s the best solution. There are certainly some more likely scenarios that would be good to anticipate, particularly if they’re not too costly to mitigate, but it would be a mistake to spend time mitigating every possibility. The old programmer’s motto “Don’t do today what you may not need to do tomorrow” holds sway. As painful as migrations are, it’s the right choice to leave some of the pain there and not try to spread it out, since you’ll probably spread out more pain than you remove. Don’t peel that bandage too slowly!