At the Ignite conference, it was clear the vision Microsoft has for Office 365 and the SharePoint platform is the cloud, but what does this mean for developers?
I attended a session on future proofing on-premises SharePoint development to be ready for the cloud. Vesa Juvonen, the senior program manager within the Office 365 engineering team, led this talk. He had some great direction to share with us developers. Using Vesa’s session as a guide, there are a number of ways to get your on-premises SharePoint portal ready for the cloud.
Is the farm solution going to work in SharePoint 2016?
Yes it will, but the app model with add-ins is the future for on-premises deployments.
Microsoft is quite clear they will make investments primarily on the app model side for on-premises so it better aligns with the development story for the cloud. That means you will be able to write your app once and use it for both cloud and on-premises deployments.
Is the farm solution ever going to work in SharePoint online?
No, farm solutions are deployed across a SharePoint farm. If you deployed a farm solution to SharePoint Online, it would impact customers sharing the same tenant.
Shifting your on-premises SharePoint development to the cloud
First of all, here are a some general tips to start preparing an on-premises SharePoint development for a move to the cloud. Even if the cloud is not on your organization’s radar in the short term, is it worth considering how you might transition an on-premises site in the future.
- Gradually move to the app model. Microsoft is investing heavily in this and it isn’t dead or going anywhere.
- Avoid using sandbox solutions
- Understand the impact of your farm solution
What happens if you want to move your solution to the app model? The simple answer would be to rewrite your solution in the app model. There are no tools or techniques that you can use to easily move over to the app model.
Things you can do right now to avoid future maintenance and rework of your SharePoint development
With these recommendations you can avoid future maintenance and rework of your development. You can develop once for on-premises and the cloud.
Content types and site columns
Provision content types and site columns using the API. With this approach objects are created directly in the database (unghosted) and don’t have any dependencies on the file system.
List definitions
Avoid using list templates for your list instances. Custom list templates have unique identifiers and they create dependencies on list instances to the schema.xml file of the list template. Consider using code to provision your list instances.
Field types
Don’t use custom field types within your farm solution. Data stored in the list database will have a dependency on the custom field type, which causes all sorts of issues during migration to the cloud. Consider using only field controls for presentation or use client side rendering for the list editor overrides.
Site definition/web template challenge
Today you might be creating site definitions for your on-premises deployment. This can be challenging especially when it comes to upgrades and migration to the cloud. Consider using a model where you start with an out of the box site template and configure it with the necessary business requirements.
Timer jobs
We’re not going to have the option of deploying a farm solution to Office 365, so how do we handle SharePoint timer jobs? Azure WebJob to the rescue. This brings the concept of the SharePoint timer job. An alternative option would be using a scheduled task, PowerShell and the SharePoint API.
What happens if you’ve been developing the wrong way and want to fix your existing farm deployments? Unfortunately there is no easy way to fix it right now. Microsoft is currently working on more guidance and details to get you there, so stay tuned. If you want to stay close to this topic I would recommend visiting the Microsoft Office 365 Patterns and Practice portal on a regular basis and follow their updates.
