Thursday, April 7, 2016

Considerations when upgrading WSP’s from one SharePoint version to another

image
I’m currently helping a government client move a SharePoint 2010 farm over to SharePoint 2013, but this post is just as valid if you move solutions over from 2013 to 2016.

The backdrop for the migration is that they have numerous WSP’s with server side code, and when migrating to SharePoint 2013 they decided to keep the server side code instead of moving over to a client side model. A decision made before I was involved, but it’s a valid one for many scenarios.
Before delving into some upgrade paths you can take and the one chosen, let’s sum it up!

Lesson learned

Be smart, plan ahead and think well before you involve your favorite consultant on the migration path – it might be one of the last tasks he or she will help out with, regardless how nice and forthcoming they are.

When migrating from one SharePoint version to another keeping server side code, do the simplest thing possible with the least amount of moving parts. Do not mix in code refactoring's and changes as part of the process. If you do feel the urge to do so, then create new solutions which can co-exist side by side with the 2010 packages, and save yourself a lot of grief and swear words if you’re inclined to those.

Planning a SharePoint upgrade and want help? Feel free to contact me or Puzzlepart and we’ll be happy to forward you to someone who likes these kinds of tasks. If you however want to move from WSP’s to a client side model as part of the migration we’d be happy to assist :)

The easiest possible path

..was not chosen. The easiest path is to take the 2010 solutions, open them in Visual Studio, upgrade to 2013, and rebuild. This keeps the solution id’s and dll versions for all web parts. Which means you can migrate like this:
  • Mount 2010 database in 2013
  • Install 2010 WSP’s in compatible mode for 14 and 15 hive
    Install-SPSolution -CompabilityLevel {14,15}
  • Upgrade site collections to 2013 mode
  • Upgrade all solutions to the 2013 compiled ones

The switch path

..was not chosen. This is where you rebuild your 2010 solutions into new 2013 solutions with new solution id’s and new web parts. With this approach the migration can be accomplished like this:
  • Mount 2010 database in 2013
  • Install 2010 WSP’s in compatible mode for 14 and 15 hive
  • Install 2013 WSP’s
  • Upgrade site collections to 2013 mode
  • Activate 2013 features if needed
  • Loop over all sites and web pages, replacing the existing web parts with the new ones
  • Deactivate 2010 features
  • Uninstall the 2010 WSP’s

The custom, not well planned path

..was the chosen one. This is where some of the WSP’s kept their solution id’s, but they decided to change namespace and assembly names as part of the 2013 code upgrade process. In order to switch out the 2010 web parts with the 2013 equivalent ones and keep the web part properties you need to have both the 2010 dll’s and 2013 dll’s present. If not you cannot export a web part from the page and keep the web part definition. So we ended up with the following steps:
  • Mount 2010 database in 2013
  • Install 2010 WSP’s in compatible mode for 14 and 15 hive
  • Deactivate 2010 features (neither had deactivate code present)
  • Upgrade site collections to 2013 mode
  • Remove 2010 WSP’s with same solution id’s as 2013
  • Install 2013 WSP’s
  • Manually GAC the 2010 dll’s
  • Manually add safe control entries to web.config for the 2010 web parts
  • Loop over all sites and web pages, replacing the existing web parts with the new ones
  • Un-GAC the 2010 dll’s and replace the safe control entries

2 comments:

  1. how to upgrade wsps to SharePoint 2016? should i open them with Visual studio 2015 and assign the framework to 4.5.2 or no need for this?

    ReplyDelete
    Replies
    1. You could open them and recompile, or just leave them as is. 2013 WSP's should install just fine in 2016.

      Delete