One of the things that we want to do as we move forward to SharePoint 2010, is to get our content databases squared away. When we first began working with SharePoint, we did not know how it would be received in our organization, and frankly, we had tried content management efforts before with little success. Acceptance of SharePoint is growing, and grudging acceptance of ECM is tagging along. Actually, I think we get the ECM thing now, partly due to a better understanding of the benefits and our plan to improve processes while implementing ECM. So now, we need to decide “what goes where?”
The planning that is going into this decision is really a series of what-if scenarios; right now, we are not being driven to content separation by growing volume. That is the mixed blessing of being small; we won’t ever have enough content to make these choices easy. We do have a mixed set of uses though, and that seems like a good reason to separate content. For example, we have a small collection of documents that are business critical, and that are generally limited to a small subset of our users. We don’t need to break these out, but by doing so, we can build a very simple site for all this stuff. Then, even if one of the ‘owners’ goes overboard with permissions, they won’t be able to include the world. This content also does not change much, so separating it gives us better options for running backups. Again, that isn’t an issue today, but it may become one as other content grows.
One area that we know is getting its own backend database is the support site for our lawyers – those people generate some serious content. They also deal with numerous restrictions and they swap a lot of stuff between our internal and Internet facing servers and they have some workflow enabled processes. I mention these things because having content in a separate database makes it easier to start some utilities, including SharePoint Designer, in the right place. That is a simple benefit, to be sure, but we are going to be working here for a long time, so why not make it an easy place to work. It will also make it easy to document. Don’t worry; I am not going to get up on my documentation horse today.
I will take a short ride on my ‘shameless plug’ horse. That’s because, once again we are benefiting from one of the best decisions I ever made, to purchase MetaVis Architect Suite for SharePoint. MetaVis Migrator actually allows us to ‘promote’ content from our 2007 server to a different content database on the 2010 server. This is another example of what I love about this product, they have designed it to work the way people work – what a concept. I am not sure if I talk about this product because it is so good, or because I recognized that fact very early on. Seriously, it is a great product and they are some of the best people to deal with. OK, end of shameless plug.
As my profile says, there are tons of SharePoint blogs out there and many of them espouse the importance of planning your SharePoint installation; you need to review that planning process as you upgrade to SharePoint 2010. This is a great time to improve the design.