Custom Master Pages, Custom Site Templates and Sandboxed Solutions are NOT Recommended for Office 365 Sites

As the pace of updates to Office 365 continues unabated, Microsoft is recommending strongly to limit customizations such as custom master pages, custom site templates and sandboxed solutions. There is a general article providing some advice on planning these customizations here with recommendations on what types of customizations pose the most risk to the sustainability of adopting future changes to the Office 365 user interface.

There was also an updated session at the last Teched Europe conference where Microsoft is recommending to avoid using these types of customizations.

If you are customizing SharePoint and expecting Microsoft to respect your customizations, don’t count on it. When you start customizing, you’re essentially forking the code from the moment of time when you start building the customization. As Microsoft adds additional features (which it is doing very frequently), your customizations do not automatically get these features. In addition, there is no guarantee that your customizations which depend on underlying CSS styles, XML structures, etc. in the Office 365 product will continue to work as Microsoft tweaks these underlying structures.

Custom Site Web Template

The key challenge with creating your own site definitions and web templates is that while they are based on underlying out of the box templates (e.g. a Team Site Template) they do not receive any new features from those underlying templates as they are updated. If Microsoft adds additional features to those out of the box templates, your custom site template does not receive these features automatically – in effect, your custom site template is now based on a moment in time version of the out of the box site template. This means your custom template becomes further and further out of the date as Microsoft adds additional features.

Custom Master Pages

Custom master pages have been used for years to customize the SharePoint look and feel to inject branding into the default user interface. Many organizations spend LOTS of time, energy and money to make their intranets branded.

When you customize the default SharePoint user interface in Office 365, you’re now assuming a fixed framework underlying that customization. However, the Office 365 interface framework is evolving and there is no guarantee that your custom master page will continue to work as the underlying CSS styles, XML, HTML, Javascript, etc. that is provided as part of the out of the box framework will support your customizations in the future.

Another consideration for custom master pages is that they are specific to SharePoint. Microsoft’s key mission at the moment is to provide integrated branding across the entire Office 365 service including Outlook, Office online, Yammer, Delve, etc.

A good example is the basic navigation for SharePoint and the look and feel around it. The basic navigation is rapidly evolving with Office 365 and if you start building a master page based on these navigation constructs your master page could either break in the future, not be compatible with other Office 365 services and/or not leverage new features coming in the future.

Microsoft is also evolving its own branding service for the entire Office 365 service so you can brand it across all services.

Sandbox Solutions

Sandbox solutions come in two flavors – custom managed code and no code solutions. Office 365 does not support custom managed code running in a Sandbox solution at all. You can deploy sandbox solutions that contain 100% client side code and declarative markup.

Even on premise, Sandbox solutions are officially “deprecated”:

While developing sandboxed solutions that contain only declarative markup and JavaScript — which we call no-code sandboxed solutions (NCSS) — is still viable, we have deprecated the use of custom managed code within the sandboxed solution. We have introduced the new SharePoint app model as a replacement to those scenarios that required the use of managed code. The app model decouples the SharePoint core product from the app runtime, and this enables much more flexibility and gives you the ability to run the code in the environment of your choice. We realize that our customers have made investments in coded sandboxed solutions and we will phase them out responsibly. Existing coded sandboxed solutions will continue to work in on-premises SharePoint farms for the foreseeable future. Given the dynamic nature of online services, we will determine support needs for coded sandboxed solutions in SharePoint Online based on customer demand. NCSSs continue to be supported. All future investments will go to making the new SharePoint app model richer and more powerful. Accordingly, we recommend that all new development should use the new app model whenever possible. In scenarios where you have to develop a farm solution or coded sandboxed solution, we recommend that you design it so that it can easily evolve toward a more loosely coupled development model.

However, even currently supported development models in Office 365 are evolving. For example, if you built an “Auto-hosted” App these are no longer supported in Office 365.

The key recommendation is keep your hard core code off of SharePoint and as loosely couple to underlying SharePoint services as possible. Use client side APIs instead of the old server side APIs to build your customizations and keep track of the evolving APIs.

Office 365 Development Best Practices

Microsoft has an Office 365 Development Patterns and Practices site on GitHub that contains a number of sample coding patterns as well as documents outlining best practices. You can find the site here.