Monday, June 9, 2014

Information Architecture Re-factorization

Situation: You have a legacy SharePoint 2010 Enterprise site that has grown organically. The web application has a home spun/3rd party global navigation component for the top nav and one site collection for every 1.03 web sites.  Plus, there's no discernable taxonomy to the current site structure. Your mission, should you choose to accept: migrate to SharePoint 2013, add support for Managed Metadata from the Term Store, rework the top navigation as a "MegaMenu," and reduce the overall number of site collections. Go!

Lets start with the problem in IA re-factorization and go from there:

Option 1) It's Enterprise, use "Manage Content and Structure"
Option 2) Use some exotic PowerShell magic to detect and recreate all settings.
Option 3) Use some not-so-exotic PowerShell magic, leveraging Import-SPWeb and Export-SPWeb commands.
Option 4) Buy a third-party tool that like those from Metalogix or AvePoint or some other great source.

I'm cheep, so we're going to go with something from options 1-3.  That said, we'll build the 2013 farm; copy the 2010 content database (fortunately there's only one); and attach it to a web application we've built for the new deployment.  We've now got a 2010-2013 version migrated SharePoint site operating in 2010 visual mode.

Option1: Manage Content and Structure
MCaS is pretty exciting option.  It's GUI based, so the learning curve is pretty short.  It will let you move Items, Lists or Web Sites between Web Sites or Lists.

Drawback #1, you've got to move one Web Site or List at a time.  If you've got a bunch (in my case more than 80), you're going to be at it a while.

Advantages, you get immediate feedback on the move.  I've seen that feedback to be wonky.  For instance, if the move takes too long, it may seem like it's erred out, but it's actually still plugging away in the background.

Drawback #2, you're going to have to keep both the source and destination content in the same web application.  MCaS doesn't work with two different web applications, but is this really a drawback?

Drawback #3, you can't move between site collections inside.  So you're stuck in one place.

Option 2: Exotic PowerShell Magic
This option seems the most sexy.  Create a totally awesome PowerShell script that recreates one SPWeb in another SPWeb.  At the same time, it seems like it's the most error prone, especially when you throw in SharePoint Publishing.  The code you write for this needs to duplicate every setting, while accounting for the new URL taxonomy as the content shifts from one location to another.  Plus, you'll need to not only duplicate the attributes of SPWeb and SPList, but you'll have to use the secondary object overlays for SPFile, SPFolder and publishing classes like PublishingSite, PublishingWeb and PublishingPage.  Too exotic for me...

Drawback #1: Man it's hard to write a script like this.  Better buy a tool, or look for some open source scripts...

Option 3: Not-So-Exotic PowerShell Magic
Ok, so this one seems viable to me.  Here we can script together a bunch of export-spweb commands with import-spweb commands to effectively extract and load the content in different locations.  Best part here is that the content can be in different web applications, and even be in different farms.

Drawback #1, Export-SPWeb will give you some really weird errors, especially if List Templates and their ilk have been removed.  The same goes for Import-SPWeb.  I've run the Import-SPWeb multiple times and it seems to resolve the problem when there's missing list template content.

Advantage if you can call it that: You couldn't look at the list contents anyway if the templates were missing.  They are basically dead items that you have to prune with PowerShell because the GUI won't let you navigate to the list settings pages anyway.

Drawback #2, If you script more than one move together with other moves, you're probably going to have to go digging through a bunch of log files to see what moved and what didn't go.  Error reporting isn't a strong suit of these commands.

Personally, I'll recommend Option 1 and Option 3 to my clients, and point them to some third-part solutions.  But for the situations I've been apart of, 1 & 3 will be just fine.

No comments:

Post a Comment