Part 2 - Migrating a SharePoint 2007 farm to SharePoint 2013

What Have We Got?

In the previous article, we discussed the methodology we used to get from SharePoint 2007 to SharePoint 2013, which was using a mirror.  The mirror became an exact copy of our SharePoint 2007 site, but in a SharePoint 2013 farm.  The content in the mirror was continuously updated so that once we were ready to go live, we backed up the DEV instance of SharePoint and restored it to our Production instance of SharePoint.  We also highlighted the fact that ShareGate was integral to our process and success.


Knowing the methodology was only the first step; before we could take any others, we needed to know what we actually had to migrate.

Taking Stock

A SharePoint farm with 60 sites also means a lot of lists and libraries.  We knew that it would take months to get the mirror ready; all the while, the site would still be in use - meaning the inventory was dynamic.  Lists could come and go, columns could be added to a library, views could change, and workflows could be added.  It quickly became evident that a spreadsheet was not the way to go for taking inventory and tracking progress.


Being a DBA, and being a huge fan of SQL Server Reporting Services (SSRS) and SQL Server Integration Services (SSIS), it seemed only logical that creating some tools for our own use using technology we were already familiar with would be a tremendous benefit.

PowerShell is Your Friend

With 60 sites worth of lists and libraries, we didn't want to manually gather and review all that information.  Though PowerShell support for SharePoint 2007 doesn't come close to what SharePoint 2013 offers, it's good enough to create scripts that extract all the information you need to create a site inventory - so we created scripts to give us the following for all of our site collections:

• Sites
• Site permissions
• Groups and group members
• Libraries and lists
• Library and list content types
• Library and list columns
• Library and list pages
• Library and list permissions
• Library and list event receivers
• Library and list workflows
• Library and list sizes

The scripts output their results to .csv files, which makes them very easy to process with an SSIS package.  We created a custom set of tables to store the data, and custom SSRS reports to get the data back out in a easy-to-use format.  We could use these reports to not only take stock of what we had, but we could use them in our meetings with Site Owners when discussing the migration as it relates to their site, and we could also use them for status reporting.  Having the information on-hand for our own status reporting allowed us to report actual metrics and progress, rather than estimations on how far along we thought we were.


Since we ran the PowerShell inventory scripts once a week, a key part of making this method of inventorying effective was the ability to know when things changed; if our site inventory determined a list changed after it was added to the mirror, we had to review our migration script to ensure the changes were properly captured.  Given the size of our farm, the small pool of users permitted to change list definitions, and the fact that our SharePoint 207 site architecture didn't change that frequently this was a fairly minor effort.

What to Inventory

Aside from the data we gathered via PowerShell, we also had to gather information related to the following:

• SSRS Reports
• Custom code (custom event receivers and webparts)
• InfoPath forms
• 3rd-party solutions
• SSIS packages

Each of these items had various considerations, and we had to ensure they were migrated properly.  For SSRS Reports and custom code, Team Foundation Server was invaluable with its code branching and merging capability.  This allowed us to maintain code branches for both SharePoint 2007 and 2013 during the migration process with little effort, which was all the more impressive when you consider the package structure is so completely different between SharePoint 2013 and SharePoint 2007 that our solutions for SharePoint 2013 had to be created from scratch. 


While ShareGate can migrate InfoPath forms, the forms themselves still require some attention - even if the SharePoint 2007 and 2013 library URL's are the same, InfoPath relies on list GUIDS - so an InfoPath form will not migrate directly without modification.  We read a lot of articles and postings related to InfoPath and SharePoint trying to answer the question "can I use InfoPath 2007 forms on SharePoint 2013?"  We tried for ourselves and learned the answer is "yes, but."  We were tied to the SharePoint 2007 forms client both before and after the migration (and were unable to migrate any of our forms to InfoPath Forms Services due to using digital signatures), and we learned that:

• When creating a data connection to a SharePoint 2013 list or library in a form that will open in InfoPath 2007 client, the connection must be modified in InfoPath 2007
• Editing anything other than a data connection in a form that will open in InfoPath 2007 client can be accomplished in InfoPath 2007 or InfoPath 2013

Though ShareGate is quite powerful, it doesn't operate at the farm level, so any 3rd-party solutions needed to be manually installed and configured.  SSIS packages, while not in SharePoint, connect to it; so all packages needed reviewed to ensure they would function properly post-migration.

Conclusion

Creating our own tools - PowerShell scripts, a SQL database, SSIS packages, and SSRS reports - comprised about a week of our total migration schedule, but the time and hassle ultimately saved was worth the effort.  It allowed us to get an excellent picture of our SharePoint 2007 inventory so we knew exactly what needed migrated and could track our progress.  As it turned out, having all this information in a database format made using our migration tools even easier than we could have imagined.  But that's a topic for the next article...

< Part 1 - How Do We Get There? | Part 3 - Using the Tools to Get There