SharePoint Site Deployment Strategy 101

I have recently involved in explaining Site template and feature in SharePoint to an organization that is going to roll out many business applications built on top SharePoint 2013 platform. In this article I  just want to give a simple clarification on site template and feature and pros and cons of each definition.

Site Templates

Site templates are a great way to define lists, libraries, content types, workflows, web parts, and landing pages.  This is achieved by creating a SharePoint site, using out of the box (OOTB) functionality of SharePoint to create and design your site, then saving the site as a template.

Once the site is saved as a template, it is displays as on option when creating a site.

The following diagram depicts the flow for this deployment method:


It is very easy to define your template. No code is required. Using SharePoint Designer, you can additionally define workflows, which can also be saved to the template.


This is great to quickly define your site structure and then create new sites based off of the new template, however, it becomes problematic when you need to update the template and retroactively apply those changes. For example, if you add a new list to the site template, only sites that are newly created will contain that new list.  Existing sites require manual intervention or a coded approach to provision the changes to multiple sites.  Options for coded approach can be to use:

  • PowerShell scripts: Doesn’t require compiling and is a skill set that many SharePoint Administrators have
  • Console apps: Requires developer skills and understanding of .NET framework.


Features are packages that define content types, lists, libraries, web parts, and even functionality when activated.  Features can contain logic that defines what to perform (configure) when activated, what to do when the feature is being upgraded, and what to do when being deactivated.

The following diagram depicts the process for provisioning sites using features:



Updates to existing sites are easily managed by deploying new versions of the feature.  Existing sites that are using the new feature are easily updated during the deployment process.


Requires developer skills to create the feature.  Unless scripted, the features must be manually activated after creating a site. If sites are not created that often, this may not be a problem.


  1. July 9, 2015 — 5:06 am

    Very good written information. It will be supportive to anyone who uses it

  2. July 9, 2015 — 8:48 am

    You should check out the O365 PnP Provisioning Engine ( which is a whole lot better to work with than Site/Web templates and definitions in SharePoint 2013/O365.

    Upgradability, maintainability and migratability is a lot easier with that approach too 🙂

    • nnthuan
      July 9, 2015 — 1:32 pm

      Thank you mate for the link. I should have indicated that this article is written for the traditional full-trust in SharePoint on-prem :).

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

© 2018 The Soldier of Fortune.