I recently completed a 10-month project for a healthcare organisation in the US to migrate content from SharePoint 2010 and 2013 to SharePoint 2016 (and SharePoint Online). The end result was a success, but with a few caveats, which I’ll discuss throughout this blog.
Our client, an international health care organisation, was looking to divest one of their practices. This divestiture required that the new business setup their IT department from scratch (as the parent company wasn’t providing any staff for IT purposes).
Amongst the best decisions that was made by the new company was to have all their IT live “in the cloud”, and to have no on premise IT. Eventually it was decided that Azure would be the cloud of choice for this, which meant all the “on premise” SharePoint farms would live in Azure.
rhipe’s recommended approach in this situation was to script the deployment of SharePoint farms into Azure. This way we could control the building of the VMs, as well as the building of the SharePoint farms thereafter. rhipe worked together with the Azure team to develop scripts that would build our development farm servers for both SharePoint 2010 and 2016.
The original theory (before rhipe joined the project) was that the organisation would simply require farms for SharePoint 2010 and 2016, and any content that originated in SP2013 would simply be imported into 2016 directly. Although this would work in theory, several flaws were identified: there were several custom solutions (branding, workflows, etc.) that wouldn’t port directly into SharePoint 2016. Additionally, the parent company’s custom solutions would then be baked into the new organisation’s Production SharePoint farms (likely forever, or at least until someone spent a lot of time and money in the future to create new SharePoint farms which would eliminate these).
In response to this, rhipe proposed an alternative approach which involved creating staging farms for both SharePoint 2010 and SharePoint 2013. The content from the parent company would then be imported directly into these staging farms, and migrated out using a migration tool (into the platforms we desired). Once this proposal was accepted we selected Metalogix Content Matrix as the tool of choice for our content migration.
Our team then proceeded to build the staging farms (reusing the scripts we had previously developed), and as a test content was being provided by the parent company. We would load this content into the staging farms, and use Content Matrix to perform test migrations into the development (target) farms.
A few other notable items were that we obviously had to get all the 3rd party components installed into the various farms. One of the solutions that was used by the parent company was Nintex Workflow. Although this was a good thing, it came with some challenges of its own. Without a full account of the organisations content we had to make a guesstimate as to the number of total workflows. We were able to succesfully navigate this challenge by collaborating with the organisation and Nintex.
Additionally, a request was made to migrate all custom solution sites from SharePoint 2010 to SharePoint 2016 – ultimately this proved to be challenging as we couldn’t identify anyone with the necessary skills to perform the work. Fortunately we came across an adjacent team of individuals with the necessary skill sets, and by collaborating with the client we were able to utilise their talents to help achieve this goal.
When it finally came time to build the production farms, we took a new approach to the build out of the farms in Azure. Utilising rhipe’s existing Azure capabilities we built the new farms in a much more structured fashion. Thus, our production builds were far more elegant than our development and staging builds were!
After performing some test migrations into the production farms, we were ready to set a date for the final migration of the SharePoint data from the parent company. Utilising rhipe’s global resource capacity for the migration window, we requested that everyone was on-site, or available during this window ensuring that we could all work together effectively.
As the production data was provided to us, the first task was to get that content from a physical hard disk into Azure. Once the data was in Azure, we successfully loaded it into the staging farms and began the data cleansing process. There were a few scripted steps we needed to perform in order to ensure the data would be useable on the target systems.
The next phase involved migrating the content using Content Matrix from Azure into both our production SharePoint 2016 farm, as well as SharePoint Online. Much of the content ended up being migrated into SharePoint Online, as it was purely documents and/or webpages, and it would fit well with the SharePoint Online model. The content that was kept on premise contained custom workflows, custom applications, and personally identifiable information (PII).
The SharePoint 2016 production farm had all the custom solutions pre-loaded, so it was ready and able to accept the new site collections as soon as they were could be migrated. The sites with PII and Nintex workflows were migrated using Content Matrix, and these sites moved easily and successfully into production.
The custom solution migration approach followed a different path. For these sites (five in total), we performed a database attach migration, exporting content from SharePoint 2010 into SharePoint 2013 (performing the content upgrade and visual upgrade), and then again exporting from 2013 into SharePoint 2016 (once again performing the content upgrade along the way).
Overall, both approaches were highly successful at migrating the content from the source staging farms into the target production farms. There were a few minor issues with custom solution sites at the end as not all the functions were working 100% as expected, but these were resolved in a reasonable timeframe, and the client was overjoyed with the success of the project as a whole. rhipe were able to deliver; on time, on budget, and provided our client with the full functionality they desired!
By Colin Phillips, Principal Consultant, rhipe Solutions