Recently I was asked to migrate a SharePoint 2007 internet facing site to their new SharePoint 2010 environment. After a quick analysis of their SharePoint 2007 site and environment I decided to give it a go with the DBAttach approach. In this blog post I would like to share my experience.
It was a small MOSS2007 farm with Service Pack 2 installed as well as the Dutch Language Pack. The internet site used the publishing features for creating and maintaining the pages. The web application had only one content database.
Just to be sure I used the STSADM –o preupgradecheck command to investigate the current SharePoint environment. It resulted in no errors, so I could proceed with the next step. From SQL Server I made a backup from the content database I was going to migrate (or should I say update to SharePoint 2010?).
I installed a new SharePoint Server 2010 farm with also the Dutch Language Pack. Nothing special here. I created a new web application. The content database created will be temporary. It is not possible to delete it now.
Next thing to do was restoring the content database in the new SQL Server environment using SQL Server Management Studio. After this I was able to test this content database prior to attaching it to the newly web application.
Let’s start the PowerShell environment and execute the cmdlet:
Test-SPContentDatabase –name <restored contentdb> –webapplication <url>
It gave me several items to work on: 2 missing features and these:
Database contains a site (Id = [<guid>], Url = [/]) whose url is already used by a different site, in database (Id = [<guid>], name = [WSS_Content]), in the same web application. Consider deleting one of the sites which have conflicting urls.
File [FeaturesExcelServerSite Microsoft.Office.Excel.WebUI.dwp] is referenced  times in the database [WSS_Content_Restored], but is not installed on the current farm. Please install any feature/solution which contains this file.
The missing features was easy to resolve. Installing the features did the trick.The SiteOrphan message was also easy, because there are 2 content databases in the same web application having a root url. It will be solved when the temporary content database is deleted.
I had to google for the MIssingSetupFile error. According to this I could ignore it, because it was an issue with the webpart and the Test-SPContentDatabase cmdlet.
So, after all, this test was of great value and I could proceed to the next step. I attach the restored content database to the web application. Once again PowerShell is the way to go:
Mount-SPContentDatabase –name <restored contentdb> –webapplication <url>
This command migrates/updates the content database to SharePoint 2010. After this I deleted the temporary content database and gave the site a go…
Opening the site was quite a surprise. For starters, the look and feel really looked okay, but I still needed to do a Visual Upgrade. Then I noticed the errors in the top navigation. I switched over to Site Settings and tried to click on Navigation. ERROR! Hmmm… After some investigation I noticed the following:
In MOSS2007 we have a Pages library for the Publishing Infrastructure. Although the Dutch Language Pack was installed this library is still called Pages. Not in SharePoint 2010! If you install the Dutch Language Pack the library is called Paginas. Not only the UI is translated, but the “back-end” infrastructure items as well! Eeek! The SharePoint 2010 navigation is based on the language translated Pages library (thus, Paginas). After the migration I still have the Pages library with all the content. No Paginas library present. Renaming the Pages library is not an option. The url needs to be corrected. Fortunately, Microsoft acknoledged this issue and has a KB article about it:
Great! PowerShell to the rescue! I executed the script and my problem was solved!
One thing left to do: the Visual Upgrade. In Site Settings I clicked on Visual Upgrade and I confirmed my action. The site changed to the SharePoint 2010 UI. Horrible! The look and feel was a mess. Hmmm… It seemed that this action replaced my custom master page to the default v4 master page. Duh! No wonder it became a mess! I changed the master page back to my custom one. Pfew… I looked okay again.
This migration went really easy, some minor issues when testing the content database. The navigation errors due to the Dutch Language Pack is one to remember. I have a feeling I will encounter this many times in the future as many customers are migrating to SharePoint 2010 now.