Well it's been almost 6 months since my last post, and while there were many things I would have liked to share, my workload simply hasn't allowed the time.
Where has the time gone
If your reading this post, then I guess it's safe to assume you are interested in what's been keeping me so busy. While some of it can be attributed to changes in personal circumstances, the largest contributor has been the migration of our custom learning platform from SharePoint 2010 to SharePoint 2016. If you're new here, or simply haven't seen me discuss it before, here's a little overview of our platform, to give you a sense of our scale/usage:
- We have over 1 Million subscribers
- We have users spread all over the globe
- We have over 1 million lines of custom code spread over more than 100 projects
- Our platform, like most these days, runs 24/7/365
- Our SharePoint content databases contain ~1.5TB of Data
From discussions with Microsoft, I know we have quite a large and complex environment compared to most on-premise SharePoint customers.
The joys of early access
How have you spent so long on 2016 when it's not been released yet?
I hear you ask. Well, I was one of the lucky people who were granted early access to 2016 for testing purposes. So at this point, I've been using 2016 for just short of a year. While I can't go into any details about that (NDA's yay) Now that it has reached RTM, I can finally start to share some of the things I've learnt about 2016 during that time.
Things to consider
For this first post, I'm going to give some high level considerations for you to think about, without going into to much detail. The details will follow in further posts.
The big pain point with a 2010-2016 migration, is that currently, it is not directly supported. While it should be possible for most people, be aware if you do come across any strange Database migration issues etc, you may not be able to get any help from Microsoft.
Having said that, as I am about to cover, it is certainly possible.
As mentioned above, there is no direct upgrade path from 2010 to 2016. So if you want to upgrade you must pass all relevant databases through SharePoint 2013 before you can upgrade them to 2016.
While this by no means requires a full farm to be configured (a single server farm will do) you must ensure that all custom farm solutions are installed and configured correctly, whilst having been deployed with the Compatibility level set to All.
Custom Code and Deprecated Features
While SharePoint 2013 supported running 2010 farm solutions with little to no changes, It is not possible to run SharePoint 2010 solutions in 2016. So any custom farm solutions you have must be upgraded to 2016. While we found this to be a fairly painless process for 99% of our code base, there were some issues around deprecated features.
The biggest one for us, was the changes made to site templates and themes. While these changes already existed in SharePoint 2013, the older SPWeb.ApplyTheme() method still worked. In 2016 it does not, so all of our code had to be re-factored to account for this.
Before you undertake a SharePoint 2010-2016 upgrade project, I would highly recommend you investigate any farm solutions you may have, to ensure that you aren't using any features which have been removed.
Another thing to consider, and a big pain point for us, was the actual practicality of doing the migration due to the size of our dataset, and the fact that all the databases must be passed through SharePoint 2013 which cannot be installed on the same server. You will be amazed how much longer the migration takes. Having to pass the data through 2013 resulted in 2 extra transfers over the network that would not be required in a 2013-2016 upgrade. the databases must have schema upgrades, and then all site collections upgraded while attached to the 2013 environment. For us, this step alone took almost 36 hours to complete, so just something to keep in mind.
If you have done any custom Styling/Branding in your 2010 sites, be aware that it will all be horribly broken. The SharePoint style sheets haven't changed much between 2013 and 2016, but if you are coming from 2010 be prepared for a complete mess. This was the single biggest issue we faced during our migration, and took the longest of any issues to resolve.
Up Next - UPDATE
I had originally planned to do a series of posts regarding this process, unfortunately due to leaving that job, I no longer have access to my notes from the upgrade process, thus making it rather difficult to produce an accurate account of the procedure.
While this is a nice short intro post, listing some of the main pain points you may encounter. In the next post I will go into more detail as to why you would want to upgrade to 2016 in the first place [a little hint, cause it's the best version yet]
If you have any questions about 2016 you would like addressing directly, let me know in the comments.