Update: Also read SharePoint 2010 to 2013 migration overview
Step 1 – Finding and moving the content databases ^
The easiest way to locate the content databases that are currently being utilized by our 2010 SharePoint installation is to open up the SharePoint Central Administration site. This is the administrative site used for the SharePoint backend and can be found in the Start menu.
Once you have opened the SharePoint Central Administration, click on the Manage content databases link.
When the new page loads, we are presented with all the content databases. In the case of our test server, we only have one content database named WSS_Content. We also see the current number of site collections we currently have.
There are many ways of backing up the content databases. Microsoft has several articles and tutorials dedicated to this subject. You can of course use any method you prefer and are comfortable with. For this article, I chose to use the Copy Database Wizard.
We’ll start out by opening the SQL Server Management Studio and connecting to the instance where the content databases are located. I’m directly on the SQL server so in this case it will be localhost.
Once connected, expand the Databases folder. Here we will find the WSS_Content database where our site collections are stored.
Right click on the database and hover over the Tasks option. A new fly out menu will pop up. We want to select the Copy Database… to start the wizard.
The first dialogue box of the Copy Database Wizard asks what source server the database we want to copy is located on. Note that you can use either Windows authentication or SQL server authentication. Select the appropriate one in accordance with your environment. Again, I am on the SQL server where our content database is, so I will just enter localhost and click Next >.
The next box asks where we want a copy of the database to be moved to. Here we have the same authentication options also. Enter the new SharePoint 2013 database server name and instance if any. The specific format is <server>\<instance>. Click Next >.
The transfer method depends on whether you can have downtime on your SharePoint 2010 site. There are two options: the detach and attach method and the SQL Management Object method. The former is much quicker and protects against changes during the copy. The downside is that it requires the database to go offline during the process. The latter method will leave the database online but will take significantly more time to move. When you’ve decided on the best method for your individual scenario, click Next >.
The next screen will ask what databases you want to move. The WSS_Content database should already be selected. If not, select it here. For this article, we will only be covering the content database. Click Next >.
The destination database name doesn’t necessarily matter. However, for the sake of simplicity, I leave the database the same name. You can append 2013, new, etc. if you wish. Leave the rest of the options as default and click Next >.
Click Next > again on the next dialogue box. We only need to move the logins and the rest are out of the scope of this article.
Leave the next box at the defaults also unless you have a specific reason to save the logs. Click Next >.
We want to run this copy immediately for the purpose of this article. Depending on when downtime is allowed or what copy method you chose, you may wish to schedule the copy at a later date and time. Click Next >.
The final window in the wizard gives us a rundown of what process will occur. After verifying the steps, click Finish.
When the wizard has completed copying the database, open the SQL Server Management Studio and connect to the server and instance you copied the database to. Verify that the database exists.
Step 2 – Creating the default application ^
In order to attach our newly copied database to the SharePoint 2013 installation, we need to create a default application. In order to do so, open Central Administration from the Start menu.
When the administrative page opens, select Application Management on the left.
Then click on Manage web applications in the right side of the page under the Web Applications heading.
From here we can add, delete, and manage the web applications on the SharePoint server. You’ll notice there is currently only one web application listed; the Central Administration site we are currently using. In the top left on the ribbon, click the New button.
A Create New Web Application modal box pops up. We don’t necessarily care about the options in this box for this particular tutorial. If you wish, give the options a look over to ensure compliance with your company. Don’t worry about the database. We will be deleting it shortly.
Another popup lets us know that the web application creation is currently in progress. Depending on the robustness of the server, this process can take quite a while.
When it has finally completed, the Application Created box is shown. We don’t wish to create any site collections at this point, so click Close.
Step 3 – Testing and mounting the content database ^
Although there are other ways to test and mount the content databases, by far the easiest and most efficient way is to use the management shell. Open it from the Windows Start menu now.
Testing the content database is extremely important and will tell us if we’re missing any installations on the new server. This can help us immensely by giving us troubleshooting information and letting us know whether these issues will not allow the upgrade process to complete. The command to test the database is as follows:
Test-SPContentDatabase -Name <database_name> -WebApplication http://<sharepoint_server_application>
In our case it will look as follows:
Next, after all issues have been resolved, we will mount the new content database. This process will also upgrade the database in order to allow SharePoint 2013 to use it. The command is very similar to the test command:
Mount-SPContentDatabse -Name <database_name> -WebApplication http://<sharepoint_server_application>
Depending on the size of the content database, you may have to wait several minutes for the upgrade to complete.
Upon completion, we are given some information about the process. If there were any issues or errors, they will be shown here.
Step 4 – Clean up and initialize ^
After the test and mount has gone smoothly, we will need to remove the content database SharePoint automatically created earlier. Open the Central Administration site from the Start menu.
Click on Application Management in the left when the site has loaded.
On the right under the Databases header, select Manage content databases.
This should be familiar as we did the same thing to find what content databases 2010 was using. Here you’ll see the database WSS_Content that we just tested and mounted. You’ll also see the automatically created content database WSS_Content_<string>. Click on the automatically created database.
About halfway down on the modal box that pops up, there is a tick box to remove the content database. Check the box and click OK.
We have successfully removed the unused content database. Now we must initialize the site to use the content database we copied over and upgraded. Go back to the Web Application Management page by clicking Application Management in the left.
Under the Web Applications header on the right, click Manage web applications.
Select SharePoint – 80 under the table header Name.
In the ribbon at the top of the site, click the Managed Paths button.
We’re going to add the “/” base path to the web application. This basically just reinitializes the web application so that it will use the content database we want to use. If you do not complete this step, your new SharePoint installation will just error out when you go to the site. Type “/” in the Path: textbox and click OK.
Our web application is now up and running! You’ll notice that it looks exactly the same as the 2010 installation. This is one of the great features in 2013 that has built upon the Visual Upgrade of 2010. The individual site collections can now be “visually upgraded” by their site collection administrators. This is extremely helpful if there are a lot of customizations to the site that will be broken during the visual upgrade process.
The content database is now upgraded and on our new SharePoint 2013 installation. We copied our content databases from the old SQL server to the new one and created a new web application to attach it to. We then tested and upgraded the content database and forced our new installation to use it.
This completes the three part series for upgrading from SharePoint 2010 to 2013. I hope you all have found it very informative and as always, if you have any questions or comments, I would be more than happy to respond in the comment section below. Thanks for reading!