SharePoint 2010 升级到 2013 step by step-CSDN博客

There is no longer an in-place upgrade and therefore this upgrade document will continue to be targeted toward the database attach method as prescribed by Microsoft. The SharePoint Server 2010 paradigm (Learn, Prepare, Test, Implement, and Validate) has now been consolidated into three sections: Prepare, Upgrade Databases, and Upgrade Sites.

A few more introductory notes:

Content Database upgrade is completely separate from site upgrades
Web Analytics should be disabled in the 2010 farm; it is now a part of Search
Web applications can be run in 2010 mode or 2013 mode
SharePoint 2013 uses Claims-based authentication only; upgraded sites will have to be converted
PowerPoint broadcast sites in the 2010 environment will have to be removed prior to migration
Workflow Auto Cleanup should be in the same state in both environments or workflow associations could be lost

Upgrade Methods and Downtime Mitigation

Read-only databases Use read-only databases to continue to provide read-only access to content during the upgrade process. For this approach, set the databases to read-only on the original farm while the upgrade is in progress on another farm. This method reduces perceived downtime for users.
Parallel database upgrades Attach and upgrade multiple databases at one time to speed up the upgrade process overall. The maximum number of parallel upgrades depends on the hardware. This results in faster overall upgrade times for the environment. Monitor the progress to make sure that the performance is acceptable, and for large databases, parallel upgrades can be slower than single upgrades.

Upgrade Paths

The tables below are the topology and product requirements for Upgrade to SharePoint 2010 versions.

Starting edition	Supported ending edition	Unsupported ending edition

SharePoint Server 2010, Standard edition	SharePoint Server 2013, Standard edition	SharePoint Server 2013, Enterprise edition You can convert to Enterprise edition after upgrade.
SharePoint Server 2010, Enterprise Edition	SharePoint Server 2013, Enterprise edition	SharePoint Server 2013, Standard edition.
SharePoint Server 2010, Trial edition	SharePoint Server 2013, Trial edition	SharePoint Server 2013, full product You can convert to the full product after upgrade.

Starting product	Supported ending products	Unsupported ending product
SharePoint Foundation 2010	SharePoint Foundation 2013 SharePoint Server 2013
SharePoint Foundation 2013	SharePoint Server 2013
SharePoint Server 2010	SharePoint Server 2013	SharePoint Foundation 2013
SharePoint Server 2013	SharePoint Server 2013	SharePoint Foundation 2013
Search Server 2010	SharePoint Server 2013 or Search Server 2013	SharePoint Foundation 2013
Project Server 2010 with SharePoint Server 2010, Enterprise Edition	Project Server 2013 with SharePoint Server 2013, Enterprise Edition

Supported topologies

For SharePoint 2013, the only upgrade method is the database-attach upgrade method. Because this method upgrades the databases instead of installing in place over an existing environment, attach the databases from a stand-alone installation to server farm (Complete) installation to expand the new environment.

Figure: Upgrade to either stand-alone or server farm (Complete) topologies

Hardware and Software Upgrades

Hardware Requirements

Component	Minimum requirement
Processor	64-bit, 4 cores for small deployments 64-bit, 8 cores for medium deployments
RAM	8 GB for small deployments 16 GB for medium deployments
Hard disk	80 GB for system drive

Software Requirements

Minimum requirements for a database server in a farm:

One of the following:
- The 64-bit edition of Microsoft SQL Server 2012.
- The 64-bit edition of SQL Server 2008 R2 Service Pack 1
The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter
The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)
FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)
Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM (KB 2759112)
Microsoft .NET Framework version 4.5

Minimum requirements for a single server with built-in database:

The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter
The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)
FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)
Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM (KB 2759112)
The Setup program installs the following prerequisite for a single server with built-in database:
- Microsoft SQL Server 2008 R2 SP1 – Express Edition
The Microsoft SharePoint Products Preparation Tool installs the following prerequisites for a single server with built-in database:
- Web Server (IIS) role
- Application Server role
- Microsoft .NET Framework version 4.5
- SQL Server 2008 R2 SP1 Native Client
- Microsoft WCF Data Services 5.0
- Microsoft Information Protection and Control Client (MSIPC)
- Microsoft Sync Framework Runtime v1.0 SP1 (x64)
- Windows Management Framework 3.0 which includes Windows PowerShell 3.0
- Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously named WIF 1.1)
- Windows Server AppFabric
- Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)

