Forum Discussion
Modern subsites?
All flavors of "Modern sites" that are created now are Site collections by definition with the top level site providing the "Modern" UI experience. I'm wondering what the future is for subsites in the "modern" experience? I know you can create a classic subsite and add modern pages to it, but that's not quite the same thing. And you don't get some of the modern features. E.g. you can't apply the modern themes to these sites from the Settings gear.
I know a lot of organizations have made mistakes in trying to put all content in a single site collection, but I'm also wondering if having all sites in single-site site collections makes sense? Are Hubs enough to manage those? And what do we do with all the classic sites that are organized into subsite hierarchies?
Does anyone know what the future is for the modern experience and subsites beyond Hubs?
I am concerned about what happens to existing structure in this scenario. I understand that splitting things out into site collections can be better in some instances, but what about where you have different solutions or sub departments and you want a separate group associated with it for each? Or the case where you have regional sites and then departments per site that need to re-use content from the regional site collection root (site columns, content types, etc.) Are we expected to duplicate all those columns across the site collections that need them?? To rule the possibility of O365 Group Enabled subsites out completely is going to hamper existing tenants switching over to the modern experience in a major way.
Current, the new Hub Sites, do not provide any ability to deploy Content Types and/or site columns
If you need to control these, the current best approach is to the PnP PowerShell cmdlets to provision new sites with the specific items you desire
ssquiresfrom Microsoft has stated that they are working on improving the functionality in the Content Type Hub, what this means and when it will happen remain to be seen.
I don't see group-enables subsites coming any time soon because that would make a very complicated engineering problem even worse.
- How do we share lists across site collections, the kind that drive lookup column values? This is a major reason why ppl use subsites...Not going to use managed metadata for dynamic content like contracts, purchase orders, work packages, etc...
I totally agree with your concerns.
- Making such a change in the architecture would be really huge for us with hundreds of subsites created
- What about the re-usability of
- security groups within a site collection
- Site columns
- Site content types
- The security management will become a nightmare as we cannot add a group (or security group or distribution list) to a group
- Hubs don't nest!!!!
All of this goes away to ashes with the site collection/o365 group approach.
It would have been simple to allow an office 365 group to be linked to an existing subsite wouldn't it?
I don't see how this could be an enhancement...
- This was a concern for us, but the use of groups functionality outweighed the reusing of security groups, which after looking at our users, turns out was not done much.
I would be interested to know how Hubs manage permissions, it at all.
- Glad we have the migration tool. I think that will come in handy with all my subsites.
A concern raised by a coworker is that all modern team sites are associated with a different Office 365 Group. And you can't add a group to another group. So maintenance of security across all those groups could be an issue. Will it be possible at some point to associate multiple modern team sites with one group?
i would say that from a performance viewpoint, resolving sub-sites has always been an overhead as it reduces the amount of work that can be delegated to SQL by the need to translate internal sharepoint only meta-structures. Now that the old limitations around site collections and database sizes have gone, it makes sense to evolve the granularity and use site collections as the atomic site so that performance can be accelerated. it is only because we have got in the habit of subsites that we are nervous about moving away from them. The advantages they gave in inheritance are much outweighed by the problems of broken inheritance. The inability to separate them in SQL can become a problem as a site grows and then forces a restructuring.
For small segregations then List/ Library structures can be used instead of subsites to partition data physically for security purposes.
The HUBS architecture looks like a more formalised evolution of cross-site publishing which delivers a very robust and flexible system where I have used it before. excellent pattern that really leverages search.
perhaps those with a love for subsites could bullet point their advantages to see if we can suggest how that functionality would be designed into a site collection approach.
Hello,
I have a classic site with 2000 subsites in it. If i convert it to a Hub site and link all subsites to the hub site; is it possible to do?
- Vinita, no. Modern team sites and modern communication sites link to hub sites. I have not heard any simple answer to what do you do with thousands of classic sub-sites.
One strong argument for the classic sub-site Information Architecture is that important Web Designer Galleries -- the Web Parts gallery, the List templates gallery and the Style Library -- all live in the Site Collection, not in the sub-sites. We maintain important assets in these galleries and in the Style Library: in one place, where a change automatically applies to all the subsites within that site collection.
In a new Information Architecture where all sites are site collections -- and we have 1000s of these site collections -- where do we deploy a common, custom JavaScript that we would traditionally keep in the Style Library? Same question for custom list templates, web parts, themes, solutions and composed looks?
Related to this - if I wish to make a custom list accessible to a number of sub-sites then it must live in the root site of the site collection. I don't see how I can provide this functionality if I adopt the "new" flat infrastructure where subsites are not used
I'd rather not have to sacrifice information architecture and usability for the sake of performance, especially in an Intranet as its main function is to provide information. So my concern is more whether we are losing an aspect of information architecture that can be beneficial for certain types of users, those that prefer browsing to searching.
At least one scenario we use is a site collection of clients. Each client is a subsite which in turn has subsites for those projects. We could have a hub that surfaced the site collections of clients, but then what about the projects and searching across all of that structure?
I'm glad you qualified the multiple List/Library approach for small segregations. I've seen the opposite, and the job of trying to split that information apart into separate sites is quite a bit more difficult than moving a subsite into its own site collection.
But that said, we haven't had a lot of people "with a love of subsites" chiming in :-). And maybe I just need to get my head to think a different way.
Mary,
We currently have the same information architecture on premises. One site collection per client (> 150,000) and one subsite per project (2-50 per client). We could use a hub per client but then we loose the «all clients» scope.
If we stay with the subsites, it prevent us from using Teams and Planner for the projects.
We have to make on decision on our 2.0 architecture for the cloud and I think we will have to leave the subsites strategy.
at the Ignite conference it was defintly 100% clear you do not want to create subsites anymore. So this is your first answer.
the Hub is still in development but i think this will definitely be the way to go with SharePoint.
A example why you should choose sitecollections and the instead of subsites is that when you need to move a site to a different department or other sitecollection. this is not possible without migrating if you use a subsite.
Hmm. Okay. Good to know that was the message given. I don't know that I entirely agree with that approach.
Hubs will not be able to be linked to other hubs, so that means only one level of categorization of a site. And while I do understand the problem of moving a site between departments requiring export/import, it is not a scenario I've run into so frequently that subsites should be ruled out categorically.
I agree. I don't really understand how this will work for us. We are a small company with quite a lot of projects and the current modern experience doesn't allow us to organise sites in an easy way. We currently have 9 service areas with programmes and projects underneath those. Many projects relate to each other so have a natural hierarchy and while a flat structure is fine for quick access via the hub, it is not very useful for finding old projects that we regularly need to refer to. We also don't want to spend thousands of pounds contracting consultants to write some bespoke pages for us, especially when there is such a transition between classic and modern.
Does anyone have any links to videos/pages that explain how a company *should* structure their site collections to create a coherent structure in line with our operational needs? Most of the videos i've seen just demo individual site/group creation.
