The first afternoon session focused on the overviews of SharePoint 2013 upgrade which helped drive home what is now different when dealing with upgrade in 2013 versus the previous versions. The main topics for this session included:
Design Goals for 2013 Upgrades
The first main goal for 2013 upgrades discussed was around making upgrades safer continuing the line of “do no harm” to a site during the upgrade process. With this in mind the In-Place upgrade for version to version builds is now not available so everyone needs to start planning on how to upgrade using the trusted Database Attach methods. Other new and improved features that align with this design goal are site collection health checks that can be manually run or automatically run as part of a site collection upgrade and the concept of evaluation sites which we will dive into a little bit later.
An additional goal was trying to reduce the amount of downtime for a version to version upgrade, and this has been improved by separating the content database schema upgrade from the site upgrades. Now administrators have the ability to move users onto the new platform, but continuing to leave them in the old user experience version until the business is ready to make the change that ultimately disrupts the business more than it does IT.
The last goal was woven in with some previous items which is to grant more power to the users that are driving the tool. This goal ends up driving the majority of the changes into the upgrade cycle which revolve around site collection upgrades, conveniently enough is the next major topic.
Site Collection Upgrades
The entire concept around site collection upgrade is to be able to move the backend architecture to the new system version and let the user decide when to start utilizing the new features of SharePoint 2013. One thing that we heard is that even though the only software pre-requisite for moving your sites to SharePoint 2013 is being on SharePoint 2010 RTM it would be a good idea to be up to the April Cumulative Update which involves some additional schema changes which you will either need to deal with in your 2010 environment (pay now) or when you move to SharePoint 2013 they will also get put in place, but this will slow down your upgrade time (pay later).
Unlike the Visual Upgrade available from 2007 to 2010, the new UI mode enables you to have sites available in 2010 mode and 2013 on the same server instance running in full fidelity. SharePoint 2013 can do this because you will notice a full 14 hive and 15 hive directories deployed to your 2013 servers. An interesting new piece of functionality is called self-service site collection upgrade which informs the site collection administrator that a version to version upgrade is pending and allows them to choose to start the upgrade process. When they decide to start the process, that site collection is put in a queue, which is then picked up by a timer job and processed for upgrade. Later in the week during the deep dive session additional information will also come to light in how administrators can manage and throttle this process in the case of an overloaded system due to everyone wanting the new shiny features that SharePoint 2013 has to offer. When the self-service upgrade is processed the site collection health checks are forced into the process which can also stop an upgrade from being completed if there are upgrade blockers that the health checks determine that will not let it fully complete without breaking functionality. It is important to note that the health check rules are only automatically forced into the pipeline during a version to version upgrade (e.g. 2010 to 2013) and NOT during a build to build upgrade (e.g. RTM to SP1)
The last main section was around the ability to have evaluation site collections which puts a new perspective on performing User Acceptance Testing (UAT). These evaluation sites are a full exact copy of the existing site collection which can be initiated by the site collection administrator, but these sites have a predefined expiration date as they are NOT intended to be used as a stop gap before finalizing the upgrade with production changes. These evaluation sites should be used to test out how the new functionality will effect the existing sites and content, but NO production changes should be made in that environment that cannot be thrown away after the evaluation is completed. As an administrator the main thing I worry about with evaluation site collections is storage requirements since it is an exact copy but supposedly administrators can specify a max size that is available for these evaluation sites, hopefully more information on that as we continue through the week.
With all of the additional powers that site collection administrators are getting in SharePoint 2013, especially in regards to upgrade the good news is there are some default throttle levels for how many parallel upgrades can be processed at a given time based on content database or web application worker processes. If the past holds true, mostly the changes that happen down at the SQL layer and the I/O requirements for these changes will ultimately help you set YOUR throttle levels so plan accordingly.
Upgrading the Social Experience
With the new concept of site collection upgrades one thing to start thinking about is the social impacts for your existing My Site infrastructure. The first site that should get upgraded in your My Site web application is the My Site Host. To help with that, you have isolated that to its own database correct? This can help start forcing the issue as this site should always be the first one upgraded to the 2013 user experience level and then all personal sites will follow as individuals start hitting the upgraded My Site Host using the same queuing technique as the self-service upgrade method.
Upgrades with SQL Snapshots
One of the concepts that has been introduced during upgrade is that SharePoint has the ability to utilize SQL Snapshots if your SQL environment supports these features. Really, that’s a nice way of saying you can only use this feature if you are utilizing SQL Enterprise. There is a good reason for SQL Snapshots like the storage footprint is significantly smaller than a traditional upgrade where you need much more storage however Snapshots are not supported if you are using Mirroring, AlwaysOn or the RBS FileStream provider.
As highlighted through the site collection upgrade is the concept of the System Status bar which highlights information to users whenever the system may cause issues for the end users. This status bar is not that extensible but it does give you the ability to add further links for “More Information” which is a starting point to help drive people to your personalized information. Additionally during the site collection upgrade processes there are enhanced email notifications that can be configured at the web application level informing the site collection administrator of various milestones through the upgrade
Miscellaneous Upgrade Items
A nice catch all for items that didn’t belong anywhere else improvements to the Upgrade Log will help administrators troubleshoot the upgrade process using similar tools that we use today to decrypt the ULS logs. In addition because these upgrades are happening at the site collection level, each site collection will receive a new gallery which upgrade and maintenance logs can be placed so that site collection administrators can see these log files in the event of an issue without requiring any server level access.
Farm Upgrade Overview
The last section was fairly similar to the 2010 area which focuses on four pillars that you need to work through in order to process through a successful upgrade: Planning, Preparing, Executing and Finishing. At the end of the day, an upgrade is no small feat and planning your upgrade process will go a long way in making sure when the production cutover happens, you encounter no hidden surprises.