SharePoint is proven a platform for so many real-world no-code solutions, it still requires customization to fulfill business requirement, and to maximize investment for the platform, especially for middle and large organization. With SharePoint On-premises, the customization is flexible as you have several options in the development approach. You own your development environment to test everything you need. You control what to be patched when Microsoft releases a new update. You can rollback with your backup and recovery plan. Everything sounds well as you go. But with SharePoint Online, things are not that easy like the on-premises one. The development approach SharePoint Online supports is to go with client-side technologies. No server-side is supported. Sandbox mode with many limitations has been deprecated. You wouldn’t easily rollback your SharePoint Online site. This results to a nightmare to people who are responsible for roll-out of SharePoint Online in the whole organization.
Recently one of my big customers shared a concern about customization in SharePoint Online. They are afraid if one day a new release of SharePoint Online patch breaks their customization. If so how does the incident response plan and risk mitigation look like? This article is going to share you just a little bit of my experience and how Microsoft controls improvement and change in its platform, and what you should do to prevent.
First Release & Message Center
By some numbers in this post (http://windowsitpro.com/blog/office-365-numbers-ever-increasing-trajectory) you know how super large the pool of Microsoft’s customers is. And as a very old guy in software development, Microsoft must have a way to control the release to its Office 365 customers. First, Microsoft lets its Office 365 customer know what is being developed, or is an upcoming release in this website http://fasttrack.microsoft.com/roadmap
Second, Microsoft recently offered a new feature called First Release in the Office 365 Admin portal. Basically there are types of release in Office 365: Standard Release and First Release. Standard release is the default option where you and your end users receive the latest updates when released broadly to all Office 365 customers. First Release is to provide you the ability to select a group of users to experience with upcoming updates before giving Microsoft early feedback, and rolling out to your end users.
Message Center is another feature Microsoft offers, telling you upcoming Office 365 changes in order for you to have preventive actions if possible.
Preventive Action Plan
With Standard Release option, when an updated is released, it will apply to your existing Office 365. This may make an impact on your customization and you will hardly have to explain to end users and remediate issues if any. First Release is the way to go. In a real-world scenario, you should have a testing tenant (non-production Office 365 subscription) for testing. This tenant should be hosted in Microsoft USA data center. In both tenants, enable First Release option. If you are using Office 365 Admin Center Preview, access Release setting under Settings > Organization Profile. Change the setting to First release for selected users and assign some of testing users in your organization. The purpose of non-production tenant is for evaluation and testing of new update. If the update breaks your customization, you still have chance to fix it before the new remediation deployment into the production tenant.
When you are ready for the update (including your fixed customization) you can switch to Standard release to apply the release for your entire organization.
The time frame for a first release is often 2 weeks which may not be enough for your change readiness.
Folks often recommend to use out-of-the-box features as many as possible. That’s ideal but in the real-world scenario it’s not that easy, especially for business workflow in SharePoint Online. Tips to prevent customization impact in SharePoint Online:
- Do as much within SharePoint out-of-the-box with less customization.
- Read and keep track in Office 365 Message Center for upcoming change.
- Prepare non-production tenant to test every update which may potentially impact on your customization.
- Inform your end users updates and changes made by Microsoft.
- Always use up-to-date technologies that Microsoft is supporting. Office 365 PnP must be in your developer’s pocket https://github.com/OfficeDev/PnP