Well, as promised quite a while ago I was finally able to get this accomplished for the client I am working with. But before I go in to the steps that I used let me re-iterate the situation.
My client has had a Team Sites box setup with WSS 2.0 for a while. This was mainly just for the use of team sites for projects and planning things. It didn't support the whole company, but made it possible for a team to work on a project/issue in a central place. The box was never meant to be a production box and never was it configured and administered in a production way.
With that said the WSS 2.0 implementation contained 4 top sites and a total of 141sites. The database that contained all of the data was in the range of 20GB on a SQL Server 2000 database server.
So on to the steps and lessons learned....
Step 1: Check Service Pack Level
The first thing to verify before you do anything is to check the service pack level of your current 2.0 SharePoint installation. I found that it was still running SP1 and had never been upgraded to SP2. This presented a huge problem. At a minimum your SharePoint 2.0 installation has to be at the SP2 level. If found this out when I had the database backed up and restored to my new database server and tried to attach it to MOSS 2007. It came back saying that the database was too old and couldn't be upgraded. So if you get a similar error message, double check the service pack level for your 2.0 installation.
Step 2: PreScan
With the installation of Services 3.0 or MOSS 2007 comes a nice little utility to help you pre scan the 2.0 install for things that might cause errors when you migrate. You can find this utility on your 2007 server under <%root%>\program files\common files\Microsoft Shared\web service extenstions\12\bin directory. Transfer the EXE to your 2.0 server and kick it off from the command line. The command line statement “Prescan /all” will start the utility and have it start enumerating all of the sites on the box.
When it is complete it will put a log file in to your Documents/Local Files/Temp directory with information as to what it found. It details any errors that it encountered, it details lists that it re-organized, and also will give you details on page customizations and the like. Verify that there are no errors, If there are, fix them before you do the migration. Rerun the prescan utility after repairing any errors to be sure that things have been rectified and are good for migration.
Step 3: Backup/Restore
I didn’t have the opportunity to do this part of the operation. I had a fellow DBA do this part for me, but it did take quite a while. The issues he encountered here was that every time he tried to transport the backup files from one server to the next it kept on corrupting. So the solution was to use a compression utility to zip up all of the data and then transport it. That seemed to do the trick.
Step 4: Create New SharePoint Web Application
Now if you have been working with and configuring SharePoint 2007 then more than likely this will be second nature to you, but there is one little step that is a bit different here. When you create a new web application usually it will default to create a new content database usually with a name like “WSS_Content_<GUID>”. If we were just going to create a new web app this would be fine, but we are looking to attach a copy of the old WSS 2.0 database to this web application. So, replace the defaulted name of the database to the name of the newly migrated and restored database from the WSS 2.0 and let it rip.
SharePoint will take over and create the web application, but instead of creating a new content database it will upgrade the 2.0 database to the correct schema that 2007 uses. Once that is done you should be able to access your content through the new url root. I did go through and verify that it did bring over all of the content as well as the security settings for the sites.
Step 4b: I don’t want a new SharePoint Web Application
Okay, so what if you don’t want a new web application? Well you can always do the same thing by attaching the migrated database to an existing web application on the 2007 box. You can do this either by the content databases interface in Central administration OR you can do it with STSADM. I would recommend the STSADM method for the only purpose that when you do the attaching and upgrade the process can take a bit of time and can possibly time out the Central Administration operation. The only issue I found with this process of attaching and upgrading is that if your 2.0 site structure had a top site (which most of all will) it will not be pulled in and overwrite the current site collection of the existing web application. At least, I found that the content at the old top site I had couldn’t be accessed. So I chose to go the path of Step 4 above.
The STSADM command line statement looks a bit like this: stsadm –o addcontentdb –url <web application url> -databasename <database name> [there other optional switches you can add on if you would like but this is the base execution].
Well, I hope that this has proved useful for anyone in the need to do this type of upgrade. Again, during this process I didn’t have to really mitigate any major errors or deal with any major customizations that might have been done to the 2.0 installation. I guess I was lucky in that respect, but with other sites that might have 3rd party web parts or other customized parts you might want to really proof out the process you will use to do the migration.
Happy Coding.
Michael