I wanted to blog about this for little while but could not find time earlier. At livepoint we have developed our own technique for migrating from SPS 2003 to MOSS 2007 content that allows customers to minimise risk during migration.
First, let's look quickly at the recommended migration strategies that Microsoft promote:
a. In place - basically run the upgrade routine on your 2003 environment and pray for it to work.
b. Gradual - this one is a bit more controlled but requires more space. basically you run 2003 and 2007 side by side and migrate site collections 1 at at time (or multiple). the issue is that your production environment suddenly gets "polluted" with 2007 and there is no way back in case you want to roll back.
c. Database attachment - this one is a lot of work and I have not tried it myself. Basically, take the content databases and then attach them to a new 2007 environment. The good thing about this is that your production environment is safe while you are doing the upgrade... but it can take you a long time to finalize the upgrade and so the prod 2003 environment needs to be frozen... the site collections that live in the content database that you are migrating.
These are the pros and cons compared:
The problem?
Well as you know medium to large enterprises are very careful with installing "stuff" on their production servers. So if they have SharePoint 2003 on their production server they will be against touching/ modifying/ compromising it in any way, shape or form their production data. So the first 2 migration options are out. The only left is the content db migration, but this one requires more manual steps and can be difficult.
livePoint's method
We have used a method where we use a migration server to stage in gradually site collections or sub sites and then restore them in a new production environment. as you can see from the diagram, the 2003 production is untouched.
You must configure the staging server (the intermediate migration server) in a specific way so that future migrations can still be performed on this server.
This is how we do it:
We extensively use echo for SharePoint to fix migration after the fact, tasks such as reapplying themes, resetting pages back to a site definition, updating links (due to a server/url move), fixing up infopath templates, uploading new content, migrating content from 2003 in a custom fashion, etc.
Even when we perform an in place or gradual upgrade for customers that require a quicker migration and can easily restore a server image to rollback the migration.
In most cases, we run through a migration of some site collections or sub sites to ensure that on "migration day" there are no surprises. This allows us to document and identify potential issues and rectify them prior to go live.
The benefits
1. Reduced risk - because the clients production environment (2003) remains intact and a proof of migration is carried out.
2. Reduced downtime - because we can migrate 1 site collection at a time. we can even migrate subsites at a time if we needed to.
All of the above allows you to achieve a "like for like" migration. However, we can achieve a more granular and customised migration using echo as well, more on that in a later post.
You can also look up the blog post on our livepoint public team blog for other migration items:
http://blogs.livepoint.com.au/Lists/Posts/Post.aspx?ID=2