Forum Discussion
Consolidating into one site collection
We are looking at moving our SP2013 on prem farm to the cloud. We currently have around 20 site collections representing various business units within the company. These are the same site collections that we had way back on WSS 2.0 that have been upgraded through 2007, 2010, and now 2013.
As part of the planning for the move I came across this article:
https://docs.microsoft.com/en-us/sharepoint/dev/solution-guidance/portal-information-architecture
The entire article is a good one, but I thought this comment was interesting:
The discussions have changed around horizontal/flat site collections vs vertical/hierarchical. In the past, we promoted flattening hierarchies into potentially several separate site collections. This was for many reasons such as IA best practices, menu structures, content database management, capacity, etc. As far as for capacity reasons, with SharePoint Online, that is not too relevant anymore. However there are other considerations now such as URL limitations.
I looked at this link as well:
In it I can find nothing that limits the size of a site collection (i.e. content databases). Does that mean that there are no more limits on how big a site collection can grow? And if so, then does that mean we could consolidate our 20 site collection down to 1, (around 1tb of data)?
Consolidating appears to give a lot of benefits, (easier to manager permissions, site templates would apply to all, etc), and now I'm struggling to find any real downsides to it. As long as content database sizes don't apply to SPO then I'm thinking consolidating seems like a real good option.
What does everyone else think?
Ted
4 Replies
I realized I should give just a few more details about our system, since that could make a big difference in this as well.
Like I said we have around 20 site collections in our current SP2013 farm. We also have around another dozen or so in a SP2010 farm that will be moving over someday as well. All told it's about 1tb of info. We also have another 10-12tb of data in our file shares that we have been debating moving into SP for years but never got around to it. Now with the cloud there is some push for that to happen.
We are a global company with a offices/manufacturing plants all over the world. We have several subsidiary companies, each with their own site collections as well.
One important aspect of this is that for every product our company makes, (or even thinks about making), there is a SP site for it. All data regarding that product lives in that SP site forever. Everything for that product, from it's initial concept through the end of life shut down, get's saved in SP.
We've been looking at Teams, and I would assume each product would get created as a Teams site. That way all the engineers, sales people, legal types, etc associated with that product could come together to work on it. How well does that work in Teams if you have an engineer who's a member of 30 different projects, all on Teams? Or a lawyer who has to chime in on every product, plus every other thing the lawyers have to be involved in?
I'm a little hesitant about doing all of this in Teams sites because it just doesn't feel like MS has fully developed this idea yet, and I'm nervous about committing fully to it only to find out that it doesn't scale well in a large manufacturing company. I use Teams for just my small workgroup and there are some days I SERIOUSLY want to just delete the app completely.
We also looked at Hub sites, but according to MS you can only have 50 of them per tenant. Even though we only have around 30 site collections now, planning for future growth means we'd run out of those eventually. I can't see the benefit to the hub sites that doesn't already exist with our current top level site collection home pages. or master pages.
I think Hub sites could have been cool if they could have been nested, and had way more than 50.
Ted
Don't assume that each product will get its own Team. Teams provides some new ways to create cross-functional groups of people that don't reflect your org/sales hierarchy. I belong to many project teams, i just make the active projects favorites so that they show up in UI, and when I'm not working on it I remove the Favorite. It can get tricky remembering where a Chat took place.
When you create a new Team, you can connect it to an existing Office Group, or create a new Group. You will also get a SPO Site with a document library and each channel in the Team will get a folder in that doc library. You can easily add links to other existing SP Sites/doc libraries so that the Team can easily access other products/reference material etc.
Hub sites are intended to tie together a flat site scenario, which you don't have, they won't provide much benefit for your legacy collections, but will for new stuff.
Keep in mind that you will soon be able to assign site collections to different data centers around the world.
HTH
Dean
- I would advice to maintain the same architecture you currently have OnPremises where all your top sites are Site Collections....this kind of architecture makes totally sense in SPO. In regards of size limits for Site Collections in SPO, you don't have to worry about this since a Site Collection in SPO can store up to 25 TB of information...what you have to take into account is the default storage you have in your SPO tenant: 1 TB + 500 MB x # Users with a valid Office 365 License
That's far from the recommended approach these days :P. I was the total opposite of you. I went from 1 site collection to many site collections. Especially with the advent of Teams. You may end up eliminating those units in place of Team connected site collections. I don't know your big picture but if you do plan on using Teams I would focus your migration around Teams. vs. moving SharePoint then integrating Teams after the fact cause it will make it more difficult to move things around.
Every entity you create in Office 365 these days is a site collection. Everything you create is tied to an Office 365 group, which also creates a site collection with it. So in my case, I now have a Teams for every department, a team for every sub team inside the department. Which creates site collections for both. Then org facing sites that are communication sites for org consumption, these are their own site collections.
Hub sites help connect all these flat site collections together for providing consistent branding and news/content rollup to the hub site. Think Parent site with sub sites, but they aren't connected in any way share or form other than using the parents nav, and theme across all sub sites.
So not sure about that article, seems old thinking, the new way is many site collections, no sub sites, since that's how Microsoft likes to scale these days with SPO.
The limits are fairly large per Site collection these days,, looks to be up to 25TB according to this: https://technet.microsoft.com/en-us/library/mt842345.aspx but the beauty of 365 is you don't have to think about content databases and those things anymore as an admin :).
