SharePoint 2013 Upgrade Process

[dropcap][/dropcap] [dropcap][/dropcap]How to we get the SharePoint 2010 upgraded to 2013?

We do not have anymore inplace upgrade, so we need to bring the databases over to SharePoint 2013 Farm. So we need to have SharePoint 2013 farm built, services setup and server distribution before the upgrade.

What are the high level upgrade Stages?



What service applications can be upgraded?

Only a few of the service applications below can be upgraded.

  1. Managed Metadata
  2. Business Data Connectivity
  3. Secure Store
  4. Search Administration
  5. PerformancePoint
  6. User Profile – Profile, social and sync databases

How are the service applications upgraded?

Restore the database from 2010 farm and in required rename it while restoring to any new 2013 service app database naming convention. Then can use this database name while creating new service application either from CA or with


How can we upgrade upgrade Site Collections or Content databases?

This involves three steps: Get the databases restores in SQL server. Mount the content database associated with web application. Upgrade the site collection from the sites banner. Or upgrade the content database and the associated site collections with PowerShell.

While upgrading consider  – how are the cpu, memory and disk IO doing as the process running on the servers. Before we do the production upgrade we need to have an test or stage 2013 farm where we can run and note how long the upgrade can take will it help if we run the upgrade parallel. Upgrade performance is very crucial while planning for production upgrade.

We can upgrade as an administration all the content databases, and as a user they can upgrade their site collections by clicking on the upgrade banner.


We will see other detailed admin upgrade commands and considerations in the following post.

Recover Sharepoint 2013 databases from suspect mode.

This Post courtesy to: 
Original Post from:

I restarted my SharePoint server, opened Central Administration and encountered the following error:
Server Error in ‘/’ Application
Runtime Error
Description: An application error occurred on the server.
01 - SharePoint 2013 Server Error in Application
In order to troubleshoot this issue I had to check couple of thing:

  • Make sure SQL Server services are up and running
  • Make sure the IIS application pools are started
  • Review Windows logs and gather more information about the server. I noticed the following event:

SQL Database ‘SharePoint_Config’ on SQL Server instance ‘C4968397007′ not found. Additional error information from SQL Server is included below.
Cannot open database “SharePoint_Config” requested by the login. The login failed. Login failed for user ‘DC07SQLSvc’.

02.1 - Windows logs
This event made me suspect something is wrong with my SQL Server. I opened SQL Server management studio and noticed that some of my most critical SharePoint databases are not accessible and set to suspect mode. 02 - SharePoint 2013 databases are in Suspect mode
What is a suspect mode in SQL Server database?
Suspect mode might be caused by many reasons like unavailable or corrupted database files, hardware failure etc.
Don’t worry! This situation is reversible.
Here’s a quick guide of how to recover your SharePoint databases from suspect mode:
Open your SQL Server management studio and execute the following queries one after another:

  • Run the following query. sp_resetstatus command will turn off suspect flag on the database.

EXEC sp_resetstatus ‘SharePoint_Config’;

After executing this query you’ll see the following warning. Don’t worry, this doesn’t mean you did something wrong.
04 - SQL Server reset status of database warning

  • The next step is to set the database to an Emergency mode. This can be done by executing following query:


After executing this query your database should look like this:
06 - SharePoint_config database is set to emergency mode
Once we set the database to an Emergency mode it temporarily becomes a Read Only database.

  • Execute the following query in order to check the logical and physical integrity of the objects in the database.

DBCC checkdb(‘SharePoint_Config’)

  • To complete the process, run the following queries:

SharePoint_Config SET SINGLE_USER
DBCC CheckDB (‘SharePoint_Config’, REPAIR_ALLOW_DATA_LOSS)
DBCC CheckDB (‘SharePoint_Config’)

Repeat this action for each one of the affected databases.
09 - Everything is back to track
I ran some basic tests to make sure my SharePoint server is working properly again, looks like everything is back to track.

January 29th, 2013 | Author:  | Filed under: CloudShareDev / TestSharePoint | Tags: