Welcome to my series of short tips on migrations. Whilst based on Microsoft migrations the same principles can be applied to any type of migration.
My first tip Migration Tip #1 – Source Server Health can be found here: http://www.experts-exchang
My second tip Migration Tip #2 – The Practice Run can be found here: http://www.experts-exchang
So, we now have a healthy source server and you have practiced until the match sticks snap what next?
My third tip is about making sure you are prepared for the task ahead. Any type of migration needs to be taken seriously. It is a business critical operation you are about to embark on. If you are in any doubt about it at all, now is the time to say so, and if necessary call in help.
If you are happy with the process and confident you are able to complete the steps to achieve your goal then the next thing we need to do is plan a time to do it.
Most migrations are not time limited other than SBS to SBS migrations that have a limit of 21 days where both SBS servers can co-exist at the same time.
Make people aware of what you are doing. Involve them, explain that you are expecting to have teething problems but would prefer if they collated them and then passed them to you when you ask for them. The last thing you want is to try trouble shooting whilst trying to complete a migration.
Find out if there is anything business critical happening (a big bid/contract etc that needs to be out just when you take the mail system offline) that could be delayed by the work you are carrying out, and if so, delay your migration. Talk to absolutely every member of staff. Manage Expectations.
In reality, if you get it bang on, the end users shouldn’t even notice and I would say that in 99% of the migrations I have done, this has been the case. But there is always the odd one.
Have a recovery plan, know how to back out of what you are doing if it does go pear shaped. If you need to lock and migrate huge amounts of data then make sure you plan this stage of the migration for when people aren’t going to be using the system as heavily.
Document what you are doing, make notes of which stage you have got to and what action you have just taken. This might seem like a waste of time, but take it from someone who has picked up a few failed migrations from people just like yourself, it’s not. Knowing exactly what stage you are at will help a consultant very quickly get to grips with the situation and this means a faster resolution.
And, most importantly of all, make sure you have backups! Take more than one, take one off-site, and do it different ways. I like to have a backup on removable storage so I can access it quickly but also on tape just to be sure.
=-=-=-=-=-=-=-=-=-=-=-=-=-
If you liked this article and want to see more from this author, please click the Yes button near the:
Was this article helpful?
Thanks!
=-=-=-=-=-=-=-=-=-=-=-=-=-
Written by Glen Knight (demazter) as part of a series of migration tips.
My first tip Migration Tip #1 – Source Server Health can be found here: http://www.experts-exchang
My second tip Migration Tip #2 – The Practice Run can be found here: http://www.experts-exchang
So, we now have a healthy source server and you have practiced until the match sticks snap what next?
My third tip is about making sure you are prepared for the task ahead. Any type of migration needs to be taken seriously. It is a business critical operation you are about to embark on. If you are in any doubt about it at all, now is the time to say so, and if necessary call in help.
If you are happy with the process and confident you are able to complete the steps to achieve your goal then the next thing we need to do is plan a time to do it.
Most migrations are not time limited other than SBS to SBS migrations that have a limit of 21 days where both SBS servers can co-exist at the same time.
Make people aware of what you are doing. Involve them, explain that you are expecting to have teething problems but would prefer if they collated them and then passed them to you when you ask for them. The last thing you want is to try trouble shooting whilst trying to complete a migration.
Find out if there is anything business critical happening (a big bid/contract etc that needs to be out just when you take the mail system offline) that could be delayed by the work you are carrying out, and if so, delay your migration. Talk to absolutely every member of staff. Manage Expectations.
In reality, if you get it bang on, the end users shouldn’t even notice and I would say that in 99% of the migrations I have done, this has been the case. But there is always the odd one.
Have a recovery plan, know how to back out of what you are doing if it does go pear shaped. If you need to lock and migrate huge amounts of data then make sure you plan this stage of the migration for when people aren’t going to be using the system as heavily.
Document what you are doing, make notes of which stage you have got to and what action you have just taken. This might seem like a waste of time, but take it from someone who has picked up a few failed migrations from people just like yourself, it’s not. Knowing exactly what stage you are at will help a consultant very quickly get to grips with the situation and this means a faster resolution.
And, most importantly of all, make sure you have backups! Take more than one, take one off-site, and do it different ways. I like to have a backup on removable storage so I can access it quickly but also on tape just to be sure.
=-=-=-=-=-=-=-=-=-=-=-=-=-
If you liked this article and want to see more from this author, please click the Yes button near the:
Was this article helpful?
Thanks!
=-=-=-=-=-=-=-=-=-=-=-=-=-
Written by Glen Knight (demazter) as part of a series of migration tips.