Upgrade from 2007 to 2010 error on custom web parts

Question

We have several SharePoint 2007 farms with several site collections in certain databases. The desire is to be able to migrate these 2007 site collections to our new 2010 farm envirionment. The best way to do this is the Database attach method.

However when i do the database attach, certain functions of the sites fail. This varies per site collection from menu structure to the site not working at all.

The cause of this is because the 2007 envirionment contains several web parts and features that the 2010 envirionment does not. Also the look and feel has drasticaly been changed.

To adres this problem we decided to create a new and clean SharePoint 2007 envirionment and first attach the "dirty" 2007 database there. After that we changed the look and feel and all web parts and features seemed to be gone.

However when i run Test-SPcontentDB on this "Clean" database, it gives me the same errors as te dirty one! The end result is also the same. So my question is, is there a way to remove these web parts etc. from this site collection? So to do some sort of clean up on the database.

I cannot remove the web parts and features from the original server and DB because it is a production server.

Answer 1

One of the first steps to any upgrade is to perform the Test-SPContentDatabase check against every content database in the farm. If this check finds errors, your upgrade will not complete successfully. There's no way around this; if you want a successful upgrade, you must pass both the stsadm preupgradecheck and Test-SPContentDatabase.

If the errors are feature related, you must either install the referenced features in your 2010 environment BEFORE attaching/upgrading the database(s), or cleanly remove the features from the 2007 environment before performing the upgrade.

There's a few things you can do to "clean up" the upgrade once it is done, but the "Error" status in the upgrade section of Central Administration will never go away. It's critical that you have a successful upgrade operation from a supportability perspective, which means it really needs to be done correctly in the 2007 environment first.

Even if you had a development environment, you'd still need to clean up the production environment before doing the migration since dev wouldn't be up to date data and you'd loose the delta in the two environments are part of the move.

The best practices process would be to create a mirror of your 2007 environment (build a dev environment), where all of those features and references exist so you can test the removal of those features and migration to 2010. Many times it'll take multiple iterations of removing features/references and rerunning Test-SPContentDatabase until the report is clean. You use this experience in your development environment to document the plan for the production migration. You then take production down for a maintenance window where you execute your documented plan against production to clean those databases, move them to the 2010 farm, upgrade them, and validate the new environment.

Upgrades are not a simple process, it's not something you're just going to fly through. A valid test run and clean Test-SPContentDatabase reports are critical if you want to be successful.