Minimum requirements for front-end web servers and application servers in a farm:

The 64-bit edition of Windows Server 2008 R2 Service Pack 1 (SP1) Standard, Enterprise, or Datacenter or the 64-bit edition of Windows Server 2012 Standard or Datacenter.
The SharePoint parsing process crashes in Windows Server 2008 R2 (KB 2554876)
FIX: IIS 7.5 configurations are not updated when you use the ServerManager class to commit configuration changes (KB 2708075)
Hotfix: ASP.NET (SharePoint) race condition in .NET 4.5 RTM (KB 2759112)
The Microsoft SharePoint Products Preparation Tool installs the following prerequisites for front-end web servers and application servers in a farm:
- Web Server (IIS) role
- Application Server role
- Microsoft .NET Framework version 4.5
- SQL Server 2008 R2 SP1 Native Client
- Microsoft WCF Data Services 5.0
- Microsoft Information Protection and Control Client (MSIPC)
- Microsoft Sync Framework Runtime v1.0 SP1 (x64)
- Windows Management Framework 3.0 which includes Windows PowerShell 3.0
- Windows Identity Foundation (WIF) 1.0 and Microsoft Identity Extensions (previously named WIF 1.1)
- Windows Server AppFabric
- Cumulative Update Package 1 for Microsoft AppFabric 1.1 for Windows Server (KB 2671763)

Document the Current SharePoint Server 2010 Environment

Use the Migration spreadsheet, if needed, or assessment document in the Migration site to gather inventory information from the existing SharePoint Server 2010 installation. A high-level list of information required is as follows:

Settings

Alternate access mappings
Authentication providers and authentication modes that are being used
Quota templates
Managed paths
Self-service site management settings
Incoming and outgoing e-mail settings
Customizations (solution packages, etc.)
Certificates

Environment

Number of sites
Number of databases
Number of users

Clean-Up

Check for and repair all database consistency errors
Turn off Web Analytics service application
Remove PowerPoint Broadcast Sites

Manage Customizations

Identify customizations in SharePoint 2010 environment

As part of an upgrade testing process, create an inventory of the server-side customizations in the SharePoint 2010 environment (solutions, features, Web Parts, event handlers, master pages, page layouts, CSS files, and so on). A few strategies are listed below for determining some of these customizations:

Use Stsadm –o enumallwebs (with includefeatures and includewebparts parameters) in the SharePoint 2010 Products environment to identify specific customizations in subsites
Use WinDiff (or other comparable product) to compare your production environment servers to your test farm servers
Check the web.config files for changes and look for custom controls
Use SPDiag to find deployed solutions.

Evaluate the customizations

The following table describes types of customizations and the kind of effect they can have during upgrade.

Category of customization	Types of customizations	Potential effect on upgrade
Visually-affecting	Master pages Themes Web Pages Web Parts Custom JavaScript Custom CSS files	Should not affect database upgrade. For site upgrades: likely to work well in 2010 mode, but need changes to work in 2013 mode. Test carefully in both modes.
Data structure affecting	Content types List types Web templates Site definitions	Can affect database upgrade if content or list type names conflict with new content or list types in the product, or if templates or definitions are missing.
Non-visually affecting	Web services Windows services HTTP handler HTTP module	Might not be compatible with SharePoint 2013. Test carefully to determine effect. Be prepared to remove or replace.

Use the following questions to help evaluate the customizations:

Is the customization still valuable?
- Does it serve a useful business need?
- Is it widely deployed and used?
- Does it do something that cannot be done with standard features in the product?
Is the customization well-designed?
- Is it built on supported, predefined site definitions?
- Does it follow best practices for customizations?
- Is it a supported kind of customization, or does it introduce risk into the environment?

Evaluate customizations, and think about the overall approach for upgrading the customizations. Choose from among these options:

