12

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.

Improve this question
1
  • open ended questions like this is typically no good match for our QA forum. I have converted Q to Community Wiki for now – Anders Rask Mar 29 '13 at 8:15
4

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.

Improve this answer
3
  • It is indeed a bad practice to use custom site definitions, both in SP2010 and SP2013. Several issues, especially related to Build to Build (CSD can never be updatd -it is not supported) and Version to Version (eg moving to cloud directly will be impossible and you will have feature issues like you mention) upgrade. You should in 99% instances use Web Templates instead, as they dont have the same upgrade issues since they always map to OOB site definitions. I have yet to make a CSD in SharePoint 2010, there simply is no good reason to do so.More info here bit.ly/bS8v4g – Anders Rask Mar 29 '13 at 8:14
  • Thanks, I went through this article but will deep dive into web templates @SharePoint2010 as I mostly worked with site definitions for SP2007. – Muhammad Raja Mar 29 '13 at 8:53
  • Thank you, Muhammad for the very usefull links! I don't know why I haven't stumbled into them before. – MikhailSP Mar 29 '13 at 12:47
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. "

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.