Migrate a Site Collection with Different Patch Level and User Accounts

I was recently asked to restore a site collection that was being hosted on an external provider’s network without any SharePoint patches installed. There were also some custom templates installed that had to be tested internally.

Bringing this site in took a little extra work. We couldn’t just restore the site collection backup into the regular production farm.

Update: – When I originally wrote this post I thought both servers had to be at the exact same patch level, but this is incorrect. The target server needs to be the same or greater.

To handle this, I went through the following steps:

Step 1 – Create a new farm with matching revision level (or greater)
The system I configured was a basic one server install of MOSS.

You can find your version number by migrating to any SharePoint site’s settings page (i.e. Site Actions, Site Settings). Here is a resource for matching your version level to the installed patch level: http://www.mindsharpblogs.com/penny/articles/481.aspx

Step 2 – Install any Customizations
Next you need to install any customizations such as custom or third party web parts, site templates (i.e. Fabulous 40 Templates)

Step 3 – Restore the Site Collection
Restore the site collection using STSADM’s restore command.

Step 4 – Migrate the site collection’s users
Next you will want to migrate the site collection’s user accounts to your internal accounts. This will ensure that user security, content ownership, and historical changes are maintained.

To migrate the users simply run the STSADM’s migrateuser command for each user.

NOTE: I later experienced an unexpected issue. While the migrateuser command moved user profiles, it did not update the mappings for the site collection administrators. Before you continue make sure you review and update the Site Collection Administrators group with valid internal accounts. If you don’t you will not be able to export the site collection or even run commands like Enumsites. The tools will return an Unknown User error because there is no longer a valid Site Collection Administrator.

Step 5 – Validate the site
Make sure that everything is the way it should be. Test your sites, review the content, and make sure that there are no other templates or pieces missing.

Step 6 – Install Patches
If it is not at the same level as your production server, install all of the Service Packs, Cumulative Updates, and KB patches to match your production environment. Most of those will require running the configuration wizard or pscofig afterward.

Step 7 – Backup the site collection
Run the STSADM’s backup command to export the content.

Step 8 – Restore the site collection to the production server
Restore the site collection using STSADM’s restore command.

3 Replies to “Migrate a Site Collection with Different Patch Level and User Accounts”

  1. It’s nice to see process for checking to make sure that everything is in order prior to releasing it back to the user base. Nice catch with regard to the site collection administrators or the site security – definitely something that’s typically overlooked. :)Out of curiousity though, why would you have to restore to a RTM version of MOSS? From everything I’ve found as long as the target MOSS installation is the same or greater version than the source, there isn’t an issue in restoring a site. Only if you try the reverse where your target is at a lesser version than the source. In which case you’re forced to break out your migration toolkit for moving data since it won’t restore at all, spawning a version error message on stsadm -o restore.

  2. I’ll need to go back and take another look at that. Restoring it directly to the production environment’s supported patch level will certainly save time since you would not need to roll back to a previous point in the VM.Putting it in this temporary environment allows you to validate the features, templates, and other customizations involved as well as migrate any user accounts.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: