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 Templates
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.
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 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”:
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.