Some time ago we migrated several sites which were implemented for Sharepoint 2010. Project was started with Sharepoint 2013 Preview and then continued with RTM version (when RTM was released we made all steps which were made for Preview from beginning). I wrote about one of interesting problem which we faced during first part of upgrade here: Problems with upgrading claims based site from Sharepoint 2010 to Sharepoint 2013 Preview. During first part we made the following:
- Configured SP2010 farm
- Moved and migrated service applications databases (mostly managed metadata database in our case)
- Created new empty web applications and applied SP2010 customizations into 14 folders (in Sharepoint 2013 there are now both 14 and 15 folders, so you can deploy wsps for Sharepoint 2010 as is on 2013 farm and run your sites in 2010 mode)
- Copied and mount content databases from existing 2010 sites to empty web applications on 2013 farm.
This part went quite well. The major problem which we faced with was broken layout in pages edit mode (need to mention also that we migrated publishing sites). But it is caused by the fact that in 2013 you need also to update master pages in order to have all new scripts and necessary controls. E.g. you may use OTB seattle.master or oslo.master as base masterpages for updating your customizations.
The next part of work was migrating of customizations from 2010 to 2013. For 2010 we used standard Sharepoint project templates for Visual Studio 2010. But anyway it is not possible just change target platform from 2010 to 2013 as it is possible for .Net version. In Visual Studio 2012 you need to create empty Sharepoint projects and copy/paste all items one by one (Update 2013-02-17: there is a trick which allows to migrate Sharepoint project from 2010 to 2013. I wrote about it here: Convert Visual Studio Sharepoint 2010 project to Sharepoint 2013 project). In order to ensure that we didn’t forget anything after copying of files we compared content of wsps by comparison tool (we used Beyond Compare, which may compare folders, but you may use your favorite tool for this). The only difference was in feature guids and in SharePointProductVersion in manifest.xml which was set to 15 after upgrade:
After this we retracted wsps for 2010 mode from 14 folder and deployed new wsps for 2013 mode into 15 folder. And then run upgrade of site collections to 2013 mode by PowerShell.
Upgrade went well, we only had several warnings without errors in the logs. But when we opened sites in the browser we got File not found error. After checking Sharepoint logs and using of FileMon tool we found the reason of this error: for uncustomized files (page layouts and master pages) Sharepoint still tried to search their content in 14/Template/Features folder, while correct path is 15/Template/Features, because after upgrade and deploy of customizations there were no files deployed in 14 folder. So Sharepoint couldn’t find content on file system and gave this File not found error.
We analyzed content database and found that AllDocs table (which contains rows for all documents and files in the Sharepoint web application) still has SetupPathVersion = 4. While the correct value for Sharepoint 2013 is 15. We tried to update page layouts’ and master pages’ vti-setuppathversion property but without luck. After updating it and calling SPFile.Update() it was reset to initial value 4. At the moment I know only one solution: update AllDocs.SetupPathVersion in content database directly:
But as you probably know direct modifications in content database are not allowed and leaves system in unsupported state according to MS. So it is more like hack. Anyway after it File not found error was solved and we were able to move forward and resolve another problems (they are minor, like change of all paths for scripts, images, css and for ascx files for visual web parts from /_layouts/MyFolder to /_layouts/15/MyFolder. There is no need to change it for aspx files, because Sharepoint will automatically redirect your application layouts pages to /_layouts/15/).
At the moment we are still looking for the correct way of solving this problem. It may be so that it is caused by the bug in upgrade process, because I saw that other people faced with this problem in Sharepoint MVP distribution list. We ordered support ticket from MS to check this problem, I will update if will know new details. If you also encountered with described issue, please share it in comments.