Upgrade first, then fix your information architecture. Your users will appreciate it

Posted Tuesday, July 16, 2013 10:20 AM by CoreyRoth

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.


# re: Upgrade first, then fix your information architecture. Your users will appreciate it

Tuesday, July 16, 2013 10:03 PM by Robin Majumdar

Great write-up... very timely. We're on SP2007 at the moment and looking at moving to 2013 most probably... 1000+ sites easily, 1000 users of which about 400 are active monthly... and

500+ GB over 500K items or docs....

In a very complex large enterprise environment, so your article has given me lots of food for thought.

(Even though right now my priority is hoping that my 18 month old sweet little girl doesn't wake up) hehehe


# Upgrade first, then fix your information archit...

Wednesday, July 17, 2013 9:26 AM by Upgrade first, then fix your information archit...

Pingback from  Upgrade first, then fix your information archit...

# re: Upgrade first, then fix your information architecture. Your users will appreciate it

Wednesday, July 17, 2013 3:03 PM by Thomas Vochten

Great read. I very much like your approach. Very often even customers themselves want to upgrade and fix everything at once.

# re: Upgrade first, then fix your information architecture. Your users will appreciate it

Monday, July 22, 2013 12:51 PM by Tom Resing

Improvement happens one step at a time. Sometimes, upgrading can be a quick win. Make sure you test, though. We all saw the lesson I hope Microsoft learned when they tried this approach with o365.

# re: Upgrade first, then fix your information architecture. Your users will appreciate it

Monday, July 22, 2013 2:39 PM by Mike Fortgens

Not sure what to think of this... currently I'm at a client where they did an upgrade in the past from 2003 to 2007 without bothering about the "C" containers. IA in their 2007 is a complete mess and it would be my worst nightmare to have that upgraded to 2010. So we are migrating departments to the new environment, in a new IA structure, and updating links in the old environment, slowly migrating everything, one step at the time. I think it really depends on what the current situation is. Trash in will still be trash out imho, whether you're gonna try to polish that afterwards or not.

# re: Upgrade first, then fix your information architecture. Your users will appreciate it

Tuesday, August 13, 2013 10:47 AM by Mick Thornton

Love it.  I'm the person who both builds and then trains the corporate employees how to use the tech.  I made the mistake in 2007 of going to "techie" and the adoption rate plummeted.  People were hiding stuff in LAN folders, desktop, even shared Outlook mailboxes.  My big key for 2010 (SP & Office) was to really know what the end user needed (not always what they said!).  I had to go watch many people and their workflows.  

Once the upgrade occured, I could train on key features (tips & tricks to make their life easier).  When they felt empowered, they started to evolve their own Information Architecture.  Is it perfect? Nope, but adoption stays high.  We also take seasonal slow times and do "spring cleaning" every year, or take out the trash (using Mike F's analogy from above) - which may not be trash to begin with but becomes trash once it's been consumed (think trash in your own house, i.e. my Hershey's wrapper is now trash, but wasn't yesterday! :) )

Leave a Comment