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: https://demazter.wordpress.com/2011/06/12/migration-tip-1-source-server-health/
My second tip Migration Tip #2 – The Practice Run can be found here: https://demazter.wordpress.com/2011/06/14/migration-tip-2-%e2%80%93-the-practice-run/
My third tip Migration Tip #3 – Preparing for Live Migration can be found here: https://demazter.wordpress.com/2011/06/15/migration-tip-3-preparing-for-live-migration/
My fourth top Migration Tip #4 – The Migration can be found here: https://demazter.wordpress.com/2011/06/16/migration-tip-4-the-migration/
My fifth tip is based around testing and clearing up after the migration. You’ve done all the hardwork, it would be a real shame to get this far and to encounter problems when you start to remove the old system.
Check over your work, do some test shutdowns of the old system. Making sure that all users, data and systems are all operational during the shutdown. Even go as far as to turn the system off for a week before you actually remove it from the network. Making sure you tell your users that you are doing this and that any glitches you want to know about. Believe me, all too often they will put up with a glitch and won’t tell you about it, until it’s too late. You need to make it very clear that no matter how small you need to know about it during this “down” time. It’s easier to resolve when the system is available than it is when it’s no longer part of your network.
There may be additional tasks you will need to perform once the old system is decomissioned. These could include (but are not limited to):
- Backups, check you are backing up the data/system in it’s new location.
- Data flow, check that any dataflow in, out and around your network/systems have been updated to accomodate the changes you have made. for example if it’s an Exchange migration, make sure that the firewall rules that control mailflow have been updated. If it’s a SQL Database, make sure that any scripts/log shipping/etc have been modified.
- Check any internal/external DNS entries have been modified if required. If migrating to the cloud these will be external changes, if internal migrations then they will be internal changes.
- Check that any systems that interact with what has been migrated are still functioning, MFD’s, Fax Machines, NAS devices etc etc. The list is endless and only you will know what devices/systems you have in place. Check them all.
- Check with your users that they are happy that all of what they need access to is working and functioning as they expect it to.
- Update your network documentation, do this now, whilst it’s still fresh in your mind.
Finally, once all that has been completed and you are happy that everything is working, decomission the old system. Making sure of course you take a final backup before you do so. Make sure you follow the correct procedure for removing the system you are migrating away from. Don’t just turn it off and take it away. Not following the correct procedure, can and will effect your network and any future migrations.
This is my final migration tip, I hope you have found them useful. Please watch out for my next migration guide which will be available in the next few weeks which is Migrating Small Business Server 2008 to Small Business Server 2011.
If you are planning on a migration and are not comfortable with the process then Demazter IT Services can assist you. Please contact me on firstname.lastname@example.org.
All versions of Microsoft Exchange and Small Business Server require the use of an SSL Certificate. Whilst they will quite happily use a self-signed certificate a commercial certificate can save a lot of time and hassle, purchase Exchange/SBS SSL Certificates at an excellent price from: http://www.exchangecertificates.com