Karthik Murugesan Posted on November 10th, 2013

Custom Site Definitions

Custom site definitions in SharePoint 2010 are site templates customized and saved as SharePoint solution packages (WSP file). If you are planning to use these custom site definitions after you upgrade to SharePoint 2013, you must plan to recreate them in 2013 mode before you upgrade your site collection.

You have to create them again because custom site templates apply to specific versions and don’t always look or work the same way in subsequent versions. SharePoint 2013 has significantly changed the underlying components it uses to render the appearance of SharePoint sites. For customizations made to default components in SharePoint 2010, these new changes include styles, page layouts, master pages and themes.

A Little History

In SharePoint 2010, development of custom site definition is purely declarative and there is no code involved. It just involves adding two critical CAML files, WebTemp*.xml and Onet.xml. This is really good news when it comes to migration. Why is this good news? Imagine creation of custom site definitions involved procedural code that generates assemblies, then it takes more discipline to manage all the source code to reproduce the templates whenever changes are required. It is possible to create custom site definitions using Visual Studio. While there is no code involved in a site definition project you’d imagine there should be no assembly. Visual Studio by default always compiles an assembly with every project even though there are no classes. Eventually these assemblies usually gets deployed with the SharePoint solution package. So unless the developer sets the “Include Assembly in Package” property to false there might be useless assembly deployed in the GAC that may confuse farm administrators or anyone who is performing the SharePoint upgrade.

Upgrade your Custom Site Definitions to SharePoint 2013

First step in porting the custom site definitions to SharePoint 2013 is to identify what site definitions will cause the upgrade to fail and prevent the self service site collection upgrade. Unless you manage to complete at least one test upgrade you can’t really understand what customizations need further tweaking to make it work in 2013 version. During your first test migration review the error log to make a list of all the custom site definitions that prevents migration. Once you have this list of all the site definitions and respective WSP packages, go to your 2010 environment and download those WSP files. These WSP packages are either deployed at the site collection level or at the farm level. Once you have the list of WSP files it’s time to make those declarative changes required for SharePoint 2013.

