Retro on SharePoint 2013

SharePoint 2013 burst onto the scene in late 2012 with several large upgrades over SharePoint 2010 (list a few). With this, our client made serveral large investments in teams to develop custom what we call (fix this) “Apps” to perfectly match their workflows in several complex scenarios. For example, how do you control access for a 3rd party that needs to access only a small part of of high security internal infrastructure without compromising that security of the experience of the 3rd party? A Second SharePoint Site! but this time it’s just a small mirror of the exsisting site with a different permissions provider and some new libraries (don’t forget about plain text passwords (link to cyber sec somehow)).

Analysing SharePoint 2016

When SharePoint 2016 came around, we still had not taken over the client yet, so again their previous team put in the work to migrate over to SharePoint 2016 from 2013. However after this migration was complete, the previous maintainers left and we were there to step in and pick up the pieces. Now there was a serious amount of custom solutions to understand and maintain from the get go. This provided a huge learning oppotunity to get our teeth into and get some hands on experience with what’s possibly one of the most complex SharePoint setup bar Microsoft’s own in-house build! (possibly not true).

The New World (2019)

As the deadline for SharePoint 2016’s EOL date approached (2023), the client expressed a security need to migrate once more to SharePoint 2019 (on prem), however this time with us (a new team with significantly less on site knowledge and resources). A challenge approaches! A system built in 2013 being dragged kicking and screaming into 2023/24.

Backup! Backup! Backup!

Step 1: Back up as much site data as possible hopefully we can bring as much of it over as smoothly as possible! (foreshadowning). There are several approaches to backups in 2016, web-level backups, site-level backups, farm-level backups and database-level backups. For our solution, since a lot of time had been put into creating a schema of databases for a collection of over 150 site collections we chose to backup at the database level. This led to al ong process of backing up several terrabytes of content databases, but once the process was over it would be much easier to complete the restoration on the other side.

Time For Shiny New Thing!

Step 2: Creating a new back-end, we need to setup a new instance of SharePoint 2019 that will be capable of recieving as much of the SharePoint 2016 data as possible.

Trouble Begins

Step 3: Migrating the service applications. Due to the age of the 2016 service applications and them being way out of patch date, it was neccassary to mostly create new service applications from scratch rather than trying to migrate over the old versions, there were 2 main downfalls to this approach: Search and Security.

Big Data

Step 4: Migrating Data. This part was relitivly smooth, other than the extremely large amount of it, the way that it had bee partitioned made it a breeze, we were able to copy over each ondtent database (handily labelled by the previous developers) and then re-attach the content database to the newly created site collection on the other side!

Step 5: Fix up! Now although migrating the data over was easy, ensuring it was presented in exactly the same way as in 2016 became an issue, although not much changed on the backend in sharepoint 2016, sharepoint 2019 did have a large unwanted front end overhaul, this then had to be disabled on all site colelctions site wide and there were several other small hitches that left the site needing a bit of tlc. One other major development was requirements around HTTPS

Conclusion

Finding information about old SharePoint 2013/2016 installations can be hard to come by as the internet ages and links go dead, leading for a need for developers to foster a good understanding of the basics before even attempting a project this old.