My project this week has been migrating a system from SharePoint 2003 to SharePoint 2007 - like many things in SharePoint, this is something that is either very easy or very hard.

The first challenge was getting prescan to work. Prescan kept reporting that SharePoint 2003 SP2 was not installed, even though it was. Turns out that as well as having SP2 installed you need to upgrade/extend all the web applications with that version. It also doesn't like the presence of non-SharePoint web applications on the system.

The next issue was an exception in ParseInt32 when checking the system version. It turned out to be simple enough to fix, though I have no idea why the SystemVersion table contained "6.0.2.6568*" instead of "6.0.2.6568".

With prescan finally running without errors, it was time for the actual migration. The original plan was to just attach the database to a new 2007 server, but that was not an option once we discovered that the database was 30GB larger than the hard drive on the new server - everything would have to be done locally.

After installing 2007 on the 2003 server and selecting gradual upgrade, my first attempt at migration was to attach the 2003 database to 2007 and do database migration with an in place upgrade. This appeared to work quite nicely - the process completed in about 20 minutes - until I tried to access the site. All the data was copied, but nothing had a url and the site collections list was empty.

With in place upgrade ruled out, it was back to doing gradual upgrade of individual sites. All the references I could find on doing this with large sites (the biggest single site being 30GB) just said to use database migration instead.

Gradual migration works by copying everything from the 2003 database into a temp database, performing an in place upgrade on that, then copying everything into the 2007 database. On small sites it's great - All but 5 of the site collections were under 2GB and migrated without problems. On larger sites it uses huge amounts of disk space (maybe 5 times the database size), takes hours to run, and may timeout on some operations.

The first timeout came when migrating a couple of 2GB site collections. This one was in DropFullTextSearch. Reflector led me to sp_fulltext_database and references to needing to reinstall windows. Fortunately restarting the search service seemed to be enough - instead of timing out after 30 minutes, the next run completed in 3 seconds.

Next was the last site, the 30GB one.  The timeout came in copying data to the temp database. I found a technet post with instructions to pregrow the temp database transaction log - it probably improved performance, but not enough to stop the next run timing out as well. When copying the Docs table, the upgrade process detects that it is full of 50MB blobs and extends the timeout to a couple of days. When copying the DocVersions table it doesn't do this, and leaves the timeout at the default 30 minutes. Although it's possible a service pack fixes this, I opted for the quick solution - removing all document versions.

To do this I renamed the DocVersions table in the 2003 database with sp_rename and recreated it - I could have deleted it, but this way it can be restored quickly if necessary.

Without the versions, migration completed successfully and as an added advantage the database was down to 24GB, which should make things easier to get onto the new server.