I keep getting almost daily emails concerning WebTemplate element support and when it would be proper technical approach for the site provisioning with SharePoint 2010. There’s no doubt that many times there’s requirements to be able to provision sites as easily as possible from content editor perspective, so let’s still elaborate or evaluate different options and common misunderstandings with these options.
Detailed explanation of different available options can be found from my previous blog post (also has step by step guidance on custom WebTemplate usage). Mirjam also has done good work on explaining WebTemplate in her blog post titled as same as this one. Notice that when I’m writing about web templates, I refer to WebTemplate element usage with onet.xml, not what get’s created when you save site as a template from browser (site template wsp package), even though site templates uses WebTemplate element in them.
Here’s quick list of advantages and disadvantages on both approaches. Let’s also add some cloud perspective on the topics, since it seems to get cloudier and cloudier all the time, especially now with the Office365 being released few months back.
Notice that I didn’t include feature stapling or features to the game, since in this post we’ll concentrate on having new options available in the Create Site functionality, rather than just changing how the existing templates will work using feature stapling or manual feature activation. Following chapters will list random pointers for both sides (advantages and disadvantages) which you should be considering when you create your technical plan for customizations.
In 2007 we didn’t have any other options than using site definitions with certain business requirements, so it’s understandable that there’s numerous sites which are build technically using custom site definitions. These deployments won’t be cloud compliant unless dependency to these site definitions is removed. This means that these kind of deployments cannot be migrated to Office365 (Standard or Dedicated) without complete refactoring of code and content as pre-requisite.
These kind of refactoring projects are not simple and could be surprisingly expensive. If you are planning to migrate away from custom site definitions, you might want to consider to take a approach where you rebuild customizations using WebTemplate element and then migrate just the content from the existing sites to newly developed customizations. You might want to consider this as one of your options when you define required changes for the customizations anyway due the version upgrade from 2007 to 2010.
As a summary, you should be using WebTemplate element whenever possible to provide site provisioning options to your deployment.
As a Microsoft consultant, I also personally would prefer people to use more cost efficient options in long term when they design their customizations to avoid any hidden cost impact or unnecessary cleaning in later stages of the deployment life cycle. By using WebTemplate element over site definition, we still provide complete flexibility for the customers to host their SharePoint wherever they want (cloud or on-prem) and don’t cause any “stupid” technical limitations for their possible future cloud transition to any cloud platform (like Office365). Even though your deployment would have been currently planned to be an on-premises deployment, you shouldn’t lock it’s future by using site definitions and cause also additional costs as part of the upgrade to following SharePoint major version (o15).
Hopefully you were not forced to do any SP2003 to SP2007 upgrades where custom site definitions where used, but that’s exactly the route where using site definitions also in future will drive deployments. These migration issues should be major consideration point for any SharePoint deployment from overall costs perspective. By selecting WebTemplate approach, your deployment will be as easily updated to following SharePoint major version as it would be using simple stapled features. This has major cost impact on the overall lifecycle costs of the deployment.
Notice also that since WebTemplate element usage is also based on same onet.xml structures like site definitions, you can easily learn how to use them, so that your customization architecture is following up guidance's to avoid any unintentional costs for the deployment during maintenance phase of the sites.
So – forget site definitions, start using WebTemplate elements in your deployments, this will be beneficial for your customers, you and any SharePoint deployment in short and long term.
If you disagree any of the pointers listed above, don’t hesitate to contact or write comments on this blog post. We would like to also understand what are the concerns and possible issues you might have run into. Thanks for the comments and pointers advance.