Microsoft announced in 2016 it would no longer support coded sandbox solutions and gave less than 30 days’ notice. Put in business power user terms, if you have developed business solutions such as an Intranet, help desk, employee self-service or other custom site on Office 365 SharePoint Online they may stop working soon if you did not build them using the correct methods. The impact could impact your ability to conduct business.
This announcement may impact any web parts, forms, workflows or branding where code was used by the original developers. Many of these are probably are core to the operation of the application solution. There are a number of other solution development approaches that will become a problem as well. This article will look at business solution development and the “critical” mistakes internal developers and consultants can make and what you can do about it.
As an independent software vendor of “packaged” SharePoint business solutions with over a thousand customers around the world, we at SP Marketplace had to design our products strictly adhering to Microsoft’s solution development guidelines so our customers would not get “burned” by the inherent changes made to Office 365 by Microsoft. The first rule we have is to keep it “native” SharePoint / Office 365. Because our products are not “one-off” development, we had to carefully architect the underlying infrastructure on SharePoint Online which will stand the test of time. From the beginning our products were designed to support the Office 365 multi-tenant environment, rather than retrofitting solutions built on premise, often with coded web parts. Given this, we thought we would provide input to what you need to look for as critical errors in building applications on Office 365 SharePoint Online.
Critical errors you can make building business solutions on SharePoint Online
Let’s say you want to (or have) build an intranet, or HR portal, or some basic business processes like time-off or a help desk on SharePoint Online. You will often start with a team site and add function from there. This is all fine until you find out that basic SharePoint has limited functionality, and its user interface is not the best. That is when a couple of things start to occur. First you look for third party web parts or apps to augment functionality, or you start coding. Many consultants like coding because it gives them ultimate flexibility and runs up the hours. Unfortunately, as many people are finding, that custom code is what breaks later with the consultant or developer are long gone. Also, to make SharePoint look better many developers do custom code for branding. All of this is fine for SharePoint on premise, but a ticking time bomb on SharePoint Online. Here are the critical mistakes we have seen:
The solution “go native” and buy vs. build
So what can you do. You may have to rewrite applications or replace them. First, I recommend if you can buy vs. build, do it. ISVs are committed to providing products that will work now and in the future. We architect and design our products for that. If you are on a support or subscription plan, we are responsible for our products working on the target platform. With the recent changes in SharePoint Online, our products worked fine with the latest version. What many consultants do not realize is the cloud is very different from on premise deployments, in that platform change is a constant and not in your control. If you build your own solutions, they need to be designed correctly or be ready to update it to support future changes. Consultants usually do not back their work to support future changes. Or if they do, it will end up costing you.
At SP Marketplace our out of the box business solutions are SharePoint and Office 365 “native”. Therefore, we ride on top of most changes. And they are 100% customizable, so the need to build from scratch is questionable from a business case perspective. They are up and running within 48 hours and the user adoption rate is high. Modules include Intranet, department portals, CRM, IT Help Desk, HR and more. If you are going to lose application use from the desupport announced, think about replacing as soon as possible.
If you do build your own, make sure you go native. Use Apps or client based web parts. Make sure you use standard SharePoint or Office 365 capabilities rather than coding anything.