Future Proofing SharePoint Customizations
I had a question come in from a customer who is currently on SharePoint 2010 running on-premises. Their question was “how can we future-proof the customizations we make in SharePoint today?” I thought this question was worth a post.
So the answer is of course, you can never completely future proof your customizations but here are a few key considerations that will help smooth the transition….
Understand what SharePoint can do out of the box
Too often I see customers that have built customizations or solutions that don’t utilize out-of-box functionality. I know this is easier said than done, because SharePoint packs a lot of features and functionality in to the product – but the general idea here is that any time a business problem or solution need is raised, the first step is to start with out-of-the-box capabilities. How far can you go with out-of-box? What can’t it do? Taking this approach could help to minimize customizations and in the long run, grease the skids for a smoother migration.
Resource: My SharePoint Saturday talk from a few years ago – 5 worse mistakes to avoid with SP development (skip ahead to slide 20 or so)
Understand Deprecated features list in 2013
There are a handful of features, sites, web parts, etc. that are either no longer part of SharePoint 2013, or we’ve publicly stated that we are no longer investing in it. We’ve had a few customers look at rolling out capabilities such as document workspaces and we always advice against doing this in SharePoint 2010 given that the feature is deprecated. This is true even in cases where features are still supported in SharePoint 2013. (most deprecated features will upgrade and are supported in SharePoint 2013 – but no guarantees for SharePoint v. Next.
Resource: Changes from SharePoint 2010 to SharePoint 2013 - https://technet.microsoft.com/en-us/library/ff607742.aspx#section4 or https://office.microsoft.com/en-us/sharepoint-help/discontinued-features-and-modified-functionality-in-microsoft-sharepoint-2013-preview-HA102892827.aspx#_Toc339867839
Sandbox Solutions and Apps for SharePoint
When SharePoint 2010 and Office 365 (“Wave 14”) launched we introduced Sandbox solutions as a way to develop customizations and run those in Office 365/SharePoint Online. If you want to develop customizations in SharePoint, any compiled code needs to be a sandbox solution to work in the cloud. Full-trust code will not work in Office 365 multi-tenant, and there is no foreseeable plan to allow for this to happen. In SharePoint 2013 we introduced a new application development model – Apps for SharePoint. This is an entirely new dev methodology and is really the go-forward strategy around customizations in SharePoint. Apps for SharePoint won’t work with SharePoint 2010 – this needs to be understood. So if you are running SharePoint 2010 and need to customize, first try to build as a sandbox solution. This is supported in SP2010 and SP 2013, cloud and on-premises. If you are running SharePoint 2013 and you want to future-proof your design, then build a SharePoint App, using the new development model. This works in SharePoint 2013 on-prem and cloud, and this is the go-forward strategy for SharePoint customizations.
Resource: Sandbox solutions - https://technet.microsoft.com/en-us/library/ee721992(v=office.14).aspx and https://msdn.microsoft.com/en-us/library/ff798382.aspx
Resource: video – code for the sandbox - https://msdn.microsoft.com/en-us/SP2010DevTrainingCourse_CodeForTheSandBox
Resource: SharePoint Apps - https://msdn.microsoft.com/library/office/apps/fp179930(v=office.15)
Vet out 3rd Party Solutions
Some customers I work with have done an assessment of SharePoint 2013. They love what they see but their biggest blocker to migrating in the near-term is that they have bought 3rd party add-on solutions, and those solutions aren’t yet SharePoint 2013-ready. Microsoft does have a partner ISV program and we do our best to inform and educate all our partners on our SharePoint roadmap, and we have hundreds of great partners that are SharePoint 2013 ready – both for on-premises only solutions (full trust code) and also leveraging our new SharePoint App Store and the new app dev model. But the fact remains that there are still a number of partners who have not updated to SharePoint 2013 yet. And for some, it isn’t on their near-term roadmap. My advice for those considering a SharePoint 3rd party add-on is to go through a validation process. Who builds it? How long have they worked with SharePoint? Are they SharePoint 2013 ready? Does it work in Office 365? What is their product roadmap? Is there any other feedback or reviews that you can track down? The more you know, the greater chance for no surprises come upgrade time or migration to the cloud.
The other consideration here is what is new in SharePoint 2013 (or just around with the corner with Yammer integration and new apps). How will the 3rd party add-on work in SharePoint 2013? Does SharePoint 2013 introduce new functionality that will make the 3rd party add-on obsolete or less critical? You may still opt to go with the add-on, but then you at least know it is a short-term investment and you can plan accordingly.
Resource: Apps for SharePoint store (SP 2013 only apps) - https://office.microsoft.com/en-us/store/apps-for-sharepoint-FX102804987.aspx
Resource: SharePoint Reviews – independent website - https://www.sharepointreviews.com/product-directory
Package Customizations and follow a methodology
When you do determine that customization is necessary, be sure to follow the guidance and methodology for custom dev. Document why the customization is needed, the business problem it fixes, and the department or team that is going to leverage the customization. This too often gets thrown by the wayside and then I’ll have meetings with customers that know they have customizations, but they don’t really have a good sense about why they customized. Many times the developers have since moved on to different jobs or left the company. Teams change and processes evolve. A clearly documented list of customizations can be a huge help come upgrade time – even if the “documentation” is just a simple custom list that you create in SharePoint. And along those same lines, customizations should be packaged up as wsp files, and go through the same methodology as other custom code. Unfortunately, I’ve seen too many times where a customization was deployed by dropping a few .dlls in the GAC and updating the web.config file manually. This can be a major challenge come upgrade time. Often these manual customizations won’t show up in upgrade reports, and only surface during upgrade tests and validation of functionality post-upgrade.
Resource: SharePoint 2010 test and deployment process - https://msdn.microsoft.com/en-us/sp2010devtrainingcourse_testinganddeployment
Bucket customizations and document
Finally, I think it is important to bucket your customizations, or group them together based on complexity. “SharePoint Customization” or “SharePoint Development” has a wide range of options. There are very simple customizations. For example a bit of javascript embedded on a page to change the behavior. Or branding customizations, where all the customization files are html, javascript, image assets, and css and stored in libraries within the site. And then mid-range customizations such as event receivers, custom workflow, or a custom web part. And then there are the more complex customizations involving server-side full-trust code and modifications to an entire web application, service application, or even central admin integrations. Not all customizations are created equal and I think it is important to consider this.
Resource: SharePoint 2010 Design Considerations - https://msdn.microsoft.com/en-us/SP2010DevTrainingCourse_DesignConsiderations.aspx
Final Thoughts
As I mentioned above, there is no way to fully future-proof customizations, but I think the steps above go a long way in easing the upgrade or migration process. I’d also like to add that in my opinion the SharePoint product team has done a great job of reducing the upgrade and migration risk with SharePoint 2013. There is still work to do, but the ability to upgrade a web application to the SharePoint 2013 platform but keep individual site collections in 2010 mode for a period of time goes a long way in easing the migration efforts. It doesn’t have to be all-or-nothing over a weekend. SharePoint administrators now have the ability to upgrade one-step at a time, and move sites over one-at-a-time as soon as training, help desk, and communication planning are all in place. And of course, those that have already moved to Office 365 and SharePoint Online, we will upgrade the service regularly and ensure that customizations made to SharePoint in this environment continue to work, and provide proper communication if customization support does change down the line.
Resource: SharePoint 2013 Upgrade diagrams - https://technet.microsoft.com/en-us/library/cc263199(v=office.15)#upgrade