When I started working with SharePoint back in 2005, deploying WSS 2.0 followed and then SharePoint Portal Server 2003 for a large client, the concept of “customization” as we define it today was not really part of the SharePoint vernacular. The technology was fairly basic back then (in comparison to SP2019, anyway) and was viewed by most customers more as “building blocks” for document collaboration than a robust platform that could meet all of their needs.

That view of SharePoint changed dramatically with SharePoint 2010, which is when the technology really found its stride, and adoption took off within the enterprise. At that time, SharePoint was positioned as the “Swiss army knife” of collaboration that could be shaped into whatever you needed it to be.

With maturity, the platform has moved away from that idea — although it remains a somewhat pliable technology. SharePoint administrators have many options available to them for designing their collaborative environments, depending on their own unique business needs. But how do we extend SharePoint to meet our needs, while also ensuring that our customizations can scale, that we can continue to support the environment, and that our users and their data will remain secure?

In an article I wrote earlier this year for the Rencore blog, I suggested that organizations need to answer some basic questions before embarking on the customization path. For example, it’s not a question of “can” you customize SharePoint, but “should” you customize?

Always begin by understanding what the technology can do without customization. It’s fundamental, and yet far too many organizations eagerly approach coding a solution before they fully understand what the platform can already accomplish. The out-of-the-box capabilities in SharePoint have become incredibly powerful, with many of the SharePoint Online capabilities surpassing the capabilities for On-Premises deployments.

The next step is to understand the costs associated with your proposed customization. You may be able to deliver the exact features and capabilities that your end users are asking for, but will your changes impact your ability to support the environment?

No matter what version of SharePoint you use today, there will be new/faster/better features in the next release. What’s more, your business requirements are constantly evolving — as are your end user requirements. Part of your customization planning must take into account your ability to keep up with all of these changes. There are always new and better ways to accomplish your business needs — but some of those “ways” may compromise the integrity of your environment, intentionally or unintentionally.

That’s one of the reasons why Rencore has been so successful in this area — organizations realized very quickly that having development standards in place, with their people were up to date on all of the latest SharePoint training was simply not enough to ensure that mistakes were not being made in how SharePoint was being extended and supported.

As I mentioned in my original post, there is some great content out there to help you understand what can be customized. For example, check out this simple outline of customization options from the Microsoft support site. This article barely scratches the surface on what is possible — but both Microsoft and the partner community have done a great job of creating content and training materials for every possible option you might consider. I also highly recommend that organizations take a look at the Rencore platform, which can help ensure the integrity of SharePoint as you extend and configure.

Originally posted on LinkedIn Pulse

By Christian Buckley