Clean up an environment before upgrade (SharePoint Foundation 2010)
Applies to: SharePoint Foundation 2010
Topic Last Modified: 2011-09-12
Before you begin upgrading from Windows SharePoint Services 3.0 to Microsoft SharePoint Foundation 2010, you should make sure that your environment is functioning in a healthy state and that you clean up any content that you do not have to upgrade. You can also take the time to remove or rearrange content so that you will have the structure that you want after you perform the upgrade.
In this article:
Many of these items can be removed or repaired by using Stsadm.exe commands.
|To run the Stsadm command-line tool, you must be a member of the Administrators group on the local computer.|
You do not want to upgrade content that you do not have to keep. If it has been unused for a long time and will not be needed in the future, back it up, and then delete it to free storage and administrative resources, improve upgrade performance, and reduce upgrade risk. Be sure to communicate with site owners or organizational contacts regarding the site status — you want to make sure that the site is not needed before you delete it (for example, you do not want to delete sites that are required for compliance, such as emergency procedures, even though they may not be updated frequently).
For more information about how to delete site collections and subwebs, see:
By default, large list query throttling is applied after an upgrade to SharePoint Foundation 2010. If a list is very large, and users use a view or perform a query that exceeds the limit or throttling threshold, the view or query will not be permitted. Check any large lists in your environment and have the site owner or list owner address the issue before upgrade. For example, they can create indexed columns by using filtered views, organize items into folders, set an item limit on the page for a large view, or use an external list. For more information about how to address issues with large lists, see Manage lists and libraries with many items (http://go.microsoft.com/fwlink/p/?LinkId=182370) on Office Online.
If you have 5,000 or more site collections in a database, consider breaking them out into multiple databases. In Windows SharePoint Services 3.0, there was a default warning at 9,000 site collections and a hard limit at 15,000 site collections. In SharePoint Foundation 2010, these values change to 2,000 site collections for the warning and 5,000 site collections for the limit. To avoid errors during upgrade or broken sites after upgrade, we recommend that you move some site collections into separate databases. If you have multiple content databases, you can also speed up your upgrade process by upgrading multiple databases in parallel.
For more information about moving site collections to a new database, see Move site collections to a new database (split a content database) (Windows SharePoint Services 3.0).
Using item-level permissions frequently can result in large access control list (ACL) entries, which can in turn create performance problems on your servers. For information about this issue and for tips on how to handle lots of users, see Knowledge Base Article 953132: How to add lots of users to a site, to a list, or to a document library in Windows SharePoint Services 3.0 and in SharePoint Server 2007 (http://go.microsoft.com/fwlink/p/?LinkId=182327).
Large numbers of document versions can slow down an upgrade significantly. If you do not have to keep multiple versions, you can have users delete them manually or use the object model to find and remove them. For more information about how to programmatically remove extraneous versions, see Versions Web Service (http://go.microsoft.com/fwlink/p/?LinkId=182330) on MSDN.
First, verify that no sites are using the template, feature, or Web Part. You can use the pre-upgrade checker (Stsadm -o preupgradecheck) and the Stsadm -o EnumAllWebs operation to identify these customizations in your environment. Both of these operations were updated in the October 2009 Cumulative Update (CU) and now identify Web Parts, features, event handlers, and setup files that are being used in your environment. The pre-upgrade checker specifies which server-side files exist in your environment and how many times they are used. The EnumAllWebs command specifies which files are used by which sites.
For more information about how to identify customizations in your environment, see Use a trial upgrade to find potential issues (SharePoint Foundation 2010). If customizations are not being used, delete them. For more information about how to manage these kinds of customizations, see Features and Templates (http://go.microsoft.com/fwlink/p/?LinkId=182338) and Solutions and Web Part Packages (http://go.microsoft.com/fwlink/p/?LinkId=182332) on MSDN.
Make sure that you repair any issues in your databases or site content before you upgrade. In particular, check the following items:
Check databases for corrupted data
Clean up your databases to remove any orphaned sites or other corrupted data, such as a corrupted list. Consider defragmenting if you have removed sites or subsites from the database. For more information, see:
Check databases for duplicate or orphaned site collections
Make sure that site collections exist in only one content database. Occasionally, site collections can leave behind duplicate or orphaned references in old content databases if they are moved to new ones, or if a duplicate copy of a database was attached to the farm, or if there was an error when a site collection was provisioned. If a site collection is referenced in more than one content database or there is more than one instance of the site collection in a content database, it can cause issues when you upgrade by using the database attach upgrade method. If you upgrade a duplicate version of the site collection first, the site map in your configuration database might end up pointing to that version of the site rather than the current version.
Before you upgrade, use the pre-upgrade checker tool to identify all site collections and look for any duplicate or orphaned sites – any sites with the same URL or the same GUID as another site. For more information, see Run the pre-upgrade checker (SharePoint Foundation 2010). Also, use the enumallwebs operation in Stsadm.exe to find out which sites are in which content databases and compare the results. For more information, see Enumallwebs: Stsadm operation (Windows SharePoint Services). If you find duplicate or orphaned sites, you can use the deletesite operation in Stsadm.exe to remove the duplicate or orphaned sites from the database. To delete a site from a specific content database, use the following command:
Stsadm -o deletesite -force -siteid <SiteID> -database <databasename> -databaseserver <Servername>
For more information, see Deletesite: Stsadm operation (Windows SharePoint Services).
If you want to make structural changes to your environment, such as moving site collections around or changing how your databases are allocated, you can use the following methods:
Stsadm -o mergecontentdbs Use this to move site collections between databases. Upgrade is most efficient when databases contain similar data. Therefore, it is best if any site collections that share a content database are similar types. You can also use this operation to divide large databases if they contain multiple site collections. This can also help increase upgrade efficiency.
For more information, see Mergecontentdbs: Stsadm operation (Windows SharePoint Services).
Export and import sites Use this method to move subwebs or site collections within a farm or between farms. For more information, see Import and export: Stsadm operations (Windows SharePoint Services).