Follow these steps to start updating your WSP file to make the site definition 2013 ready.

  1. Open Visual Studio and create a New Project
  2. In the list of available templates select SharePoint 2013 – Import Solution Package. Click OK.
  3. Make sure the project name is same as the 2010 WSP file name so it is easy to reference it later during the upgrade
  4. In the next section choose one of the WSP files exported from 2010 environment
  5. In Solution Explorer, find the Onet.xml file in your project and open it
  6. In SharePoint 2013 custom master page references are set to the default master page named seattle.master. If the default master page in SharePoint 2010 is customized, change the reference to that custom page in Onet.xml
  7. If you review one of the existing site templates you’ll notice there are certain set of Features included in the template. Optionally you can make sure the following set of Features are included in the WebFeatures section

    Feature Name Feature ID
    AccSvcAddAccessApp d2b9ec23-526b-42c5-87b6-852bd83e0364
    AnnouncementsList 00bfea71-d1ce-42de-9c63-a44004ce0104
    BaseWeb 99fe402e-89a0-45aa-9163-85342e865dc8
    BizAppsListTemplates 065c78be-5231-477e-a972-14177cc5b3c7
    ContactsList 00bfea71-7e6d-4186-9ba8-c047ac750105
    ContactsList 00bfea71-7e6d-4186-9ba8-c047ac750105
    CustomList 00bfea71-de22-43b2-a848-c05709900100
    DataConnectionLibrary 00bfea71-dbd7-4f72-b8cb-da7ac0440130
    DataSourceLibrary 00bfea71-f381-423d-b9d1-da7a54c50110
    DiscussionsList 00bfea71-6a49-43fa-b535-d15c05500108
    DocumentLibrary 00bfea71-e717-4e80-aa17-d0c71b360101
    EventsList 00bfea71-ec85-4903-972d-ebe475780106
    EventsList 00bfea71-ec85-4903-972d-ebe475780106
    ExternalList 00bfea71-9549-43f8-b978-e47e54a10600
    FollowingContent a7a2793e-67cd-4dc1-9fd0-43f61581207a
    GanttTasksList 00bfea71-513d-4ca0-96c2-6a47775c0119
    GettingStarted 4aec7207-0d02-4f4f-aa07-b370199cd0c7
    GridList 00bfea71-3a1d-41d3-a0ee-651d11570120
    HierarchyTasksList f9ce21f8-f437-4f7e-8bc6-946378c850f0
    IPFSWebFeatures f9ce21f8-f437-4f7e-8bc6-946378c850f0
    IssuesList 00bfea71-5932-4f9c-ad71-1557e5751100
    LinksList 00bfea71-5932-4f9c-ad71-1557e5751100
    MBrowserRedirect d95c97f3-e528-4da2-ae9f-32b3535fbb59
    MDSFeature 87294c72-f260-42f3-a41b-981a2ffce37a
    MobilityRedirect f41cc668-37e5-4743-b4a8-74d1db3fd8a4
    MySiteMicroBlog ea23650b-0340-4708-b465-441a41c37af7
    NoCodeWorkflowLibrary 00bfea71-f600-43f6-a895-40c0de7b0117
    PictureLibrary 00bfea71-52d4-45b3-b544-b1c71b620109
    PremiumWeb 0806d127-06e6-447a-980e-2e90b03101b8
    PromotedLinksList 192efa95-e50c-475e-87ab-361cede5dd7f
    ReportListTemplate 2510d73f-7109-4ccc-8a1c-314894deeb3a
    SiteFeed 15a572c6-e545-4d32-897a-bab6f5846e18
    SiteFeedController 5153156a-63af-4fac-b557-91bd8c315432
    SurveysList 00bfea71-eb8a-40b1-80c7-506be7590102
    TaskListNewsFeed ff13819a-a9ac-46fb-8163-9d53357ef98d
    TasksList 00bfea71-a83e-497e-9ba0-7a5c597d0107
    TeamCollab 00bfea71-4ea5-48d4-a4ad-7ea5c011abe5
    WebPageLibrary 00bfea71-c796-4402-9f2f-0eb9a6e71b18
    WikiPageHomePage 00bfea71-d8fe-4fec-8dad-01c19a6e4053
    WorkflowHistoryList 00bfea71-4ea5-48d4-a4ad-305cf7030140
    workflowProcessList 00bfea71-2d77-4a75-9fca-76516689e21a
    WorkflowServiceStore 2c63df2b-ceab-42c6-aeff-b3968162d4b1
    WorkflowTask 57311b7a-9afd-4ff0-866e-9393ad6647b1
    XmlFormLibrary 00bfea71-1e1d-4562-b56a-f05371bb0115
  8. Now you are ready to generate the WSP file. After compiling the project file Deploy the solution. Chances are the deployment will fail if you haven’t associated a valid SharePoint farm to the project. You can safely ignore that and go to the bin folder to get your WSP file.
  9. Upload and Deploy the WSP file in your SharePoint 2013 test environment and try the upgrade again



N Singh January 22, 2014

Really nice article. It’s very well written and easy to follow. I’m having some trouble with my custom site template though. I was able to add my 2010 wsp solution to the SharePoint 2013 server and attach my 2010 content dbs and pull up the sites on SharePoint 2013. The UI shows as the 2010 UI and everything looks good. I followed the steps you outlined to create a new 2013 wsp for the custom site definition too. Now, should I uninstall the old 2010 wsp version from the 2013 server and deploy the new one? I did that and the site doesn’t come up at all. I wonder if there’s anything I’m missing. Can the 2010 and 2013 versions of the custom site template co-exist?



    Karthik Murugesan February 19, 2014

    Make sure everything in the solution is migrated to support 2013. After that you should only have the 2013 version of the solution deployed and activated. Now the problem you are facing might be with the fact the custom solution was built. Normally they don’t do a good job of removing files deployed when the solution is retraced. May be you can try to remove those files manually and try deploying the 2013 version again.



Raja December 25, 2014

How can we make the custom webtemplates available in both 2010 and 2013 modes? Do we need to deploy separate solutions for both templates?



Leave a reply

Your email address will not be published.