We are currently upgrading our Internet facing SharePoint server to SharePoint 2010. We’ve done this drill before; in fact, since we started out with a WSS 2003 site; we have done this drill more times than I care to remember. When we were discussing how to go about this upgrade, we decided not to upgrade at all. We decided not to “migrate” either; we decided to build a new server and rebuild all of the content. What made us decide to take this approach? Simply put, our past caught up with us.
In 2005, when we installed our first WSS server inside our firewall, I built a couple of example sites, demonstrating a few cool features, and then I showed it to my coworkers. Very few of them were as excited as I was, okay, most of them weren’t excited at all, but my boss asked “could we let our members use this?” Of course the answer was yes (see my AIIM blog from several months ago to know why the answer is always yes). After considering all of the possibilities, we decided that a separate Internet facing server was the best solution for us. To my surprise, we started finding more uses for SharePoint on the external site than we were finding internally. We built sites for our members, for the outside attorneys we work with, for various vendors, consultants and business partners, for our annual charity golf tournament, and of course, for our customers. The key phrase in the previous sentence is “we built sites” – in fact, we were site building fools back then.
Sites seemed like the perfect solution for every need; they were easy to build, easy to “brand” (although we do very little branding) and it was easy to set permissions for sites. On the other hand, creating sites for every business partner was like giving houses to college freshmen; in a word, overkill. We have a couple of partners that like the idea of having a calendar, a set of useful links and a few document libraries, but most of the people we are working with simply want to share documents, lots of documents. This time around, the freshmen are getting dorm rooms, in other words, we are creating document libraries in a common site. Some of our partners, the ones using more of the features SharePoint has to offer, are getting sites, but very few. I like this solution for many reasons, but here are my three favorite ones:
1) Simplicity – It is so easy to add a Document Library to an existing site, establish the permissions for a new user and send them the same instructions you have sent everyone else on that site. I realize that sounds like the form letter approach, but sometimes, simple is better. When all you want to do is browse for documents, an uncomplicated site that has your document libraries is really all you need.
2) Navigation – The biggest complaint we get about SharePoint dissipates quickly when we remove an unnecessary level from the trail of breadcrumbs. Go to our server, go to the type of business partner that you are and open your library. Since everything is permission trimmed, that’s all the user sees anyway. We urge them to bookmark the site level, rather than the server, but we like them to know that the server main page is always a functional starting point.
3) Appearance – Nothing makes SharePoint look worse than blighted Team Sites with empty link lists, old announcements and a calendar devoid of events. By contrast, a rich page of content carefully chosen for a group of business partners is easy to fill and easy to change over time.
As we move our existing content into its various new homes, I am really getting happy with the results. We are going to end up with a clean, minimal server that meets everyone’s needs. Since this is built on SharePoint, if those needs grow, we can accommodate them. Until then, we are giving everyone what they need.