For SharePoint 2013, there is a lot of great stuff coming for performing upgrades. I may have mentioned this recently on my blog but a lot of this optimization in upgrading SharePoint. Much of this is driven by experience from the five major releases of the SharePoint however SharePoint Online is proving to be a strong catalyst for improvement. When SharePoint 2010 was released we saw how the architecture of SharePoint completely changed, and much of that change is associated to a long-term Microsoft vision to deliver SharePoint through the cloud. Whether you are implementing on-premise or purchase SharePoint Online, you will be able to benefit.
I know many folks have done upgrades in past versions of 2003, 2007 and 2010 and have dealt with a lot of work to get through those. There are a mixed bag of reasons of why upgrades were complex. When I was consulting I would also remind customers to design and implement for the future. Every large SharePoint customization should have a path for the future. There is really too much to go into here and not the topic of this posting….
In this blog I am going to discuss some of the big improvements that you should know right off the bat in regards to performing SharePoint 2013 upgrades. Second I am going to discuss how these new upgrade changes apply to SharePoint Online.
The following are some of my notes I have captured from multiple events and presentations.
New Facts About Upgrades for SharePoint 2013
The following are some of the big facts that you should know about SharePoint 2013 Upgrades:
- Upgrade Approach – The only approach available for SharePoint 2013 upgrades is DB Attach. There is no more In-Place Upgrade (2003, 2007 and 2010) or Gradual Upgrade (2003).
- Upgrade Versions – It is pretty much the same, you will need to be on the previous version to perform an upgrade; which will require you to be on SharePoint 2010. There are numerous third-party solutions available in the marketplace that can assist you to upgrade from older versions of SharePoint to SharePoint 2013.
- Requires New Server Instances – Given the fact that you must do DB Attach, you will have to create SharePoint 2013 servers. You cannot upgrade your existing SharePoint 2010 servers.
- Important >> Site Collections – Upgrading is now focused at the site collection level. Databases will be attached into the new SharePoint 2013 farm however the actual upgrade itself will be done at the site collection, when the site collection is ready. This is a really important point; “when the site collection is ready”. This means SharePoint 2010 site collections will run in full SharePoint 2010 experience on a SharePoint 2013 server until such time it is decided that it will be upgraded.
- Improvement >> More Well Known – There is a new capability for performing an upgrade health check before actually moving forward with an upgrade. The goal is to provide a capability that will tell organizations that an upgrade will fail prior to it actually failing. A health check report will provide detailed warnings and information on issues to remediate. This is extensible and can build own custom rules. These rules that can detect and custom repair operations can be created for specialized scenarios you may need to support.
- Improvement >> Evaluation Site – This is an exciting capability. There is a new capability that will provide you the ability to spin up a new site collection to preview an upgrade of a site collection before it is actually done. This is a great capability to test and remediate issues before you actually perform an upgrade. This is basically a replacement of the visual upgrade process that was provided in SharePoint 2010 (in my opinion a better solution). These evaluations site collections cannot made be permanent nor is it recommended for long-term usage. There is configuration available to administrators to control the maximum size for an evaluation site (for instance when an administrator did not put on site quotas and you have TBs of data sitting in a single site collection). There is PowerShell available to automate the creation of evaluation site collections (which can come in real handy if you need to do some automation around testing large amounts of site collections). As well an expiration date can be applied to the evaluation site collection to ensure that these sites are not accidently used for too long.
- Improvement >> Quicker Upgrades – With the focus of moving to Site Collection upgrades versus an entire content database upgrade, significant amounts of time is saved when actually performing an upgrade. This is because you upgrade the farm but all the site collections (which require all processing) can be spread out. This reduces having to do big bang upgrades.
- Improvement >> Communications – New features have been implemented that will communicate to users via email during an upgrade. There are events and different email templates you can work with to communicate the status of an upgrade. Additionally a system status bar will also be displayed that an upgrade is being performed. Administrators have the ability to customize the messages displayed to the user to give customized instructions and information.
- Easy User Transition – As I mentioned earlier, upgrades are done at the site collection level and the SharePoint 2010 experience will remain until in effect the site collection is upgraded. This means you can start delivering new SharePoint 2013 solutions in other site collections while continue to run SharePoint 2010 solutions until you have created a proper transition path for the end users. Additionally, this is great for user transition as it will allow end users get user to SharePoint 2013. Organizations have the ability to strategically identify site collections for upgrade to SharePoint 2013 and then select which ones that should go first.
- Initiating an Upgrade – Upgrades of site collections can be automated through PowerShell, administrators can manually execute them or they can be delegated to site collection admins (which may be a person within the business). Remember there are still controls available to control how site collection admins can do it (max sizes, specific site collection blocks, etc.).
- Queuing Site Collections – There is a new capability to throttle the number of parallel upgrades. This can become important if you need to coordinate the upgrade of a lot of production site collections. Specifically you do not want to overload your SQL Servers databases. The Web Application processes will wait for processing capacity and database space before executing. Time jobs are responsible for assisting with this. Large, oversized site collections will not be done through the Web Application; it would be done through a timer job. The queue can be managed if you need. Note that each queue is assigned at the content database level. Even if there is a failure (for whatever reason) the upgrade will be re-initiated in the queue. Finally PowerShell is available to place site collections in the queue or even change the throttle.
- Logging Improvements – Additionally there have been many new improvements for logging. ULS Logs can easily be pulled into Excel, correlations IDs, more error codes and more details are now provided when an error may occur.
Beyond new upgrade capabilities your process for performing an upgrade will change a little bit given these changes. Here are some things to keep in mind.
- Review the Upgrade charts located here - http://msdn.microsoft.com/en-us/subscriptions/cc263199.aspx. There are two specific diagrams a workflow for performing an actual upgrade and another for testing.
- Do not skip doing due diligence. Please audit yourself, know what you have deployed and determine what the best path is to ensure continuity of operations.
- As discussed above, you will need to build out your SharePoint 2013 farms prior to performing the upgrade. It is also good practice to leave those SharePoint 2010 farms as long as you can until you feel the production migration is complete.
- Additionally if you are using federated service farms (ie you have a SharePoint 2010 services that provides common services to other SharePoint farms), you MUST upgrade those farms first. Do not worry, an upgraded federated service farm on SharePoint 2013 can communicate with a SharePoint 2010 content farm. However it does not work in the reverse order.
- Similar to the prior note, even if you do not have a federated service farm, you should upgrade your services first, then bring over content databases and then gradually upgrade sites collections to SharePoint 2013.
- Do not forget, if you have a ton of customization and third-party tools, you will need to work through the process of moving them to the SharePoint 2013 farm.
As you have been reading, you may have noticed a lot of new features that are focused on supporting large SharePoint environments. One would be Office 365 and upgrading SharePoint Online customers. Knowing that:
- Previously I talked about upgrading federated service farms first and then upgrading the content farms. Well this is exactly what is going to happen with SharePoint Online. The common federated service farms will be upgraded first by building new service farms on SharePoint 2013 and connecting them to SharePoint 2010 content farms. The new SharePoint 2013 content farms will be created and then the content databases will be moved over.
- Next customers in SharePoint Online will determine when they want to upgrade the Site Collections to use SharePoint 2013. New PowerShell commands are available for SharePoint Online to automate this activity. Both the new Health Check Report and Evaluation Site Collection features are available.
- Note that with SharePoint Online customers will be required to eventually upgrade all Site Collections to SharePoint 2013 user experience. Even on-premise customers should do this as the goal is not to allow SharePoint 2010 solutions to run forever. This capability is really intended to provide support for transition.
As I mentioned, moving forward it is always good to understand how you are building custom solutions. I know a lot of people are doing this SharePoint. I really believe that you can build a lot of solutions with out of the box features and capabilities. I recommend that if you are building highly customized solution, to investigate building solutions with the new SharePoint Apps model.