Just a heads up it you ever need to migrate your databases onto another server. The config database of course goes first- which is configured when you run the STCW to add your servers back into the farm... no problems there.

 

Next you will probably go to reconfigure your content databases so they point to the new DB server (I assume you quiesed your farm, disconnected the members and moved all the DBs at the start).  One tip here is that you have to remove the old content DB's before you add the new ones otherwise the switchover won't take place (since you can't have two copies of the same content running at the same time).

 

So no problem with your web app content databases, but what about the content DB for Central Admin?  Well of course you have to follow the same pattern, but of course as soon as you remove this content DB, you lose the interface you are using... and thus you can't add the new one.  Don't bother trying to do the steps out of order or you'll just have three things to do without an interface rather than one.

 

What you have to do is use STSADM to add the DB on the new server back in.  Here's the syntax:

 

stsadm -o addcontentdb -url [url to central admin] -databasename [name of db] -databaseserver [sqlserver]

 

Note this is a good time to rename your admin content database if you don't like that GUID thrown on the end.

 

Don't forget to go back and start up your search services and recreate the search db's on the new server.  There might be a way of repointing these at DB copies as well, but in most cases I wouldn't bother... just create new ones and kick off a full crawl of all content sources.

 

If you need to move the ssp database as well, the best path is to use the "restore ssp" feature from the "create or configure shared services" view.  Choose restore, and put in the pointers to the copied database on the new sql server.  Once restored, you can delete your old one and check that the new one you created is properly associated with all of your web apps and that it is set as the default SSP for new ones.

 

I think that's it.  It's amazing I couldn't find better documentation or blog entries about doing this since it's probably going to be fairly common for people to install MOSS with the DB on the same machine, then later migrate the data tier off to another server as the first step to scale out.  Hopefully I didn't leave anything out... when I did this earlier today at a client we were also migrating sharepoint onto a new server as well, so we had to do a few more steps too that were related to that.