http://marcdekeyser.com

A guideline to migrations: “The Beginning”

Welcome to this first 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.
This first article will describe what’s called the preparation process. Although most  IT professionals have the tendency to just into thing (or “forget about the manual, I’ll make it up as I go along!) it pays to actually prepare for your migrations, transitions or even deployments of new systems, decreasing headaches and issues during the process as well as getting less trouble from the management (I had to learn this the hard way J).
Step One: “Why?”
The most common thing you’ll run into is the question “Why do we need to do this?” so make sure you have your arguments ready for this. Think in terms of the benefits for the business as that always goes better then “Because this version is waaayyy cooler”. This, generally, only applies to people who are working internally and have not been contracted or tasked with performing the migration.
Step Two: “Know Thy System!”
I can’t stress this enough! Knowledge is power! So if you want to make the world a better place make sure you know the ins and outs of the system you are planning on upgrading! Document it if it hasn’t been done because you’ll see that you’re going to forget that one little “this doesn’t matter” setting you’ll need to set on your new system...
You can use the “Best Practice Analyzer” toolsets from Microsoft to help you collect your data and see what warnings or even errors the system you’re looking at is throwing... Available for download here:
http://www.microsoft.com/download/en/search.aspx?q=Best%20Practice%20analyzer
Step Three: “Does this work?”
Determining if your current system is currently up to date with software updates or even just running well is an important consideration as at one point you’ll have to know whether or not you can use it as a fall-back plan in case something goes wrong. Obviously we’d rather avoid having to do that but you would want a backup parachute when jumping out of an aircraft no?
Tackle the issues you can and make sure your system(s) are up to date
Step Four: “Plausible deniability”
Decide on a timeframe where you can migrate the system, limiting impact on the business (so no user or data migration during business hours, thank you very much!) and then communicate this to your management and users! Extensively! Repeat if a number of times so nobody actually “forgets” that it is going to happen... Try to have the first communication about it go out to the users around 3 weeks before it happens. Then, at minimum, send it again a week before and a day before the migration happen. Make sure your users are aware of the possible issues they could run into during the time you are performing the migration.
Sure, this is a huge hassle and effort for something that should be transparent to your users BUT you would not want to run into a situation where an issue arises and causes a productivity loss in, oooh let’s say, the closing of the books...
Step Five: “You know what you’re doing, right?”
Determine if you are comfortable enough with the new technology and the migration process to actually perform the “operation”. After all, you can always hire a consultant to help you plan or, god forbid, even help you during the migration! If you have never ever performed a migration before you are in for a treat because they never go exactly as planned and you’ll have to be able to think fast and make the right choice in order to successfully overcome the obstacles presented...
This involves a lot of reading and, if you’re lucky enough, to test the migration in a lab environment. Not a lot of small (or even large) IT environments actually have a lab environment, much to my frustration, but if you do capitalise on it! Being able to perform a migration in a lab environment at least once (preferably 3 times) will add to your confidence and will show you what exactly you’ll encounter during the migration itself.
Use Microsoft Technet (http://technet.microsoft.com/) to prepare and find the guides on how to perform the migration your technology. Do note that Microsoft often uses the word “transition” instead of ‘”migrate” in its documentation, so if you can’t find your document right away, check your search parameters!
Conclusion
This concluded the first instalment of the series. Covering your bases is important as an IT professional and even more so if you’re about to embark on the wonderful voyage of migration (or transitioning) from an obsolete technology to the crispy, shiny newest and brightest to make your business more efficient and a nicer place to work.
Your comments are welcome and most appreciated!


Feedback

No comments posted yet.