Recently, our team was tasked with moving all the SharePoint databases of a SharePoint 2007 farm from one database server to another.
Microsoft recommends using SQL aliases while installing SharePoint. This makes such database moves much easier. Unfortunately, this guideline was not followed when the farm was first created, probably because such guidance was missing in the early days of SharePoint 2007 when the farm was originally created. The key to performing such a move is to create an alias for the new SQL instance and give this alias the same name as the current instance of SQL Server that the SharePoint databases are hosted on. Of course this would mean that the alias can only be configured after the original SQL instance is stopped to avoid any conflicts.
Microsoft provides a fairly comprehensive and accurate guideline around moving all SharePoint 2007 databases via this TechNet article: http://technet.microsoft.com/en-us/library/cc512725(office.12).aspx. Here are a few notes of my own in addition to the TechNet article:
- The article enlists various SharePoint services to be stopped before the databases are detached and the move is carried out. The article is correct in that it does not mention the “Windows SharePoint Services Web Application” as one of the services to be stopped on the front end servers. I wanted to put out an additional note of caution that the service should NEVER EVER be stopped or restarted. Doing so has the potential to delete any customizations that were deployed, including but not limited to web.config entries, assemblies deployed to GAC and so on. This can be disastrous particularly if you don’t have any backups that you can restore these customizations from.
- The article also mentions steps to back up and restore Shared Service Providers for the farm. One issue we faced here was that the SSPs were not getting restored. Further investigation revealed that this was due the Search service not getting correctly restarted. The solution was to rectify the search settings and perform the steps to restore the SSPs again. In addition when you restore the SSPs again, you will need to delete any corrupted SSPs that got restored previously and also delete the content databases for such SSPs that got restored as part of the previous restoration attempts.
That’s pretty much it. Good luck with your move!