In Microsoft Windows SharePoint Services 3.0, sites and parts of sites such as lists, list items, and folders can be migrated to other Windows SharePoint Services 3.0 sites. These other sites can be running on the same front-end Web server as the original site, on different front-end Web servers in the same farm, or on front-end Web servers in a completely different deployment of Windows SharePoint Services 3.0. Different permissions are required for different methods of migrating sites.
If you are the owner or administrator of a site collection, you can complete some migration tasks. Other site owners and designers can use this topic to understand the migration process and provide input about migrating their sites. For information about migration for server administrators, see Help on the Central Administration pages or the Windows SharePoint Services pages on the Microsoft TechNet Web site.
Methods for migration
Windows SharePoint Services 3.0 provides different ways to migrate site collections, sites, or any combination of objects within a site to another SharePoint Web application that is extended with Windows SharePoint Services 3.0. Migration applies to moving objects from Windows SharePoint Services 3.0 to Windows SharePoint Services 3.0 only. You cannot migrate sites, content, or any other object from earlier versions of Windows SharePoint Services to Windows SharePoint Services 3.0. For information about moving from one version to another, see Upgrade considerations.
The following table describes different methods for migrating content.
Note
The Miminum permissions column in the following table shows the permissions that are required for each migration method. If you do not have the required permissions, ask the appropriate team member to either grant the required permissions to you or perform the migration for you.
| Method | Comment | Minimum permissions |
|---|
| Use the –o backup and –o restore operations of the Stsadm.exe command-line tool. | This is the best option for migrating an entire site collection, because it is the only method that migrates workflows, alerts, and metadata at the site collection level. | Member of the local Administrators group or members of the Farm Administrators group at the Central Administration level |
| Use the Perform a backup and Restore from backup links on the Operations page in Central Administration. | This is the easiest way to migrate individual sites. | Member of the Farm Administrators group at the Central Administration level |
| Use the Windows SharePoint Services object model. | This is a new method in Windows SharePoint Services 3.0 and the most flexible. The migration-related application programming interfaces (APIs) in the object model can be used to migrate sites and any combination of objects below the site level. | Site collection administrator with appropriate permissions to read objects being migrated and permissions to change objects in the site to which you are migrating |
| Use a Web page editor compatible with Windows SharePoint Services, such as Microsoft Office SharePoint Designer 2007. | Only entire Web sites can be migrated. Note that the globally unique identifiers (GUIDs) are not migrated for any objects, which means that all migrated objects will not be globally unique. | Site collection administrator with appropriate permissions to read objects being migrated and permissions to change objects in the site to which you are migrating |
Migration process (object model)
The Windows SharePoint Services object model can be used to migrate objects within the same Web server, across Web servers in same server farm, or across server farms. This section describes a typical scenario for using the object model to migrate sites and other objects from a staging server to a production server. Using the object model requires someone who is a server administrator on both the staging server and the production server. However, understanding this migration scenario at a high level might be helpful to site owners, so they can collaborate with the person who is performing the migration. In this scenario, as shown in the following illustration, the staging server is used to create and test the changes to a company's SharePoint sites. After the changes are tested, the changes are migrated to the production server, where users can access the site.
Note
To use the object model for migrating sites and other objects from the staging server to the production server, you must have the appropriate permissions (listed in the table above) on both the staging server and production server. If you do not have the minimum required permissions, ask your server administrator to either grant them to you or perform the migration for you.
The server administrator logs on to the staging server and writes and runs the script that accesses the object model that is running on the staging server. The script that is running on the staging server creates the migration package in the form of a .cab file on a file share.
Note
The person who is creating this .cab file must have write permissions, and the person who is importing this .cab file must have read permissions on this file share.
The server administrator logs on to the production server and uses the migration-related APIs to deploy the migration package on the production server.
After the package is migrated to the production server, the server administrator verifies that the site migrated properly. This includes checking links, verifying security settings, and verifying the functionality of Web Parts.
Because the object model can be used to select any combination of objects that you want, from the site level and below, it can be used to migrate only the items that have been changed on the source server.