SharePoint Configuration vs. Customization

For those of us who attend a lot of SharePoint events, we hear the question often: when is the right time to configure, and when should I customize SharePoint? What are the best practices?

Well, there really aren’t any best practices, per se. What is a best practice for one organization may not be the best path forward for others. Microsoft provide guidance on working with the platform, and has hard-and-fast rules around what changes will negate your support agreement (you don’t want to do that). But the platform provides ample leeway in how you build out your system.

I define “configure” as taking an out of the box component (list, library, web part) and modifying its various settings and attributes, including adding things like columns, fields, metadata, and so forth. All of it is done within the supported “framework” of SharePoint, and should be, by definition, supported by Microsoft and scalable/upgradable to the next version.

I define “customize” as using SharePoint Designer, Visual Studio, or .Net code to modify SharePoint outside of its normal framework, which could make the site difficult or impossible to scale/upgrade, and could cause support issues with Microsoft. I’m not trying to make this option sound overly negative – many customizations are well-built and do not cause problems inside of SharePoint. More importantly, they are necessary to help the organization meet its operational vision for SharePoint, and deliver a platform that meets business requirements. But SharePoint development does not equal .Net development, and I cannot emphasize enough the strategy of first understanding what is capable out of the box, then understand what can be done through configurations, and finally resort to customizations if the first two cannot deliver what you need.

There is plenty of online documentation around specific configurations and customizations, but there are no “standards” for doing so, as the standard may be different by organization.

At the end of the day, if the business value of “breaking” SharePoint to build, in effect, a custom .Net application inside of a SharePoint shell exceeds the cost of support and future upgrade, then by all means break the SharePoint framework and deliver value to your customer.

But if your strategy is to build a system that can be readily be upgraded in a year or more, it probably makes sense to build within the SharePoint framework.