Corey Roth [MVP]

I’ve suffered through my share of SharePoint upgrade / migration projects now and I have really changed the way I look at them.  Often when you get exposed to a new system, the lack of governance has led to a total mess with site sprawl as far as the eye can see.  The architect in me makes me want to fix everything: upgrade, fix the IA, classify content, re-brand, you name it.  You might be tempted to do it all at once and maybe even use a third-party tool that promises to migrate things from location to another seamlessly.  These tools can prove handy, but don’t fall into the trap though.  The risk is too high and the experience can be jolting.  Let me explain my thoughts.

For me it’s all about the user and judging what success is.  You want to minimize the impact to the user.  The more you change at once, the higher the risk.  The more changes you make, the more likely you will fail and then your users will revolt.  Think about it.  Just changing user interfaces can be jarring.  Every version of SharePoint looks a lot different.  Now, you want to tell the users that all of their files are going to have new URLs too?  Now it might make sense in your mind because on change is easier than two.  However, I’ve tried it before, it doesn’t go well.  You end up troubleshooting upgrade issues as well as a heap of other issues because links are broken (yes, I know there are tools that help with that).

Upgrade First

Why do I like upgrading first?  Because it can be viewed as a (relatively) quick win.  Most SharePoint farms aren’t easy to upgrade, but sometimes they are.  You throw your solution packages on the new farm, attach the content databases and you are good to go.  I’m over simplifying it I know, but I think approach makes sense.  With SharePoint 2013 and site collection upgrades, it makes it much less painful to upgrade a site one at a time.  Since sites can run in SharePoint 2010 mode during a transition period.  If things go well, you can actually transition your users over to 2010 mode on the new 2013 servers and then decommission the old servers.

Switching SharePoint versions requires us to make changes to branding every time.  A lot of times, companies use this as an opportunity to redo the home page, relaunch the Intranet or make other changes.  Don’t do that.  Again, too much change.  Honestly, your users may appreciate the fact that they can drag and drop files into a document library more than the fact that you’ve come up with a flashy new news rotator on the home page.  They just want to be able to find the content they need to do their jobs efficiently.  That’s why I am saying this is not the time to rearrange sites and start tagging content.  So what do we do about the branding though?  Chances are you don’t want to completely lose your corporate brand when you hit that upgrade site collection button.  My recommendation is build a new master page but it keep pretty similar to the one you had from the previous version of SharePoint.  This may seem like a wasted effort since nothing you still have to rebuild your master page from scratch.  It’s a painful process I know, but it makes sense in the end.  Deploy your new master page to the 2013 version of the site and start upgrading your site collections.

What is great about this approach is your users are using the new version of SharePoint much faster.  This gives you a win.  What happens when you decide to change your information architecture or branding is then you have to get multiple departments involved marketing, corporate communications, compliance, records management, legal, and whomever else things they have a say.  Add those departments to your upgrade project and you’ve just extended your upgrade project by six months.

Fix the Information Architecture

Now, that you have your new site running on the latest version of SharePoint and your users are excited about the change, you can start thinking about governance enforcement and information architecture.  This approach allows you to site down with a department, determine their needs, and explain to them that you need to move their site, split it into two, or whatever needed to make it fit into the current organization properly.  As a consultant, this is an excellent opportunity to meet more business users and potentially even drum up new work.  Users will often open up to you when you sit down with them and tell you what frustrates them about their current process.  They especially get excited when you show them how some new feature can tackle some issue that they had with the last version of SharePoint.

Changing Information Architecture doesn’t always mean you are moving sites around either.  What’s important is getting the navigation right.  It needs to be clear and intuitive to the users.  Users generally have some idea how the company is organized and they are going to look for things in that manner.  At the same time, you are going to find content you want to highlight such as policies, forms, and more that should be in the navigation as well.  There are plenty of ideas out there on how to arrange your navigation, you have to find the one that is right for your organization.  Just remember, it’s about making it as painless as possible for your users to find the information they need.

If you need to move or consolidate sites, SharePoint doesn’t exactly make it easy with the tools that are included out-of-the-box.  I urge you to proceed with caution when evaluating migration tools with ISVs.  There are a lot of tools out there and they all have their plusses and minuses.  You need to keep in mind whether the tool properly maintains authors and dates when moving.  You need to especially tread carefully, if you need to move a site with workflows.  The things that tools have to do to move workflows is a bit unsettling so I always tread carefully.  However, the tools are getting better and better so you may run into less issues than I have in the past.

Depending on the size of the company, chances are you can’t make information architecture changes overnight.  You’ll have to move things and update navigation in batches.  Of course there are infrastructure considerations as well.  Your sites need to be arranged in content databases accordingly to scale for growth.  We could write a whole series of posts on arranging sites, navigation, and planning for scalability though.  Just from these few paragraphs, you may be thinking about the amount of time and planning this can require.  The point I want to make here today is that your IA changes should come after you do your upgrade.  If you are still waiting to decide on these changes, your upgrade, still hasn’t occurred.

Re-launch the Site

What I mean by this is now is when you take the opportunity to redesign the home page, implement new features, change the branding, and more.  This is the time when you get your marketing and corporate communications people to drum up excitement about the site.  After all it’s a lot more fun to celebrate a new site that has new features tailored to the organization’s employees than it is to celebrate that SharePoint is running a new version.  Your IT department might be celebrating that, but the rest of your company could probably care less unless there is just some specific feature that changes one of their lives.

What do you think?  This subject is widely open for debate and there are lots of ways to approach it.  What has worked for you?  What hasn’t?  Share your story in the comments below.

Now, you might be asking why not just use a tool to migrate and reshape the IA at the same time.  I’ve tried that and it worked for some stuff very well.  However, if you have a site that is tricky and the tool struggles with, then people start asking where there files are or why did they lose content on a page or worse.  Effectively this doubles the amount of testing you need to do.  You may thing you are saving time, but it just has too much risk.  Upgrade first, then change your Information Architecture.  Your users will appreciate it.