Sharepoint Forum

Ask Question   UnAnswered
Home » Forum » Sharepoint       RSS Feeds

Seeking opinions on site collections- best practices

  Asked By: Karen    Date: Aug 24    Category: Sharepoint    Views: 2218

what are good arguments for creating new site
collections? I'm trying to see what the pros and cons are.

We have this setup at my organization: Working groups (no real
staff, just CSOs), Clusters (didn't want to use the
word "departments" I guess), then Teams. Some clusters are led by an
individual while others are co-led by their teams' leaders. Some
clusters' teams work together, others hardly do anything as a
cluster and work mainly w/in the team/sub-teams.

In planning our top-level sites, I had originally thought of
creating a site collection for each cluster, and having the teams
and sub-teams develop subsites from the cluster site. We are trying
to put very little content at the portal level, so we'd like to have
publicly-accessible top-level sites (for clusters and possibly
teams) with restricted sites underneath.

Now I'm wondering if they should all get their own site collections
(teams, not the sub-teams). We have 15 clusters and 45 teams. Should
I create 60 sites?

I know permissions can get tricky, so I want to make sure I start
off the right way instead of trying to clean up later on.



6 Answers Found

Answer #1    Answered By: Kyla Eckert     Answered On: Aug 24

I vote for using many site  collections because of the following:

1. You can use stsadm.exe to backup each site collection  individually
having a full-fidelity backup including all security and personal
settings. You have to use smigrate.exe to backup subsites, but
smigrate.exe doesn't restore security by default. Smigrate also takes a
lot longer for backups.

2. You have some control of using content  databases to put  site
collections. You can even force a site collection to be created on its
own content database. It takes a little tweaking to get it to work  like
you want. If you use all subsites, then you will eventually have one
gargantuan database.

3. You will have some issues moving and/or restoring subsites  because of
#1 and #2 above.

We started off with all subsites two years ago, but are transitioning to
site collections because of issues above. We now use multiple portals
and managed paths for organization.

Answer #2    Answered By: Alisha Holmes     Answered On: Aug 24

So, based on what you've said here, would the same go for
considering when to create subsites  for teams? For example, if I
create a team site  for a team (instead of a cluster), should I make
a site collection  for their "public" site that all staff can read,
and a separate site collection for their team "private" site (for
all team collaboration, planning, etc.)?

What do you think? I could see a potential problem w/ having a
public site and using a subsite to start the "private" work  for the
group (which is what I had been planning  to do). They will likely
start creating  subsites and meeting workspaces, and if some day they
need to delete the public site (?? for some reason), there would
have to be a way to back up the 1st subsite and all of its
subsites/workspaces to move them "up" as their own site collection.
I know how to do this w/ frontpage, but it doesn't keep any
permissions info or personal settings (as you noted in your message).

Does this make sense? Sorry- I don't know if I'm saying this right.

This is just such a hard decision to make since I've heard arguments
for not having too many site collections, too.

Answer #3    Answered By: Laura Walker     Answered On: Aug 24

We do the same thing with having a public and private site  for teams.
The public site contains general documentation with few details, and the
private site contains the "meat" with very technical information. I
would recommend using separate site collections with different security
settings. For example, our Information Technology Group (ITG)
Operations dept. SharePoint websites are setup  as follows:

http://itg/operations/home (ITG Operations home site linked from portal)
http://itg/operations/desktop (ITG Operations Desktop Support site)
http://itg/operations/support_center (ITG Operations Support Center
http://itg/operations/data_center (ITG Operations Data Center site)
http://itg/operations/systems (ITG Operations Systems site or public

All sites  listed above are site collections on the ITG portal. The
systems site contains public information for management and others with
very general information. There are many ways to setup your site
structure (taxonomy), but the method above works best for us. I
originally approached SharePoint like I was setting up a folder
structure on a file server. For example, our ITG Server Support
websites were setup as follows:


We then found out that we had limitations with backup and a large
database size because all sites are subsites  of server website.
Therefore, we redesigned the structure to be:


To get this design, setup "server" as a managed path, and create
separate site collections. This is a "wide not deep" structure. This
taxonomy seems to work  the best for us, but you may need a different
structure. I would ask others for other SharePoint site design ideas
before creating  your site structure because it can be difficult to
change down the road.

Answer #4    Answered By: Percy Beach     Answered On: Aug 24

Anytime you need a new collaboration space, you can use a new site
collection. In larger companies, there can be 10's or even 100's of new
site collections every day.

Answer #5    Answered By: Christop Mcfadden     Answered On: Aug 24

So, part 2 of my question is this: what are some tips for keeping
sites organized, findable, avoid duplication of documents...etc. My
brain is still stuck on info architecture, so flat is something that
sounds bad to me.

I imagine, as said that a company is now doing, I could use
portal to keep an organized list of sites  and set up a kind
of "pretend" architecture/hierarchy there.

I'm so used to dealing w/ folders and subfolders that this is hard
for me to wrap my head around.

I recently took 7-8 sites and merged them under one "umbrella" site.
This was for our AMS project, and there are several different teams
working on different modules. I made the top site  public and it
holds info and documents on progress, etc., for the entire staff to
read. The other sites are sub-sites w/ different permissions. I did
this since they are all part of the same project. Would you
recommend that these actually be (as they once were) individual site

I'm wondering now when you would use sub-sites.

Answer #6    Answered By: Kundan Jambhale     Answered On: Aug 24

Use the sites  Directory to organize your sites. That's what it's for.

Didn't find what you were looking for? Find more on Seeking opinions on site collections- best practices Or get search suggestion and latest updates.