[Today's post comes to us courtesy of Shawn Sullivan from Commercial Technical Support]

This post is an extension of Part Two of this series, where we are discussing how to migrate Companyweb with a larger content database to a SQL 2008 R2 Standard instance. In the last post we covered the configuration of the SQL instance on the Premium second server, which leaves us with the final steps of physically migrating the database to this server.

Note: At the end of this entire process, make sure you update the CNAME record for Companyweb in DNS to point to the SBS 2011 server. Otherwise your web client will try to contact the source server when you browse http://companyweb rather than the SBS 2011 server.

The three servers that will be involved in this process are:

• Source SBS Server: Where the old WSS 3.0 Companyweb site resides along with the content database that we intend to migrate, attached to Windows Internal Database.
• Server Two: The Windows 2008 R2 server now running the SQL 2008 R2 Standard instance that we installed in part two. We will be migrating the content database to this server.
• SBS 2011: Where Sharepoint 2010 Foundation is installed and where the new Companyweb site exists. We will connect this site to the database that is attached to Server Two.

The tasks that will be performed are:

1. Prepare the database:
   1. Run the Sharepoint preupgrade check against the Companyweb content database on the Source SBS Server.
   2. Backup the content database on the Source SBS Server using SQL Management Studio.
2. Move the database:
   1. Restore the SQL backup on Server Two to attach it into the full SQL instance.
3. Mount the database:
   1. Export the Fax Center from the content database installed by SBS 2011 Setup on the SBS 2011 server. Dismount this database from the Companyweb site.
   2. Mount the content database from Server Two onto the new Companyweb site using PowerShell on the SBS 2011 server.
   3. Import the Fax Center document library.

Prepare the database

In this example, the content database on my Source SBS Server is called ShareWebDB, which is the default name given to it by SBS 2008 setup. If there was an SBS 2003 server in the domain previously, the database could be named STS_<servername>_1. If you are unsure what the name of your content database is, you can find out what it is by running the following command:

“%ProgramFiles%\Common Files\Microsoft Shared\Web Server Extensions\12\BIN” stsadm –o enumcontentdbs –url http://Companyweb

Once you have the name, you are ready to back it up. If you haven’t already, install SQL Management Studio; you will need it during this process. At this point, proceed with the following:

1. Run the pre-upgrade checker to detect any issues that will block the migration of this database
   Note: You can ignore warnings about approaching or exceeding database size limit, since the ultimate target instance is SQL Standard with no size limits.
   Note: We are assuming you are performing this after-hours when no users are currently accessing Companyweb. To be on the safe side, I recommend stopping the Companyweb site on the source server at this point to prevent any modifications to the site content that will be lost.
2. Backup the database using SQL Management Studio
   1. Open SQL Management Studio and connect to \\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query
   2. Go to the properties of the content database, in this case ShareWebDB, right-click and choose Tasks > Back Up…
      
      
      
   3. Perform a Full backup of the Database to Disk and add the location to a removable drive you can take to Server Two and plug in.
      
      

Move the database

Now that you have the backup file on the removable drive, simply plug it in and then restore the file into the Sharepoint instance you created in part two on Server Two.

1. Launch SQL Management Studio on Server Two and connect to the Sharepoint instance <Servername>\SHAREPOINT
2. Right-click on Databases and choose Restore Database…
   
   
   
3. Choose From Device and select the location of your backup file. Enable the checkbox under Restore. Select the database under To database at the top and perform the restore.
   
   

Mount the database

The remainder of these steps will be taken on the SBS 2011 server. At this point we are essentially swapping the new content database for the old one that contains the site that we want to migrate. Although there is no user data yet in the new content database, it does contain the SBS 2011 Fax Center library, which we will want to keep. To do this, we’ll first export it before dismounting the new content database:

1. Click Start > All Programs > Microsoft SharePoint 2010 Products and launch the Sharepoint 2010 Management Shell as administrator.
2. Run the following command to export the Fax Center library to a backup file:
   export-spweb http://companyweb -itemurl /fax%20center/forms/allitems.aspx -path c:\faxcenterbackup.cmp

We are now ready to swap the database. This involves dismounting the one attached to the local SQL instance and mounting the one attached to the SQL server on the network:

1. From the same shell as above, run the following command to dismount the current blank database:
   get-spcontentdatabase | dismount-spcontentdatabase
2. Then run the following command to mount the database attached in Server Two:
   Mount-spcontentdatabase –webapplication http://companyweb –databaseserver <servername> -name <databasename>
   Replace <servername> and <databasename> with the actual names, see example below
   
   

Finally, import the Fax Center library backup into the migrated database:

1. From the same shell as above, run the following command:
   import-spweb https://companyweb –path c:\faxcenterbackup.cmp
2. Browse http://companyweb to ensure you now have a Fax Center library available on the left side of the homepage.

After all of this, you will have a functioning Companyweb site on the SBS 2011 server that will look exactly like it did on the source server. You can use the Visual Upgrade feature in Sharepoint 2010 to update the look and feel, however you should properly plan for this especially if you have made customizations to your site that could be affected. For more information, see http://technet.microsoft.com/en-us/library/ff607998.aspx