Keep customizations and don’t upgrade the sites – The site can continue to run in 2010 mode in the upgraded environment. Use this approach to keep the same functionality. This will not take advantage of the features and capabilities that are available in the new version. Use this approach only temporarily – eventually the issue must be addressed (such as before an upgrade to the next version of the product).
Replace or redo the customizations – To use the new functionality, plan to redesign sites, or significantly change the information architecture, upgrade is the opportunity to start over with new features, a new look, or a new organization. When replacing or redoing customizations, take advantage of the new capabilities and change the design slightly, or move to a more manageable design.
Discard the customizations – Replace the customizations by using default functionality. Reset pages to the default site definitions and remove any Web Parts or features that will no longer be supported. The site collection health-checker checks for unghosted pages and can reset the pages to the default versions. If discarding any customizations, fix any issues that result from removing the customizations in the sites that used them. Use the customizations inventory to determine which sites require this kind of attention before or after upgrade.

Considerations for specific customizations

In addition to the overall decision about how to treat customizations during upgrade, examine specific types of customizations to determine whether any additional actions need to be performed to make them work in the upgraded environment.

The following table lists some common customizations and a recommendation for addressing that kind of customization.

Customization type	Recommendation
Site definition	Migrate sites to a supported, predefined site definition, then apply custom features by using solution deployment. Custom site definitions can continue to be used. There is no need to create a new site definition that is based on SharePoint 2013. However, a custom upgrade definition might have to be created in order to perform custom upgrade actions for the definition.
“Fabulous 40″ application templates	Microsoft is not creating new versions of these templates. Environments that contain sites based on these templates can be upgraded as long as the templates are installed..
Feature	Evaluate, then redesign or redeploy if it is necessary.
Workflows and server controls	Depends on the solution. Contact the vendor to discover whether there is an updated solution. If a workflow is compatible with the new version, redeploy.
Event handler	Most event handlers will continue to work without changes. However, if the code for the event handler makes calls to APIs which were deprecated, the handler will have to be rewritten and redeployed as a feature.
Managed paths (inclusions/exclusions)	Re-create inclusions to make sure all site collections under those paths can be accessed.
Themes	Re-create themes following the SharePoint 2013 theming guidance, or select a new theme available in SharePoint 2013.
Master pages and CSS files	Rework to accommodate the new user experience.
JavaScript	Test to determine whether any actions are required. In some cases, scripts will to be adjusted to work with the new page model. Verify that it works in both 2010 and 2013 modes.
Search provider or security trimmer	Test to determine whether any actions are required.
Web Parts	Test to determine whether any actions are required. Adjust the Web Parts to work with strict XHMTL mode. Test to verify that there have not been changes to any object models or Web services called from the Web Part. If a Web Part is located on a page but not in a Web Part Zone (so that it is, basically, HTML code embedded directly in a page), it will not work if reset to the default page template. There is a site collection health rule that will identify files in this status inside a site collection. There is a link from that rule to the page where they can reset to template.
Services	Test to determine whether any actions are required. Redesign or adjust code, as needed.
Authentication providers	Test to determine whether any actions are required. Redeploy the provider with the same provider name (exactly. This includes the letter case) on a test farm and make sure that it works correctly.
Custom search solutions that use SQL syntax	Rework to use FQL syntax and KQL syntax. Custom search solutions in SharePoint Server 2013 do not support SQL syntax. Search in SharePoint Server 2013 supports FQL syntax and KQL syntax for custom search solutions.

While reviewing customizations make sure that the environment is not using any features or elements that are deprecated. For example, Web Analytics from SharePoint 2010 Products are not available in SharePoint 2013 and should be turned off before upgrading. Also, SQL Server Search queries are not available in SharePoint 2013. Some methods of deploying customizations might require additional steps in SharePoint 2013. The following table lists methods of deploying customizations and any issues that you might encounter.

Deployment method	Recommendation
Customizations deployed as MSI files	Contact the vendor for updated files compatible with SharePoint 2013.
Manually deployed features, files, or changes	Re-deploy them to the equivalent directory in SharePoint 2013. However, consider packaging them into a deployable solution package for easier administration.
Sandbox solutions	No special steps. Sandbox solutions are upgraded with the content databases.
Solution packages	Redeploy to SharePoint 2013. Make sure and deploy it to the appropriate directory (/14 or /15), depending on the version.
Administrator-deployed form templates	Extract them from SharePoint Server 2010 and redeploy them to SharePoint Server 2013.

Install New Environments

Install the following on your farm servers:

Database servers: SQL Server 2008 R2 or SQL Server 2012

Web and Application servers: Install all prerequisites and then install SharePoint 2013 Products.

Install necessary language packs, and then run the PowerShell commands to create the Configuration and Admin Content databases, just as in SharePoint 2010. Run the SharePoint 2013 Configuration Wizard and select Configure Everything Myself, also just as in SharePoint 2010.

Configure service applications

Do not use the Farm Configuration Wizard to install the following service applications:

Business Data Connectivity service application
Managed Metadata service application
PerformancePoint Services service application
Search service application
Secure Store service application
User Profile service application

These service applications will be upgraded when their databases are upgraded.

Configure farm settings

Configure email settings, farm-level security and permission settings, blocked file types, usage and health data collection settings, and diagnostic logging settings.

Upgrade Databases

About the Database Upgrade Process

The paradigm has changed for the better in that Microsoft is stressing upgrade testing, finally, and not just a single test but multiple tests to vet all issues. While the production and QA environments were created in the initial step Microsoft recommends that temporary migration testing environments be created. However, unless restrictions are in place that prevent doing so, experience has shown that a QA environment can be used and rebuilt after testing and yields results comparable to the final upgrade.

ICC always recommends three environments: Production, Testing/QA, and Development. Depending on the scale of the development environment, of course, this environment can at least be used for rudimentary upgrade testing. The scale of typical development environments is too small to be considered for accurate analysis of the time or complexity that will be experienced in the final upgrade.

If development or QA environments are not available, the following will provide guidance on separate SharePoint 2013 installations that can be used on a temporary basis during the migration project.

Use virtualized environments
Make the test farm as similar as possible to the real farm (hardware, software, and available space)
Use the same URLs in the test farm as in the real farm
Use separate servers for SQL Server databases
Transfer all your settings and customizations to the test farm

Testing by using a virtualized environment, does not require much hardware. Replicate the environment by using just two servers that are running Hyper-V. One server has images for the front-end web servers and application servers, and the other server has images for the database servers.

Test the Migration Process

The database upgrade process for both the test and final migration is fundamentally the same.

Backup production databases – all or some, where applicable
- All Content Databases
- MySite Database
- BDC Database
- Managed Metadata Database
- Performance Point Database
- Secure Store Database
- Search Service Application Database
- User Profile Profile Database
- User Profile Social Database
- User Profile Sync Database
Restore Databases to the testing SQL instance

Using Windows Powershell create the required service applications to upgrade the databases
Create Web Applications
Apply Customizations
Use test-spcontentdatabase to find errors prior to upgrading

Test-SPContentDatabase -Name <String> -WebApplication <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-DatabaseCredentials <PSCredential>] [-ExtendedCheck <SwitchParameter>] [-ServerInstance <SPDatabaseServiceInstancePipeBind>] [-ShowLocation <SwitchParameter>] [-ShowRowCounts <SwitchParameter>]

Use mount-spcontentdatabase to upgrade the content databases (results below) and monitor the process in Central Administration

Mount-SPContentDatabase [-Name] <String> [-WebApplication] <SPWebApplicationPipeBind> [-AssignmentCollection <SPAssignmentCollection>] [-AssignNewDatabaseId <SwitchParameter>] [-ChangeSyncKnowledge <SwitchParameter>] [-ClearChangeLog <SwitchParameter>] [-Confirm [<SwitchParameter>]] [-DatabaseCredentials <PSCredential>] [-DatabaseServer <String>] [-MaxSiteCount <Int32>] [-NoB2BSiteUpgrade <SwitchParameter>] [-SkipIntegrityChecks <SwitchParameter>] [-WarningSiteCount <Int32>] [-WhatIf [<SwitchParameter>]]

From the last message in the output above it’s clear that the Web Application in the SharePoint 2013 environment is claims, but the Web Application in the database is not. Even this doesn’t block the upgrade. But the claims upgrade can take place at any time as shown below:

The initial load of the site in SharePoint 2010 mode before the Site Collection Upgrade takes place looks like this:

Upgrade Sites

Run Site Collection Health Checks

SharePoint 2013 includes a set of rules that run against a site collection to verify that it is working as expected. These rules are part of the site collection health checks. Run the health checks from the Site Settings page or by using Windows PowerShell.

When upgrading a site collection to SharePoint 2013, the first step in the process is to run the health checks.

Run the health checks manually to prepare for an upgrade. In addition, the health checks are run automatically in repair mode when upgrading a site collection. Also, the health checks can be run at any time to verify that a site is working as expected. The site collection pre-upgrade health checks examine a site collection and list potential upgrade issues, such as missing or unsupported elements. For example, the results itemize customized files so the custom file can be identified and reset to the default template in the site definition, if required. After running the checks, a report lists potential issues. The report also has information about how to address the issues.

The site collection health checker includes the following rules:

Rule name	Description	Rule ID
Customized Files	This rule checks for any files that were customized (or unghosted) in the site collection or subsites. When run in repair mode, it can reset the page to the default (reghost the file).	cd839b0d-9707-4950-8fac-f306cb920f6c
Missing Galleries	This rule checks for all default galleries and reports if any are missing from the site collection or subsites.	ee967197-ccbe-4c00-88e4-e6fab81145e1
Missing Site Templates	This rule checks to make sure that the template the site is based on is available and reports if any elements are missing.	5258ccf5-e7d6-4df7-b8ae-12fcc0513ebd
Unsupported Language Pack References	This rule checks to make sure that the language packs that are used by the site collection exist and are referenced correctly by the site collection.	99c946f7-5751-417c-89d3-b9c8bb2d1f66
Unsupported MUI References	This rule checks to make sure that the multi-user interface elements that are used by the site collection exist and are referenced correctly by the site collection.	6da06aab-c539-4e0d-b111-b1da4408859a

To run the health checks:

Site Collection Administrators can run the health check
On the Site Settings page for the site collection, in the Site Collection Administration section, click Site collection health checks

On the Run site collection health checks page, click Start checks
- A report lists all checked issues and issues that should be resolved

Resolve all issues, and then click Try it again to verify they are fixed

Alternatively, use Powershell cmdlets:

Test-SPSite -Identity <SiteURL> [-Rule <RuleID>]
Repair-SPSite -Identity <SiteURL> [-Rule <RuleID>]

Create an Upgrade Evaluation Site Collection

The Upgrade Evaluation Site Collection request and creation is an optional step.

Note about My Sites:
There are special considerations when upgrading for My Sites. (My Sites are not available in SharePoint Foundation 2013.) Make sure that the My Site Host site collection is upgraded before allowing users to access their individual My Sites in SharePoint Server 2013. This makes sure that the server software and database changes are complete so that users can upgrade their individual My Sites successfully. A user can upgrade his or her My Site by following the steps to upgrade a site collection later in this article, or a farm administrator can upgrade My Sites by using Windows PowerShell.

Site collection administrators can request previews of site collections; this is called an upgrade evaluation site collection. An upgrade evaluation site collection creates an upgraded version of the site in a new, separate copy of the site that is running on SharePoint 2013. Unlike visual upgrade in SharePoint Server 2010, the upgrade evaluation site collection is a complete copy of the site collection, separate from the original. Actions taken in the upgrade evaluation do not affect the original site.

When requesting an evaluation site collection, the request is added to a timer job (named “Create Upgrade Evaluation Site Collections”) which runs once a day. Of course, this timer job can be run on demand as was done for the screenshots in this section. Otherwise, an e-mail message will be sent to the site collection administrator when the upgrade evaluation site is available. This might take up to 24 hours. The message includes a link to the evaluation site. Upgrade evaluation site collections are set to automatically expire (after 30 days by default). If a site expires before evaluating the changes if finished, another request can be made for an upgrade evaluation site collection.

To request an upgrade evaluation site collection

Site collection administrators can make the request
On the Site Settings page for the site collection, in the Site Collection Administration section, click Site collection upgrade
On the Step up to SharePoint 2013 page, click Try a demo upgrade
- This option starts the process of generating an upgrade evaluation site collection.

In the Create Upgrade Evaluation Site Collection box, click Create Upgrade Evaluation Site Collection.

A request confirmation dialog opens
Click close to close the box.
An e-mail message will be sent when the upgrade evaluation is available. The e-mail message will contain a link to the site collection. Review the site and confirm that the site collection will look and behave as expected in the new user interface.

After reviewing the upgrade evaluation and making any necessary changes in the original site based on the evaluation, the site collection can be upgraded.

A request can also be made by a farm administrator using the following PowerShell cmdlet:

Request-SPUpgradeEvaluationSiteCollection -identity URL to site

All requests for evaluation sites are queued, even if served immediately. Server farm administrators can manage the queue to remove a site from the queue, add a site to the queue, or upgrade a site manually.

Server farm administrators can manage the queue in the following ways:

Determine site collections that are in the upgrade queue
Show the sites that are in the queue for a specific content database associated with a web application
Monitor all sites that are currently being upgraded
View the queue and filter it to show only the sites that are currently being upgraded for a specific content database
Add a site collection to the upgrade queue
Remove a site collection from the upgrade queue

To remove a site collection from the upgrade queue, stop the timer job, remove the site from the queue, and then restart the timer job to resume upgrade for the remaining sites in the queue. A site collection cannot be removed from the queue if it is currently being upgraded.

Some of the PowerShell cmdlets associated with Farm Administration:

View site collections in the queue

Get-SPSiteUpgradeSessionInfo -ContentDatabase <DatabaseName> -ShowInProgress

-ShowCompleted -ShowFailed |ft

View site collections being upgraded

Get-SPSiteUpgradeSessionInfo -ContentDatabase <DatabaseName> -ShowInProgress

See if a particular site collection is in the queue

Get-SPSiteUpgradeSessionInfo -Site <http://site>

Add a site collection to the queue

Upgrade-SPSite <http://site> -VersionUpgrade -QueueOnly

Remove a site collection from the queue

Remove-SPSiteUpgradeSessionInfo -Identity <URL>

Note: Throttling rules can be set by farm administrators using the Set-SPContentDatabase cmdlet with options to ensure the environment does not take a performance hit.

Upgrade a Site Collection

To upgrade a site collection

Verify that the user account that performs this procedure is a site collection administrator.
On the Site Settings page for the site collection, in the Site Collection Administration section, click Site collection upgrade.
On the Site Collection Upgrade page, click Upgrade this Site Collection.
This option starts the process of upgrading the site collection.
Click I’m ready to start the actual upgrade.

The site collection health checks are run automatically in repair mode before the upgrade starts. The results from the health checks are included in the upgrade log for the site collection. If there is an error, it must be addressed before continuing upgrade.

The upgrade starts, and the upgrade status page for the site collection is displayed. This page automatically updates while the upgrade is in progress and displays information about the process, such as the following:

Errors or warnings
When the upgrade started
Upgrade log file location – this is a very detailed log about every step of the upgrade

After the upgrade is complete, the upgrade status page is displayed in the new user interface with the message, Upgrade Completed Successfully.

Click Let’s see the new site to go to the home page.

About the TestSite site: The TestSite site is the development environment that was used to develop the site at http://team/migration. The master page and css files were customized from a team site with publishing. The site was migrated and upgraded without any customizations installed in the SharePoint 2013 environment and now work on the master/css files in the upgrade evaluation site. With only a few issues the migration worked smoothly and the end product loads without errors. Pretty smooth!

Validate the Site Collection Upgrade

To verify that upgrade has succeeded, check the upgrade status page for the site collection.

Site collection administrators can view the upgrade status page in Site Settings to verify that upgrade has succeeded for a site collection.

To view upgrade status in Site Settings

Verify that the user account that performs this procedure is a site collection administrator.
On the Site Settings page for the site collection, in the Site Collection Administration section, click Site collection upgrade.
On the Site Collection Upgrade page, click Review Site Collection Upgrade Status.

Farm administrators can upgrade a single site collection or all site collections in a content database using PowerShell cmdlets as follows:

Upgrade-SPSite <http://site>
-VersionUpgrade [-Unthrottled]
Get-SPSite -ContentDatabase <DBName>
-Limit All | Upgrade-SPSite -VersionUpgrade –QueueOnly

And view status for a site collection or content database upgrade:

Get-SPSiteUpgradeSessionInfo -Site <http://site>
Get-SPSiteUpgradeSessionInfo –ContentDatabase <DatabaseName>
-ShowInProgress -ShowCompleted -ShowFailed