Clean up an environment before an upgrade to SharePoint 2013

Artykuł
01/26/2023

APPLIES TO: yes-img-13 2013 no-img-16 2016 no-img-19 2019 no-img-se Subscription Edition no-img-sop SharePoint in Microsoft 365

Before you start to upgrade from SharePoint 2010 Products to SharePoint 2013, you should make sure that your environment is functioning in a healthy state and that you clean up any content that you don't have to upgrade. You can also take the time to remove or rearrange content so that you'll have the structure that you want after you perform the upgrade.

Items to clean up

Many of these items can be removed or repaired by using Stsadm command-line tool or PowerShell cmdlets.

Important

To use the Stsadm command-line tool, you must be a member of the Administrators group on the local computer. > To use PowerShell cmdlets in the SharePoint Management Shell, you must have the following memberships: > securityadmin fixed server role on the SQL Server instance. > db_owner fixed database role on all databases that are to be updated. > Administrators group on the server on which you are running the PowerShell cmdlets.

Delete unused or underused site collections and subwebs

You don't want to upgrade content that you don't have to keep. If it was unused for a long time and isn't 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 isn't needed before you delete it (for example, you don't want to delete sites that are required for compliance, such as emergency procedures, even though they may not be frequently updated).

For more information about how to delete site collections and subwebs, see the following articles:

Check large lists (lists with lots of data)

By default, large list query throttling is turned on in SharePoint 2010 Products. This behavior hasn't changed in SharePoint 2013. 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 won't be permitted. If you're upgrading content from the server products in the Office 2007 release, check any large lists and have the site owner or list owner address the issue. For example, they can create indexed columns with 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 large list throttling and how to address issues with large lists, see Manage lists and libraries with many items.

Delete excess columns from wide lists (lists with too many columns) or remove wide lists

Wide lists are lists with more columns than fit in a single rowspan in the content database. During upgrade, the underlying storage in the database is changed to a sparse table structure, and a very wide list can cause upgrade to fail. Use the Test-SPContentDatabase command in PowerShell to look for wide lists in the content databases and then remove excess columns, or remove the wide list before you upgrade.

For more information about maximum column sizes in a list, see Column limits.

Consider moving site collections into separate databases

If you've 5,000 or more site collections in a database, consider breaking them out into multiple databases. In SharePoint 2010 Products, there was a default warning at 9,000 site collections and a hard limit at 15,000 site collections. In SharePoint 2013, 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 an upgrade process by upgrading multiple databases in parallel.

For more information about site collection limits, see Content database limits. For more information about how to move site collections to a new database, see Move site collections between databases in SharePoint Server.

Remove extraneous document versions

Large numbers of document versions can slow down an upgrade significantly. If you don't 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 on MSDN.

Remove unused templates, features, and Web Parts

First, verify that no sites are using the template, feature, or Web Part. You can use the Stsadm - EnumAllWebs operation with the - includefeatures and - includewebparts parameters to identify these customizations in your environment. This operation identifies Web Parts, features, event handlers, and setup files that are being used in your environment. The EnumAllWebs command also specifies which files are used by which sites. Changes were made to the EnumAllWebs command in the February 2011 Cumulative update to make it return both site collection and web-level features. For more information, and to get the cumulative update, see Description of the SharePoint Foundation 2010 cumulative update package (SharePoint Foundation server-package): March 3, 2011.

You can remove a feature during site collection upgrade. Simple features also can be removed by deprecating them in the template. You can use feature upgrade to remove more complex features. For more information, see Upgrading Features and Feature Upgrade Overview on MSDN.

For more information about how to identify customizations in your environment, see Use a trial upgrade to SharePoint 2013 to find potential issues. If customizations aren't being used, delete them. For more information about how to manage these kinds of customizations, see Features and Templates and Solutions and Web Part Packages on MSDN.

Remove PowerPoint Broadcast sites

These sites and site templates aren't available in SharePoint 2013 because the Office Online Server is now installed separately from the SharePoint 2013 environment. Sites based on these templates won't work in SharePoint 2013. Remove these types of sites before you upgrade.

You can use the Get-SPSite PowerShell command together with the following options to find these sites:

Get-SPSite | Where-Object{$_.RootWeb.Template -eq "PowerPointBroadcast#0"}

This will return all sites that use that template.

You can also use the Get-SPSite and Remove-SPSite PowerShell commands together with the following options to remove these sites:

Get-SPSite | Where-Object{$_.RootWeb.Template -eq "PowerPointBroadcast#0"} | Remove-SPSite

Be sure to back up these sites before you remove them. For more information, see Get-SPSite and Remove-SPSite.

Remove FAST Search Center sites

You can't upgrade FAST Search Center sites to the 2013 experience. Existing FAST Search Center sites can continue to work in 2010 mode after upgrade. If you want the new functionality, you must create new Enterprise Search Center sites in 2013 mode.

Finish Visual Upgrades in SharePoint 2010 Products

During an upgrade from the server products in the Office 2007 release to SharePoint 2010 Products, you could allow site owners to use Visual Upgrade to keep sites in the old experience on the upgraded environment. When you upgrade to SharePoint 2013, all sites that are still in the old experience in SharePoint 2010 Products are automatically upgraded to the 2010 experience. If you want the opportunity to address any issues and review the sites before they're switched to the new experience, upgrade them to the new experience in your SharePoint 2010 Products environment and review them before you upgrade them to SharePoint 2013. We recommend that you finish visual upgrades before you upgrade to SharePoint 2013. Finishing visual upgrades before you upgrade provides the following benefits:

You can address issues while you still have the server products in the Office 2007 release components available.
You can have users be involved in reviewing and fixing issues in their sites.
You can roll back to the old experience temporarily if it's necessary. You can't roll back when you are in the SharePoint 2013 experience.
You avoid adding potential errors to the upgrade process. The fewer operations occurring during upgrade, the better. Trying to troubleshoot errors is more difficult when you have more processes involved. And users might think that upgrade has caused an issue when it's really the experience changing to the new version. If you have an issue with how the site interface is displaying, how will you know whether it's an old issue from the site that was forced through visual upgrade, a problem with the 2010 mode in SharePoint 2013, or a problem with a new CSS file?

To check for sites in the old experience, on the SharePoint 2010 Products environment, you can use the Get-SPSite PowerShell command.

To check for and upgrade sites still in the old experience in the SharePoint 2010 Products environment by using PowerShell

Verify that you have the following memberships:

securityadmin fixed server role on the SQL Server instance.
db_owner fixed database role on all databases that are to be updated.
Administrators group on the server on which you're running the PowerShell cmdlets.

An administrator can use the Add-SPShellAdmin cmdlet to grant permissions to use SharePoint 2013 cmdlets.

Note

If you do not have permissions, contact your Setup administrator or SQL Server administrator to request permissions. For more information about PowerShell permissions, see Add-SPShellAdmin.

On the Start menu, click All Programs.
Click Microsoft SharePoint 2010 Products.
Click SharePoint 2010 Management Shell.
At the PowerShell command prompt, type the following command to return all site collections that are in or have subwebs in the old experience:

Get-SPSite | ForEach-Object{$_.GetVisualReport()}

At the PowerShell command prompt, type the following command to upgrade those sites to the new experience:

Get-SPSite | ForEach-Object{$_.VisualUpgradeWebs()}

For more information, see Get-SPSite and Manage visual upgrade (SharePoint Server 2010).

Repair data issues

Make sure that you repair all 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:
- Databaserepair: Stsadm operation
- Forcedeletelist: Stsadm operation
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're moved to new databases, or if a 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's 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 instead of the current version.

Before you upgrade, use the Enumallwebs operation in stsadm command-line tool to discover which sites are in which content databases and compare the results. Also, examine each site collection in the results and check whether it's listed as missing in the site map. Being listed as missing indicates that it is an orphaned site. For more information, see Enumallwebs: Stsadm operation. If you find duplicate or orphaned sites, you can use the Remove-SPSite cmdlet in PowerShell to remove the duplicate or orphaned sites from the database.

For more information, see Remove-SPSite.
Check variations

In publishing environments, check for any variations that must be fixed. For more information, see Variationsfixuptool: Stsadm operation.

How to make structural changes

To make structural changes to your environment, such as moving site collections or changing how your databases are allocated, you can use the following methods:

Move-SPSite Use this to move site collections between databases. If a database is very large or contains lots of site collections, you can move sites to address this to make upgrade more efficient. Also, you can move all collaboration sites into one database and all My Sites into another to make the upgrade administration easier for those different sets of sites. 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 Move-SPSite.
Export-SPWeb and Import-SPWeb Use this method to move subwebs or site collections inside a farm or between farms. For more information, see Export-SPWeb and Import-SPWeb.

Udostępnij za pośrednictwem