Since I’ve been working at ColoCrossing, I’ve been responsible for coordinating, preparing and executing quite a few migrations for new and existing customers. Sometimes it will be something as simple as a single website, all HTML based. Other times, it’s one of the busiest sites and/or network of sites in the world. In this post (which I intend to be short, may end up long) I’ll cover how we generally approach these types of accounts.
Anyone familiar with being a systems analyst or IT manager may recognize a lot of these steps follow whats known as SDLC. That is, systems development lifestyle. All my college textbooks would tell me that goes as follows: Investigation, Analysis, Logical / Physical design, Implementation, and Maintenance. Imagine my surprise when that came back to help me. So in my own words, here’s how it goes:
Step 1: What does this client do? — First, I start by introducing myself to the client and to their environment. I visit their site(s), learn their software, maybe sometimes learn what the current administrators do for fun. It all helps. I login to their existing machines, control panels and I dig around. Sometimes I’ll spend an entire shift (that ranges from 4 hours to 24 hours) just seeing whatever looks interesting. I figure out their minimum system requirements, what server software their running, etc. Basically everything you would expect a sysadmin / project analyst to do. Once I’ve done this, I then ask the client to tell me about their environment. I compare notes, recheck my work, and then I write my checklist of what I need in order to make this work.
Step 2: Setup — At this point, I know the client, I know their servers, I know their environment, and I know exactly what I need to do. So me and my team will prep their new servers. Install and configure their webserver. Check. Install any necessary scripting languages, databases, and other system software. Check. Install their control panels. Check. Harden the machine, secure it, and make it as secure. Check. Add in all their special requirements, and we’re good to go, for now. Now we test. And we test some more. Once we’re done testing, it’s time to migrate.
Step 3: Staging! — Now, we migrate all (or some) of the existing clients environment over to our servers. And then we test some more! We use previews, we create new sites, new software, we deploy projects and programs. Whatever it is this client does, we do it. We find and resolve errors, and we make sure everything is 100% good to go before we schedule the real migration.
Step 4: It’s go time — So we know the environment, we setup the new environment, and we staged it. Now we get a gameplan in place with the client. Window starts at X time, at which point we migrate Y service from Z server into serverA with ColoCrossing. At X time, phase two of migration begins. This seems like a short step, but this can be a 2 hour or 2 week process. Depends if it’s a phased or all at once migration. Depends if everything works. Well, it really just depends on a lot.
Step 5: We’re done, right? — Ha, right. So in the best case, steps 1-4 have gone off relatively well. Everything is migrated and the client is happy. But you know what? Something is going to break, or something went wrong and we didn’t catch it. So now we maintain. We continue to work with the client until they are 100% happy. And when that time comes, we get ready for the next migration. (It’s not called a lifecycle for nothing)
It seems like a simple process, or at least simple enough in a 750 word blog post. In reality though, it’s one pain in the rear. There are so many variables, so much to communicate, and so much to learn that even a single site migration can take a week to get right. I’ve been part of a few migrations for high traffic sites (think top 1,000 Alex big) that have gone on for months. That’s not a discredit to our team (who are, in my opinion, absolute professionals at this) or to the people we’re working with. That’s just what it takes.
-Brian
