Building public-facing websites using SharePoint 2007: Planning

ObjectSharp has been working with SharePoint technologies for years now: building public facing websites and intranet for the clients, developing custom SharePoint web parts and features, designing custom templates, and so on... Oh yes, I forgot to mention hundreds of hours of SharePoint training (public and private) for developers and power users that we have taught to our clients. But, despite this tremendous amount of SharePoint expertise ObjectSharp has built up internally, we never had time to move our own corporate website to Microsoft Office SharePoint Server 2007 platform. Long story short, finally, the vast benefits from moving to SharePoint platform outweighed the problems with dedicating our own internal resources to this project, and we have received a go ahead to proceed with the project. As a project manager for this SharePoint migration project, I would like to share with you the experience and the certain amount of wisdom we have gained from this project of moving our original "sophisticated and fancy-looking" website to the SharePoint-based web content management platform.



As in any other project, we have identified the goals that will determine if the projects have been successful or not:

  • SharePoint-based website must look exactly (or as close as possible) as our original website
  • SharePoint-based website must keep all existing functionality of the original website (public and administrative parts). All additional features for the new site will be added in the future website versions.
  • SharePoint-based website must leverage existing SharePoint features and minimize the amount of custom code as much as possible
  • The migration has to be transparent to our clients and the effect on our SEO ranking should be minimal


Planning infrastructure for SharePoint environment

To properly plan the infrastructure for SharePoint environment we need to know

  • What are we going to use SharePoint for?
  • What features of SharePoint will be utilized?
  • How many visitors do we expect on the website? What's the expected server load?
  • What will be the expected size of the website? How often will the website be updated?
  • What are the performance requirements for the site?
  • What are the availability requirements?
  • What are our disaster recovery policy and standard maintenance schedules?

Here is an excellent link for estimating performance and capacity requirements for SharePoint servers: Also if you require redundancy and availability in your SharePoint environment here are the guidelines from Microsoft for that: and


Planning the development and production environments

It's always a good idea to separate development environment from the production environment. D'oh! Ideally, you will have separate SharePoint farm for developers, testers, content authors, and, of course, separate SharePoint farm for production.

  • An authoring environment in which site content will be authored and approved for publication. This will also be the environment that site designers use to create layouts, master pages, and other site artifacts. This environment includes an Office SharePoint Server 2007 farm along with the workstations that site designers, authors, and editors use.
  • A development environment in which custom site elements will be developed. This includes developer server workstations, a source control system, and a small Office SharePoint Server 2007 integration farm for integrating the various coded elements and testing them by using sample content.
  • A production environment in which the Internet presence site is available to site visitors. This includes two server farms:
    • The primary publishing farm
    • A parallel but smaller farm that provides failover in case the primary farm becomes unavailable, and that also will be used to pilot new site features.

For more information visit


Determine website structure and navigation

To comply with the project goals we needed to keep the existing site structure and navigation, so we have copied over the website structure to the new site. Luckily, SharePoint allows you to shape your site structure any way you want. We have created a single web application for our website, as it's more than sufficient. We have enabled anonymous access to the web application. We have also extended this web application to include support for SSL.

Now, we had to find the way to transfer our navigation menu to the new site. One of our consultants and Microsoft MVP, Justin Lee, had an answer for us: to use ASP.NET menu control with CssFriendly adapter. With a minimum of configuration tweaking and no custom code necessary we're able to get the menu transferred within an hour or so, but let's not jump ahead J


Determine authored elements: custom master pages, stylesheets, page layouts, content types, web parts, etc.

At this point, need to come up with a draft of what and how many master pages will we require, what kind of page layouts do we need, what stylesheets and javascripts will be included in master pages or page layouts, what content types and site columns we need to create, what web parts and/or features we need to develop, and so on and so forth. Basically, we need to try to determine the kind of content that will be added to our website, and the best way we can implement those authored elements.

Because master page will be loaded with every page, you need to make sure that your master page(s) contain only the minimal amount of content. In other words, only include primary stylesheet and javascript files to the master page to make sure that your pages load fast(er). Microsoft has an excellent guide on how to create minimal master page. Please note that minimizing the number of master pages will help to promote the consistency of styles and branding throughout your site (ideally, you would have only one master page).

When determining the page layouts and content types required for the website, you need to know what kind of content will be present on the page(s) and how it will be displayed to the public. I usually compile a list of different type of pages that the website will have, along with the list of entries that will be displayed on those pages. Having an original wireframe for the website will make this process so much easier.

Almost all content in our new SharePoint-based website will be in a form of a web part. Fortunately, SharePoint has a lot of built-in web parts that will be able to accommodate most of the content to be moved. Content Editor webpart, Content Query webpart, Image webpart are three web parts that you will probably use the most on your website. Naturally, sometimes your website will require functionality that SharePoint does not support out of the box, so Microsoft has provided the tools that will help you to develop all kinds of custom features. You need will to download Microsoft Office SharePoint Server 2007 SDK, SharePoint Extensions for Visual Studio 2008, and, of course, the copy of SharePoint DLLs from the SharePoint server! Please note, you can find a lot of information for SharePoint developers at


Now it's time for a little bit of SharePoint branding and development….

Related resources: