While I've performed and spoken on SharePoint 2007 to 2010 upgrades for quite some time now, recently we have become involved in a number of large migration projects for corporate clients. One of the bigger challenges in these upgrades has been identifying the features required for the sites in 2010, and determining a strategy for supporting them.
When we are doing 2010 upgrades, we generally recommend taking a content database attach approach to the upgrade. I'm not a fan on in place upgrades, due to the fact that we don't know the health of the 2007 farm, and we genreally don't want to bring that legacy of potential issues with us through the upgrade. One of the main reasons for doing the upgrade (aside from getting to 2010) is to get a clean, well-built, and well-documented 2010 environment to work in, which means a fresh build.
To determine the features needed, we will often do a the following PowerShell command to test the upgrade.
Test-SPContentDatabase -name dbName -webapplication siteUrl
This will generate the same upgrade error log as actually attaching the content database, and we can review that to determine the missing features. When we are ready to actually attach the databse, we can do that with the following:
Mount-SPContentDatabase -name dbName -webapplication siteUrl
To review the errors and warnings from a number of content database attaches, do the following:
Go to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\LOGS folder
Copy the relevant Upgrade...-error.log files to an empty temp folder
Use Visual Studio or SQL Management Studio to do a Find in Files of [ERROR] or [WARNING], and find all files. This will give you an output of all the error or warning lines in all the error logs
Once we have tested or performed the upgrade, the challenge is determining the features needed. The upgrade error log simply reports the missing feature IDs, not what they actually are. To determine the features themselves, we use one of two techniques.
The first technique involves accessing the 2007 production farm. We perform these steps:
Go to the C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\FEATURES folder
- Use Visual Studio or SQL Management Studio to do a Find in Files of the desired feature ID
- Use the folder name to identify the feature name
An alternative technique involves having a repository of all the WSP solution files used on the production farm. With those perform the following:
Copy the WSP files to a temp location
Open a command prompt to that location
Run rename *.wsp *.cab to rename all the WSP files to CAB files
Open each CAB file and extract the contents to a sub-folder of the same name
Use Visual Studio or SQL Management Studio to do a Find in Files of the desired feature ID
Use the folder name to identify the feature name