Database Preparation
In order to execute a DB Attach upgrade to SharePoint 2010, an administrator will need an actual SharePoint content database to upgrade. One of the best ways to mitigate downtime during upgrade is using the DB Attach method, which allows the original farm to be kept up as long as possible. However, the downside is that during the time in which the new farm is being created, the content in the original farm may change significantly, which may require the content database to be re-added to the farm to account for the new content.
To avoid having the content change in the original farm, it is possible to set the database to Read-Only in SQL. This sets SharePoint 2007 into a reduced functionality mode, where the existing content is accessible, but no changes can be made. Once the upgrade is successful, users can resume working in the same place they left off. In the event that the upgrade is unsuccessful, nothing has been lost and users can still resume using the farm without any lost work. This process can then be repeated once any issues preventing a successful upgrade have been addressed.
Once the database is in Read-Only mode, create a backup of both the content database(s) and the SSP database(s) and restore the databases to the new SQL server (or to the same SQL server under different names if the same SQL server will be used in the new farm.)
Verify the Database
SharePoint 2010 features a PowerShell cmdlet to check the integrity of the database to allow administrators to address any issues before attaching the database to the farm. From the SharePoint 2010 Management Shell, run the following cmdlet to test the database:
Test-SPContentDatabase -Name <database name> -WebApplication <web application URL>
The cmdlet will verify that the settings and features referenced in the database are also available in the web application that will be associated with the database.
Migrating Customizations
Customizations to SharePoint 2007 can make the upgrade path a little more complicated than an out-of-the box migration, requiring a couple extra steps.
Site Definitions and Templates – If using custom site definitions, copy the new site definitions into site templates and install the upgrade definition file. A good way to continue using custom site templates is to create a new, blank site from the custom site template in SharePoint 2007, don’t give any user access to it, and perform the upgrade. Once the site is upgraded to SharePoint 2010, use that empty site as the source for creating a new site template, which will be based on the SharePoint 2010 framework and be packaged as a Solution file.
Custom CSS/Images/Branding – Copy over any custom CSS and images used in the SharePoint 2007 site to the new server so they can be referenced later.
Web Parts/Solutions/Features/Web Services – Install any solution files, features, web parts, and web services. If possible, moving any standalone Features into a Solution file will make the migration process smoother. 3rd party web parts and applications may prove problematic during the upgrade, depending on how they are written. If any problems arise, check with any web part or application authors or vendors to see if they have plans to upgrade their code to be compatible with SharePoint 2010.
12 Hive – In an in-place upgrade, a \14 folder is created alongside the \12 folder in the C:\Program Files\Common Files\Microsoft Shared\web server extensions\ directory. When using the DB Attach method on a fresh install of SharePoint 2010, no \12 directory will exist. If there is a possibility that files may need to be referenced from the \12 directory, copy it over from the original farm into the \web server extensions directory, alongside the \14 directory. SharePoint 2010 features a failback function in which the \14 directory is checked first for a file, then the \12 directory (if it exists) for any code that SharePoint is looking for. In an in-place upgrade, SharePoint 2007 is not actually uninstalled from the server, but won’t be available after the upgrade.
Web.config – the web.config file may need to be updated or changed to match new security requirements (for example, if using the claims-based authentication model offered in SharePoint 2010)
Assemblies/References – Any custom code assemblies need to now be assembled in Visual Studio as x64 (64-bit) or “any”, not as x86 (32-bit). There is no scenario in SharePoint 2010 that would warrant a 32-bit assembly, as SharePoint 2010 is 64-bit only. AssemblyBinding entries in the web.config file will use binding parameters in SharePoint 2010 to redirect references from the 12 hive to the 14 hive. Small assemblies will act as the 12 binaries and perform redirects to the correct 14 assemblies. This will use <bindingRedirect oldversion=”12.0.0.0” newversion=”14.0.0.0”> to redirect any assembly IDs from 12 to 14.
Attaching the Database
Once the database has been checked and verified, and all potential issues have been taken care of, it is time to attach the database to the new farm. The first step will be to create a new web application that will be used to access the content in the database. On the Central Administration home page, click Manage Web Applications, then click New in the Ribbon. Create the web application as normal. The associated content database will be deleted so it can be given an obvious name such as DELETE_THIS_DATABASE so it is easy to find in SQL. Do not create a top level site collection.
Now, the content database(s) can be attached to the web application. If there is more than one content database (i.e., it’s been split into multiple databases), start with the database that contains the root site collection. Use the following STSADM command to attach the database. Keep in mind that more than one database can be attached at the same time, SQL performance permitting. This can be scripted or started manually. This process can take some time depending on SQL performance and database size.
STSADM.exe –o addcontentdb –url <URL of Web App> -databasename <database name>
The progress of the attach can be viewed in Central Administration. From the home page, click Upgrade and Migration > Check Upgrade Status. The attach command will create two log files, one that is a complete log of the entire attach process and another log of errors. It is important to check the logs for errors and warnings and fix any issues that are found. If a test upgrade environment is available, or even during the testing phase of the upgrade, it may be worth attaching a database to look at the logs and see what kind of errors and warnings are found. Actually attaching the database to the farm can be another tool to find any issues with the upgrade.