Speaker : Dan Holme
Why SharePoint 2013 delivers business value and decrease risks ?
SharePoint 2010 is a great product, but not for the world we are living today. Since 2007, some revolutions appeared. People became at the center of the attention, with the mobile devices and social networking. The cloud also emerged in that period. From those trends, Microsoft developed SP2013 and Office 365. SharePoint 2010 is so 2006.
Instead of upgrading, move forward. Basically, an evolution of the workload and not a big upgrade project, because the latter deliver little or no value.
But, at some point, migration will be needed (for support reason maybe).
He does not advise to wait for the Service Pack or a specific version. The main reason is that Microsoft is also running SharePoint internally, which makes the product more stable and reliable from day 1 and from the first version. Service Packs are now just a cumulative update, introducing new features. Stop giving justification for waiting and really move forward.
Business does not wait and have evolving needs that need to be answered quickly. If IT can’t deliver, business will go around them.
Migrating to SP2013 should be done by adding services to the current SP2010 implementation. For example, by deploying the Search Center or the My Sites. Web Content Management and Mobile Devices access are two examples of big drivers to migration of the workload to the new platform.
This leads to a hybrid solution, with SP2010 and SP2013 side-by-side, each achieving different business goals.
When SP2007 is still in place, several factors need to be considered (decision tree). One of them is if SP2010 can answer to business needs, chances are that it can be done better in SP2013. At the end, there is no real business that would benefit in sticking in SP2010.
Upgrade is dead. Migrate instead. There is no In-place upgrade, a new farm has to be deployed, doing a database migration (for example). SharePoint 2013 keeps the 14 hive from SharePoint 2010 and content from that hive would still be available and still works. The user may not even see the migration to SP2013, by staying in SP2010 mode. The reason for this compatibility is the Microsoft had also to use it for Office365, to avoid having users suddenly seeing the 2013 user interface overnight.
The sequence, therefore is : build the servers, deploy the SP2010 customization, deploy and upgrade the services, migrate to claims (new features are highly relying on claims), upgrade the content databases and site collections. Don’t forget to backup and test everything. This can be in a quite short amount of time (example of 12TB of data migrated in a 4 days week-end). If something work in SP2010, it should work on SP2013. From a technical perspective, it is not possible to go directly from SP2007 to SP2013. At step in SP2010 has to be made. Don’t stay too long on SP2010 and move quickly to SP2013. Moving from 2007 to 2013 can be done with a 3rd party tool though.
Database attach upgrade should also be considered when deploying a Service Pack, starting with a clean farm and then migrating the database to the new farm, instead of an in-place upgrade.
For Cloud services, there are different kind of Cloud : SaaS with O365, IaaS with Winows Azure, managed IaaS where the management of the infrastructure is outsourced, and the Private Cloud. Truly said, “private cloud” is a new wording for “on-premises”.
Team sites are typically things that can be deployed in the Cloud, such as O365. The same for extranet scenarios or social features.
Public-facing websites, full trust solutions or development environments are more typically deployed in a IaaS.
Moving to one type of cloud or another depends of the workload, not everything must be migrated to a same cloud. Currently tools and guidance are still incomplete, and there is no magic button to move to the cloud. Hybrid service architecture challenges should be addressed early (before the business comes with a burning need). Also, architect the on-premises environment implementation to reflect O365, for example by separating the customized solutions from the out-of-the-box implementations. Building customizations for the cloud as much as possible is crucial too. Use the full-trust solution only when necessary.
This will end up with a hybrid solution, in terms of cloud type (O365, IaaS, on-prem), versions (2010, 2013), edition of SharePoint and services.