Using the Tools to Get There
We've discussed the methodology we used to migrate from SharePoint 2007 to SharePoint 2013 (using a mirror), and how we took stock of what we had to migrated (using various tools), so we'll move on to how we actually built our mirror.Setting Up The Mirror
The first SharePoint 2013 farm we stood up as part of our migration process was called DEV. It was not very robust, and our intent was to use the DEV farm for development after our migration to SharePoint 2013 was complete. In the meantime, its primary function was to house our mirror - an exact replica of our SharePoint 2007 content, but housed in SharePoint 2013. Many services weren't even configured in this farm - just a few that we wanted to test or validate - such as Search and SQL Server Reporting Services (SSRS). We setup the Web Applications such that our current URL structure would be maintained between SharePoint 2007 and SharePoint 2013, but with a different host name. We also setup the database files just like we wanted them to be in our final product, since the actual migration would be accomplished with a database backup and restore between our two SharePoint 2013 instances (DEV and PROD).Filling the Mirror
Creating the mirror was the easy part - filling the mirror with content is what consumed 80% of our schedule. Recall from Part 1 that one of our success criteria was to make improvements where we could - this meant that each library and list was reviewed to see what, if any improvements could be made. One of the biggest areas of improvements we wanted to focus on was Search - we wanted our Search to be more usable - which meant trying to create improved content types and site columns for better search results. Ultimately, we came up with a procedure that was repeated for each site:- Create the site using SharePoint 2013
- Enable/disable required site features
- Migrate all site pages, lists and libraries (including workflows and public views) without content using ShareGate
- Cleanup/adjust permissions from what was migrated (part of our 'making improvements where we could' effort)
- Make desired improvements to content types, lists, or libraries
- Create the script for content in each list and library using ShareGate PowerShell
- Validate and test the site migration script
- Add the site script to the farm script
Scripting For the Mirror
Even with ShareGate and PowerShell at our disposal, the prospect of creating scripts for hundreds of lists and libraries was daunting. In Part 1 I mentioned that the migration wasn't all that bad if one is organized and methodical, and in Part 2 I mentioned that having our SharePoint 2007 inventory in a database format made using our tools easier than we could have imagined - and here is where those two things come together.An example of the ShareGate script to migrate a single list looks like this:
For the most part, the script structure doesn't change from list to list. Most of the string values in the script were stored in the database we used for inventory. This meant we could create a function that built the script for us, with only a small part of the script itself being variable. We added a column to our inventory tables that contained the part of the script that would vary from list to list, which is lines 27 - 37:
This section of the script block controls, for a particular list: how the version history is handled; how duplicate records are handled (skip, overwrite, or incremental update); and how content, column, and user mappings are handled.
This gave us the capability to build a migration script for an entire site using a single function that output the script to a single file. By building a farm-level script, we could update the mirror with a single script that called all the site-level scripts.
No comments:
Post a Comment