Why Are You Migrating?
One of the first questions that you need to ask yourself is “Why am I migrating?”.
There are probably several reasons for migrating. These may include some of the following:
• server / software is old
• server /software is failing
• current support level is not what I require
• current level of access is too restrictive
• feature list is too restrictive
• costs are too high
• current host is in the wrong location (US vs UK, for example)
The choices you make for your new server / host / system should be based on the motivation for your migration. You should also allow for your future plans otherwise you will find that you need to migrate again if you start a new project that requires something that you do not have.
Your Migration Budget
It is a fact of life that most businesses do not budget for a migration. It is a “hidden” cost, if you like. Things like development, research, new systems, etc. are easy to budget for because they are obvious costs. A migration is often not budgeted for because until you need to migrate your systems you will not think about it! However, every business that uses servers will, at some stage, need to upgrade to newer systems. If your accounts dept. does not already budget then raise the point with them. On average you should expect to perform a migration every two to five years.
What Should I Migrate?
Deciding what you are going to migrate is a fundamental step in planning your migration. If you are moving to a new server with a fresh operating system then take the opportunity to do some spring cleaning on your data! It is always a good idea to keep data backups for historical reasons but this does not mean that your new shiny server needs to have all that data in it! You may find, for example, that you have thousands of old emails dating back to year 200x which you haven’t looked at in years…, do you really need to transfer these to your new email server? You may have backup files from the last time that you did a migration – do you need these transferred to your new server or would they be better off sitting on an external hard drive in your office drawer? If you are not sure then it is always better to have too much than too little, especially when storage space is so cheap these days. But if you know you don’t really need it, why go to the expense of transferring your dead wood to your new systems?
Planning your time frame
Every now and again we get a phone call that goes along the lines of:
“Hi, my server is dying and I need it migrated this weekend as a matter of urgency”.
Or words to that affect.
If your server is that bad then why have you left it so long before doing something about it? We get people telling us that their server has been playing up for months but recently it has been really bad. The chances are, especially if you have a hard drive problem, that pulling all your data off it will be the final nail in the coffin! As soon as you realise that there is a problem you need to be proactive; at the very least back up your essential data!
Another thing to consider is that if you are going to ask someone to perform a migration at very short notice then you will expect to pay a premium. Not only are you asking them to stop working on other projects they are dealing with, you are also asking them to potentially give up their free time in order to meet your deadline!
Then there’s the the testing phase of a migration. You should be prepared to test your new systems thoroughly before you relaunch. Nobody will understand how your site works like you do. Test, test and test again! Take this testing phase into account when you plan your migration time frame and be prepared to wait for problems to be resolved. Fixing a problem is usually a very fast process; actually tracking down the cause of a problem can take hours of delving in file systems and checking permissions, modules, settings, etc. If you have access to the original developer of the software / website then they will probably be able to tell you what the problem is and how to fix it very quickly!
When Should I Re-launch?
The re-launch is the single most important stage to plan for! re-launching means swapping from your existing server to your shiny new one. Things to consider are:
• if it all goes wrong how quickly can I switch back to the existing server?
• if it does go wrong who will be available to help put it right?
• have I made sure that I am available to ensure that the process goes smoothly?
When you re-launch, unfortunately things can go wrong no matter how much testing has been undertaken. 90% of problems will become apparent and be resolved during the testing phase. That still leaves 10% potentially unaccounted for. In the rare circumstance that something does go wrong you need to have someone available to help put things right.
The upshot of this is that re-launching at 2am on a Sunday morning is a bad idea. Very bad! The re-launch process requires clear thinking and the availability of people who can help sort things out. It is worth bearing in mind that a re-launch should not, in most cases, require more than one hour of downtime and it is often considerably less. Sometimes it is possible to make the switch over with no downtime at all but this is rare and depends on a number of factors.
Our philosophy is that the best time to perform a re-launch is on a Monday or Tuesday morning between 8am and 10am. This means that there is enough time to do preparation (re-sync files, mail and databases) before major traffic starts hitting the server. Also the start of the week means that you have four of five days of access to people who can help put things right. There is nothing worse than having your website or server off line and not being able to get in touch with someone to fix it!
The Final Stages
Okay, great – the website or server has been transferred and is now live! Nobody noticed any downtime and everything is running much faster than it was! There will now be a few days where you will probably notice little niggles – for example, your spam filtering isn’t working as well as it was. During this phase you need to decide whether any problems are migration related or not. If you suddenly notice that a script on your website is not working (this should really have been picked up during the testing phase) then investigation will be required to put it right. Extra time will be spent on the migration to resolve such problems and hence there will be overages incurred (did I mention how important the pre re-launch testing phase was?).
Once everything is resolve and your server is running well the migration is over. Go and visit your accounting dept. and make sure that they are putting the money aside for your next migration in a few years time!
Author: Michael Moore, SEM Solutions
