I attended the SPTechCon conference in Austin a few weeks back. While most of the lunch conversation centered around team collaboration & business process automation, there were several conversations about SharePoint and public web CMS.
The lions share of SharePoint implementations are internal; intranets and extranets. There are also a significant number of organizations that still use SharePoint for their public facing web & eCommerce sites.
How’d this happen?
If we port back, nearly a decade, the CMS landscape looked dramatically different than it does today. We were evolving from custom static brochure sites to business managed (not IT) dynamic content. SharePoint ’07 (MOSS) launched with the inclusion of the Microsoft Content Management Server functionality, enabling true enterprise grade web content management. Compared to the 7 figure Interwoven CMS implementations, SharePoint was an attractive option. The popularity of SharePoint as a portal solution had a halo effect on the public facing decision. And, many IT leaders weighed in heavily, stating their preference for one system to maintain. It all made perfect sense at the time.
Challenges with SharePoint as a public facing web solution
Branding
With the selection of SharePoint, web shops jumped on the band wagon and started rolling out public sites. The first struggle was branding. The MOSS core has over 4,000 lines of CSS alone. A few shops figured out how to work around the significant branding challenges. The Hawaiian Airlines site was always touted as a great example of SharePoint branding (it’s now running on Sitecore). Because of its complexity, very few became proficient at SharePoint branding.
Editor Experience
A common & recurring complaint is the content editing experience. SharePoint is, at its core, a collection of lists & libraries that are organized in a tree structure. Without significant custom development, SharePoint can’t customize the editor experience to the way the business operates. The result is a highly technical and confusing editing experience. Sitecore, on the other hand, makes use of insert options, standard values, page editor configuration and publishing workflows to tailor the editing experience
What about the Customer Experience?
The biggest miss in SharePoint is the lack of any type of customer experience functionality. Some marketing automation functionality can be added through a bolt-on point solution. But the across-the-enterprise omni-channel contextually-aware experience that is a primary topic at all digital transformation conferences is just not available with SharePoint.
But, SharePoint’s engrained in our organizations business process…
Many organizations have made SharePoint the standard for business process automation and compliance. A typical use case includes using a SharePoint workflow to initiate a multi-stage approval before publishing a press release to the public web. With the Sitecore SharePoint connector, users can still originate content from SharePoint, including workflow based approval.
Migration considerations when moving from SharePoint to Sitecore
For those considering migrating from SharePoint to Sitecore there’s some good news. Both systems are inherently strong at the organization of web content.
So, if you have a well architected (information architecture) public facing SharePoint site, much of that foundation can be used in Sitecore. Some example relations follow.
- SharePoint content types ~ Sitecore data templates
- SharePoint web parts ~ Sitecore components & renderings
- SharePoint term store & enterprise keywords ~ Sitecore taxonomy
- SharePoint search schema & settings ~ Sitecore Indexing Manager
An architectural understanding of both SharePoint and Sitecore is essential to designing a successful SharePoint to Sitecore migration plan.