I was recently asked to comment on a recommendation that SharePoint leaders should phase out on-prem SharePoint customizations that may inhibit a cloud migration. The argument goes that tightly coupled customizations likely won’t make the hop to the next on-prem version, let alone the relative long-jump to the cloud, and thus you should rework them now to prepare for migration. While I agree with the overall sentiment, I believe IT leaders should be cautious about needlessly allocating resources for this effort, and should favor a point-forward change in how they architect SharePoint customizations.
We run our projects using an Agile methodology, which means constantly being on the prowl for wasted effort we can jettison. One way we do this is to put off work until it needs to be done, for fear that circumstances will change and render our work worthless. The longer we can responsibly wait, the lower the chance that a significant change will occur. I believe the same line of thinking applies here. Unless there are concrete plans in your organization’s future to move to Office 365, I see no reason to actively remediate customizations that are, in every other sense, working just fine for you (I dub this the If it Ain’t Broke postulate).
Also, bear in mind that 2016 is the Year of Hybrid for SharePoint. We are going to see more and more features and tools that will enable customers to easily access some online features while maintaining their on-prem footprint. It makes sense why this is happening; Microsoft’s largest customers are also the ones most likely to host SharePoint on-prem, so they need to offer easy ways to move to the cloud piecemeal instead of all at once. What this means for you is that you may be able to switch to a hybrid model in which those pesky customizations continue to hum along undisturbed while you get to take advantage of select functionality of O365 in a seamless way.
Even if a future move to the cloud is unlikely, it’s still a great idea to build for the possibility of an upgrade down the road. The Add-In (previously called App) model for O365 and SharePoint is robust, and growing more so all the time. Microsoft recommends that enhancements be built using this model and that you employ methods like Sandbox or Full Trust Solutions only if you can’t get the job done with Add-Ins. There are a wealth of resources to help with this, some of which I’ve linked to below.
Note that no one is claiming using Add-Ins will be easier than other customization avenues. Your team may be practiced in custom master pages, script editor web parts, and timer jobs; ours certainly was. We have had to figure out bit by bit how to get the job done using this new model, and it takes some time. As a benefit, though, you not only get a solution that is as future-proof as you can go, you also get much better deployment/release management options, as well as a security model in which it’s much harder for errant code to crash your farm. As a bonus, once your team learns to use Provider-Hosted Add-Ins, they are essentially doing web application development with access to the SharePoint client context, and the playing field really opens up for them in terms of customizing the experience and interacting with systems and data stores outside of SharePoint.