MVP Take: What are the consequences of extending SharePoint?

Erwin: “If you’re talking about the downside of a heavily extended SharePoint environment, I can recall an experience I had a long time ago. I was working with a customer who had a relatively early build of SharePoint 2007, and they were looking for a way to rate documents with a five-star rating system. A lot of time and effort was invested – we’re not talking about a few hundred documents, we’re talking about thousands if not millions of documents. The next version of SharePoint came out and it had what the organization had already extended built into it.

However, they couldn’t just use their application because their data storage was completely different to the way SharePoint handled it. If you don’t want to throw away all that you’ve built and you want to move it to the new SharePoint version, but then you suddenly run into an upgrade blocker, you cannot upgrade until you’ve figured out how to get the old data into the new model. That is one of the big issues.”

Waldek: “You have the exact same risk in the cloud. Imagine that you have a valid need to do something in the cloud that is not available out of the box today. Therefore, you spend time and effort building that solution, but eventually, it becomes available as a part of the out of the box tool.

The bigger problem you have in the cloud compared to on-premises is that on-premises you can choose when you’re going to move to the next SharePoint version. In SharePoint Online, the train is going regardless, and you could get left behind. You will be updated at some point, eventually, and you cannot say don’t update, I want my tenant to be here. That’s not going to work. So aligning with the recommendations that apply to SharePoint Online is even more important today than it was when you were back on-premises, where you could actually control how often and when you would update.”

Erwin: “Indeed, that’s true what you say. As long as you stick with the recommendations, you’re relatively safe and extend SharePoint by means of SPFx etc. In the future, who knows. If you follow that technology, you’re pretty safe. I would say that you will not run into issues while on-premises – you can go completely crazy.”

Waldek: “That is also the case with SharePoint Online. I mean, there is still the classic UI where you could, in theory, use the same approaches that you would use on-premises. However, you could end up manipulating them or changing things that you do not own, for example, a master page or a layout.

SharePoint Online can change every week. You do not want to be in the business of manipulating the UI online because that’s just not going to work for you. You’re basically creating a ticking bomb, and it’s only a matter of time until it breaks because it will break eventually. There’s no guarantee, and the UI is not an API. So, you have to stick to what’s recommended to extend your portal beyond what’s available out of the box.”

Erwin:  “I completely agree! They provide ‘islands’, and you can go ahead and do whatever you like on your island, but don’t leave it because when you leave the island you effectively end up in DOM and that is not owned by you. It is not an API, you do not own it, but you do own the island. You can think of SPFx web parts as an island and you can do whatever you like on your island – your safe, but don’t leave!”