“Best Practices” for SharePoint customizations/development to easily migrate to new SharePoint versions

Question

Do you know of any documents that describe “best practices” for SharePoint customizations (especially custom developments) in order for these customizations/code (for example web parts, event receivers, workflows) to be easily migrated to future SharePoint versions? I mean that there is a high chance that these customizations/custom developments can be migrated to future SharePoint versions without too much effort and trouble.

An example about the “best practices” I am looking for: Creating custom Site Definitions in Visual Studio are not recommended anymore because they can lead to problems when migrating to new SharePoint versions  Use site provisioning/feature stapling instead.

Answer 1

Migration of controls developed using custom code has always been a problem, not when you migrate to newer versions but also when you move them to another server or on another farm.

The only reason "I KNOW OF or Experienced" Site Definitions create problems while migrating is because they can have different components in them, so when you deploy them to a different server and that server doesn't have component Site definition needs then it will definitely going to break.

An example of this is, if you add a custom master page in your site definition and then just migrate site definition to another server then it will give exception for not finding that particular custom master page,

OR

If your site definition depends on some control let say a feature that has to be in 12 hive but its not then when you will create a site using this site definition it will break process and won't going to complete site creation process.

A way to get around it is to use ULS Viewer while create a site based on that site definition to find out which feature is missing. Here's my post which shows how to use ULS viewer for those who don't know,

http://sharepointbulletin.blogspot.co.uk/2013/02/how-to-use-uls-viewer-in-sharepoint.html

Back to your real question

If you know the way you deployed your control (WebPart, Site Definition, Feature, Timer job) first time on your environment then you will not going to have a problem deploying it on another server if you follow same steps and nothing going to break, but if you deploy something that is deprecated then it might not work.

You should always look at new features for development in Newer versions to improve your code.

However if you are still looking for list of best practices then here you go for SharePoint 2010,

SharePoint 2010 Best Practices (it got all best practices not just development and migration)

And

SharePoint 2013 Best Practices

Edit 2 - Why not to use Site definitions

I am not aware of any easy way to migrate site definitions if they are not deployed as solution as in our SharePoint 2007 we have several site definitions that are not deployed as solutions, hence when I tried to migrate them to another server, I had to copy files manually from 12 hive, but when I deployed them on new server they were missing components like list features or webparts that were not already deployed on new server.

I never created a web template but after reading about it, I believe it will be easier to move across while migration.

Answer 2

Regarding customization I would add that you should be careful when decide to use InfoPath as it has limited support in SP2013 (you can't use InfoPath forms to customize 2013 workflow task forms). Quote from MSDN: "Workflow form changed from InfoPath form to ASPX form. ... Workaround: No workaround is currently available. "