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 is around source server preparation.
No migration is an easy migration, there is always potential for something to go wrong. All we can do is try to minimize this risk.
The biggest risk comes from the system we already have in place, the integrity of this system is paramount in ensuring a successful migration.
Making sure your source system is healthy and configured correctly will go a long way to ensuring you have a smooth migration.
Use analyzers and health check tools that are available from the vendor. Microsoft, for example, have a number of best practice analyzer tools. These can be used to identify any problems the system may have and provide advice on how to resolve them. Some of the ones I use regularly are listed below:
Small Business Server 2003 BPA: http://www.microsoft.com/d
Small Business Server 2008 BPA: http://www.microsoft.com/d
Exchange Server BPA (not for Exchange 2007 or 2010, the built in BPA should be used): http://www.microsoft.com/d
Internet Security and Acceleration Server BPA: http://www.microsoft.com/d
SQL Server 2005 BPA: http://www.microsoft.com/d
In a Microsoft migration I will use tools like DCDIAG, NETDIAG, REPLMON and REPADMIN to check for errors, even if it’s a single server. You would be surprised how easy it is to misconfigure a single server. Further details on the usage of these tools can be found here:
DCDIAG: http://technet.microsoft.c
NETDIAG: http://technet.microsoft.c
REPLMON: http://technet.microsoft.c
REPADMIN: http://technet.microsoft.c
Make sure the source system is up-to-date. All updates, service packs etc need to be applied. This may seem like a waste of time on a system that you are soon to be migrating out of your network but really it isn’t. New products from the same vendor normally rely on the source system being up-to-date. I have been known to spend hours installing service packs and updates on a source server.
It’s worth spending the time getting this part of the migration perfect. There are no timescales in play here you can take your time, once you start migrating there are pressures at play that will make the slightest hiccup seem like your whole world is imploding. I would consider this part of the migration process the most important, and therefore if you are not comfortable with this process, hire someone who is. Buying in consulting services to make sure the server is health can save you a lot of time and money.
=-=-=-=-=-=-=-=-=-=-=-=-=-
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 is around source server preparation.
No migration is an easy migration, there is always potential for something to go wrong. All we can do is try to minimize this risk.
The biggest risk comes from the system we already have in place, the integrity of this system is paramount in ensuring a successful migration.
Making sure your source system is healthy and configured correctly will go a long way to ensuring you have a smooth migration.
Use analyzers and health check tools that are available from the vendor. Microsoft, for example, have a number of best practice analyzer tools. These can be used to identify any problems the system may have and provide advice on how to resolve them. Some of the ones I use regularly are listed below:
Small Business Server 2003 BPA: http://www.microsoft.com/d
Small Business Server 2008 BPA: http://www.microsoft.com/d
Exchange Server BPA (not for Exchange 2007 or 2010, the built in BPA should be used): http://www.microsoft.com/d
Internet Security and Acceleration Server BPA: http://www.microsoft.com/d
SQL Server 2005 BPA: http://www.microsoft.com/d
In a Microsoft migration I will use tools like DCDIAG, NETDIAG, REPLMON and REPADMIN to check for errors, even if it’s a single server. You would be surprised how easy it is to misconfigure a single server. Further details on the usage of these tools can be found here:
DCDIAG: http://technet.microsoft.c
NETDIAG: http://technet.microsoft.c
REPLMON: http://technet.microsoft.c
REPADMIN: http://technet.microsoft.c
Make sure the source system is up-to-date. All updates, service packs etc need to be applied. This may seem like a waste of time on a system that you are soon to be migrating out of your network but really it isn’t. New products from the same vendor normally rely on the source system being up-to-date. I have been known to spend hours installing service packs and updates on a source server.
It’s worth spending the time getting this part of the migration perfect. There are no timescales in play here you can take your time, once you start migrating there are pressures at play that will make the slightest hiccup seem like your whole world is imploding. I would consider this part of the migration process the most important, and therefore if you are not comfortable with this process, hire someone who is. Buying in consulting services to make sure the server is health can save you a lot of time and money.
=-=-=-=-=-=-=-=-=-=-=-=-=-
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.