As I meet with technology and business executives, one of the topics that keeps frequently coming up is whether to customize SharePoint of SharePoint Online in Office 365. There continues to be a lot of misunderstanding around what can be done safely, and what is going to cause long term stability or maintenance problems.
In the Beginning
The first thing to understand is that not all customizations are the same, or have the same level of risk or impact within the system. In the early days of SharePoint, the platform was completely open for customizations and in some cases developers had free reign to do whatever they wanted or needed. In some cases, poor decisions were made or bad code was written. Generally, the mistakes fall into a few categories; the developers were inexperienced with the platform and didn’t know any better, or they were not forthcoming with information on what kind of impact there would be maintaining the solution or when upgrading SharePoint to the next version.
Over time, SharePoint started to get a bit of a bad rap as being difficult to upgrade if there were any customizations or commercial add-ons within the system. The people that know the system, of course, know how to mitigate this risk, and address the upgrade challenges -- but again, that assumes knowledge and competencies that only a small percentage of people have.
Evolution of Customizations
Over time, Microsoft and the community-at-large learned some valuable lessons and responded with better guidance, as well as new options for how to interact with and customize SharePoint. The focus shifted more toward client-side development and interacting through standardized web services.
- Full Trust Solutions: Server code that runs within the server, this is the traditional SharePoint Server customization, which is typically deployed with a .WSP file.
- Sandbox Solutions: Microsoft’s first attempt at providing a system for customizations that runs in a safe, isolated space to ensure customizations have little to no negative impact on SharePoint sites. Unfortunately, this did not prove to be a powerful enough solution and so it was deprecated.
- Add-In (initially called App) Model: Isolated applications that can interact with SharePoint through published APIs in a safe manner.
- SharePoint Framework (SPFx): A new, lighter method of developing SharePoint interface customizations through client script, without a full Add-In package.
As Microsoft has evolved, the public APIs for SharePoint have also evolved. The client side APIs for interacting with SharePoint have become very robust, and while you cannot do everything that you used to be able to do with the server side APIs, it could be argued that it provides a good set of safety rails for the average SharePoint developer, ensuring that the risk to long-term stability is minimized.
What spurred the idea for this blog post was a customer conversation around a request for a tracking system that needed to be setup and then reset for each new calendar year. Using the published APIs, it is simple to create a process that can safely automate the setup in a repeated manner. The customer in question was concerned with implementing a customization that could have a negative impact on the system in the future, and stated that they have a "no customization" policy. It proved to be an interesting conversation as I uncovered the root of the concerns and perceptions. In the case of the solution we were proposing, there would be no customizations deployed to SharePoint, and therefore no artifacts left behind that could impact SharePoint in any way. Since our tools would be run locally and interact with SharePoint through the REST services, our solution would be safe and effective. This is the same approach taken by most SharePoint management tool vendors, like our partners at Sharegate and Metalogix.
At B&R, our approach is always to understand the goals of what the client is trying to accomplish and then figure out the most appropriate way to accomplish those goals. In some cases, we still get requests that are best addressed with the traditional Full-Trust code model. In those cases, we have to have an open and honest conversation about what that means, and what the ongoing costs will be for the customer. At times, that is the only way to address the requirements (for on-premises) customers, while in other cases it may be a more cost-effective and attractive fit than adopting a provider hosted add-in. Whatever the path forward, we make sure that the pros and cons are fully understood.
While we do still find ourselves building some Full-Trust solutions, it is difficult to argue against client-side code being the future, and many of the modern SharePoint development techniques find their way into our solutions one way or another.
Can We Help You on Your Journey?
Are you experiencing issues upgrading a farm with customizations, or are you looking for assistance in getting a solid development plan in place for the foreseeable future? We would like to help you make the most of the platform, and leverage all the options that are available to you. If you would like to talk through your goals and challenges, please reach out and setup a consultation.