http://marcdekeyser.com

A guideline to migrations: “All hands on deck!”

Welcome to this second instalment of the series! This series of articles is aimed at giving you a hold and a sort of “Best practices” to starting any kind of migrations. Whilst each technology or project has its quirks and traps most of the process you’ll need to go through is, roughly, the same.
The second article will describe a so called “test run” or, as I like to call it, practicing with duds... Seeing as running a test system in the ground is not quite as disruptive as destroying an actual production system I favour having a test run first J. Additionally a number of tips for your actual migration are given.
Step One: “Load the cannons!”
Well you should be prepared at this point to perform a test run of the migration process you have outlined. Whilst I know that it is not in the capabilities of a large number of engineers, this is the moment to put your testing environment to good use.
As you have undoubtedly figured out I want you to make a test run, make it 3 if you can... If you have no issues during these runs I salute you! But it will be more likely  you have either missed a step or have a non-identical environment in your test beds in regards to your production environment.
If you do run into problems (hooray!) this is your opportunity to document them and look at the best course of actions to solve. Remember, a prepared engineer is a ninja!
Step Two: “Tactical retreat”
Make sure that you have that rollback plan tested as well. Remember that, if things go wrong, you want to be able to avoid having shit hit the fan... Especially if you are in the path of said fan! I won’t disagree with you that you’ll be spending a lot more time preparing for migrations then actually performing them, a major downside of working in the field you’re in I suppose...
Make sure you have some backups ready (and tested :@) juuuuuusst in case that roll back plan failed to work. I never needed to use them, but they present another safe net in case the first one breaks...
Last but not least, since you informed everyone there is going to be a migration you should have a phone list handy of the people you “might” need to reach in case of trouble... You did inform everyone, didn’t you?
Step Tree: “Ready! Steady!”
Once you had your experimental test runs in which you hopefully ran into some issues (you know, to keep it interesting [and be prepared of course!]) you can look at doing some first migration actions.
Now while at this point you could just go ahead with the migration you might want to take a step back and decide whether or not you are ready to torment your production environment with making that big move. Review the issues you had and if you were able to resolve them properly.
Nobody likes to pass up an opportunity to torment some users though keep in mind that they, in most cases, will go annoy your manager (and as you undoubtedly know, shit goes downhill...), not  to mention you might lose a lot of game/movie/chill-out time if you don’t conclude that migration in your allotted timeframe!
Step Four: “Fire!”
Now the big moment arrives, you are taking the plunge in the deep and doing the move. Stick to the plan, if possible, seclude yourself from the rest of the world so you can focus on the work at hand. Remember it is important to have food at hand (large pizzas) and loads of fluids (stay away from alcohol, keep that until you are done), some mood music might help you along...
Being mentally prepared before you start is another important aspect. No heavy drinking or partying the night before I’m afraid. Your “little grey cells” need their beauty sleep to function at their peak performance!
Step Four: “I just can’t do it C’ptain!”
If you are running into problems you did not encounter during the test run or even expected (some pesky developer application interfacing with active directory and annoying the crap out of you) keep in mind that stress is your fuel. But don’t be afraid to stop for 5 minutes and take a small break.
Determine where the problem lies and contact the application owner responsible for your woes (revenge is best taken when they least expect it). Solve the problem together and proceed with the plan, but as always, document what happened and how you solved it (and who was responsible for that particular mess).
Step Five: “The aftermath”
Once you were able to run the gauntlet and reach that glorious finish line, having your servers humming along perfectly in sync you should try and work out the documentation you made. Knowing me, that is a couple of hours work as I use a notebook with a not so nice handwriting to keep track of things. Working this out is purely for esthetical reasons. Namely to present a nice report to your manager! We have to try and keep them involved now don’t we?
For the next week or two, try to keep some pro-active monitoring on the migrated systems, just to keep sure everything is working as it is supposed to. Life is hard enough as an IT professional as it is without some service deciding to go AWOL and screw up your life...
Step 6: “Bring forth the rum!”
This is where you can actually enjoy the victory. If all went well you should have a bunch of happy users and a happy manager. Don’t expect praise from anyone but your peers (well, maybe your manager... Maybe!) on your exceptional handling of the situation.
 
 


Feedback

No comments posted yet.