Architectural considerations for a progressive SharePoint 2016 roll out

Posted by

Hi All,

We are looking to do a SharePoint upgrade from 2010 to 2016. We will then look to conduct a progressive roll out SharePoint to the various departments across the organisation starting with the ones that were on SharePoint 2010. The question I have is can you provide any detail on any overarching architecture issues we would need to consider upfront to support the progressive roll out approach? An example I am of thinking of would be the directory of organisations etc. forming part of a corporate taxonomy. Many

Inform Consult Ltd

My first suggestion is to determine if the IT department checked ALL compatibility of your current Applications including Microsoft’s office products.
The Oil and Gas company I was with just 2 years ago did not do that before they aggressively deployed SharePoint and discovered the Offices tools all needed to be upgraded to Office 2013 in order for the Groups to take advantage of the full features of SP 2013.
The add-on apps did not support the 2013 SP platform.
You need to see the applications working on SP as well don’t believe the sales rep when they say it works.
Good luck and Merry Christmas

If you aren’t already you can use the Term Store in a Content Type Hub and the Managed Metadata Service to list and manage departments.
This can then be used to support automatic tagging of documents and records per business unit (i.e., library column defaults or pre-tagged templates), routing through workflows, and even menus through managed hierarchies.
It’s not perfect and I suggest you test vigorously, but it can be done and it means that you can manage content across multiple site collections from a central location.

Good luck!
Cannonspark Consulting

1st: Happy Holidays! 🙂 2nd: When you say “Architectural considerations”, are you meaning information architecture? Software architecture? Database architecture? Solution architecture? Process architecture?

3rd: In your given example, which would fall under information architecture, you should NEVER, EVER use a departmental hierarchy as your taxonomy. Why? Because it changes. There is no such thing as an organization of human beings that isn’t subject to change. Therefore, by using a dep’t breakdown as your taxonomy you are automatically injecting a bunch of extra overhead just to keep your taxonomy accurate and current.

Best regards

TQM Services

Hi All
Happy New Year and thank you all for your feedback. All very useful.
@ Lorne Rogers yes was focusing on information architecture (although you are right in that the other architectural areas (software, solution, database) should also be considered and will be.
Thanks again everyone!

Inform Consult Ltd

To add to Lorne’s reply: There’s very broad consensus about the dangers of using departmental structure as a basis for your taxonomy when publishing information that is useful to broad segments of your company. In those cases, your taxonomy should be task and topic based and not based on org structure. The struggle comes when trying to deliver department based storage and collaboration sites. Naming of the URLs/folders can be a sustainability struggle. One approach to consider: Tap into your HR system of record and use that data to create more sustainable naming structures. For instance, if your HR has coded IDs for departments, create standard sites or site collections using those department codes. The department codes usually don’t change very often even if the department is renamed so you don’t have as many issues with renaming site collection every time a department is moved or renamed. Certainly you still have issues associated with change but they won’t be as frequent or severe. In addition, we’ve considered using the parent child relationship between departments in our HR system to create a dynamic taxonomy for these site collections that would change as the department structure changes. I’d be curious if anyone else has experience with any approaches like this.

The Dow Chemical Company

What I’ve done in the past is created sort of a dual structure: publishing sites that are subject area or functional decomp based and then team collab sites that were teams under parent department sites and then used 3rd part migration software to move stuff around when it was deemed truly worthwhile. BUT, the key point was that all content meant to be consumed outside the team sphere went into the controlled publishing sites. Bit of a hack, but mostly from a governance point of view versus technically.
Not sure if I answered your question or not ;)).


Hi Tita I think everyone has given very good comments on this subject. What I would like to say it also depends on what other add-ins you have on your environment. For example workflows are a big issue when you migrate from one environment to the next so you need to do analysis of your workflows and chances are you will loose history of the workflows and you will spend a lot of time re-publishing in the new environment and some of the stuff might not work.

Also another aspects is SharePoint 2010 was big on InfoPath, ensure if you used InfoPath that your InfoPath forms will work otherwise find an alternative when moving to 2016.

I am starting with the planning of doing my 2nd upgrade now from 2013 to 2016.My first upgrade was in 2013 when I moved from 2010 to 2013.
Good luck and all the best. Regards


Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.