Part 4 - Migrating a SharePoint 2007 farm to SharePoint 2013

Getting There

In Part 3, we showed how we created scripts for our data migration from SharePoint 2007 to a SharePoint 2013 mirror (our methodology explained in Part 1) using SharePoint 2007 inventory data (covered in Part 2).  In our final part, we'll discuss how that all came together; to the point where we could migrate 60 sites with 1.5 TB of data from SharePoint 2007 to SharePoint 2013 in just six hours.

Prepping the Production Farm

We already had a DEV farm which held our mirror.  The mirror was an exact copy of our SharePoint 2007 content in a SharePoint 2013 farm.  Since it needed to be maintained as an exact copy for our methodology it work, that meant it couldn't be used for developer testing or user acceptance testing (UAT).  The solution for that quandary turned out to be fairly easy - we set up our production farm, which we called PROD, in the production configuration we wanted to use when we went live.  That included creating the Web Applications, content databases, and services.  The Web Application was created to respond to the production hostnames (which, as we stated in Part 1, needed to the same as was being used in the SharePoint 2007 farm).  We then Extended the Web Application to respond to a second hostname, which we called TEST.  This achieved multiple things:

• Allowed us to create a TEST environment for users to manipulate data and break things while leaving the mirror pristine
• Allowed us to test Production equipment and configuration during UAT, since users were testing on what would be the Production environment
• Allowed us to test and validate our step-by-step migration procedure and scripting, since the steps would be exactly the same when updating the TEST instance or the PROD instance
• Eliminated discrepancies that could exist between UAT and production, since even identically configured environments can have subtle differences that could cause problems when migrating to PROD that didn't exist when migrating to TEST
• Allowed us to test the Production environment's response to production hostnames before going live by modifying the host file on the servers

By configuring our Production farm in this manner and using it as our Test environment, by the time the day came for migration, we had effectively already done the migration dozens of times - making the final migration (the one that mattered) go off without a hitch.

Putting the Mirror Into Production

Whether we were copying the mirror into our TEST environment, or actually conducting the final migration, the steps were exactly the same each time:

1. Run the mirror synchronization script
2. Import the script output files into our inventory database
3. Review script result reports to identify issues that may have occurred during mirror synchronization
4. Fix synchronization issues
5. Backup the mirror
6. Restore the mirror to the Production farm

Since we scripted most of these actions, and we practiced/executed this process so many times, we found the whole thing could actually be accomplished mostly hands-off in as little as 4 hours:

• 2 and half hours to synchronize the mirror
• 30 minutes to review and fix synchronization issues
• 1 hour to back-up the mirror and restore it to the Production farm

We only did one thing differently when putting the mirror into final Production - after running the mirror synchronization script, the SharePoint 2007 farm was placed into read-only mode.


Once we put the mirror into Production for the final time, only a few steps remained:

• Remove the TEST host header from the Web Application
• Change DNS entries for the hostnames
• Change host files in the old SharePoint 2007 farm, allowing us to still access SharePoint 2007 using the same URL as long as we were on one of the old servers

Conclusion

From a user perspective, they went home on a Friday using SharePoint 2007 and came in on Monday using SharePoint 2013, and it was business as usual.


We couldn't have asked for or envisioned a better outcome, but that's exactly what happened.  Sure, there were issues here and there (what migration goes off with zero hitches?) - but nearly all the issues that were brought up were anticipated, and most were fixed very quickly.


We had gone from not even knowing how we could do a migration from SharePoint 2007 to SharePoint 2013 to successfully doing the migration so often to TEST we could do it in our sleep - or from another perspective - scared out of our minds to confident and optimistic. 


Being organized and methodical, taking and keeping inventory in a database, and using the right tools (ShareGate and PowerShell) all contributed to our success.  Those of you reading this who have done migrations before may have noted I've left a lot of things out when I talk about how we did all this - and you are right.  There were many other factors and things we did that were key to our success, but they are the same ones that apply to any migration - engaged project sponsorship, frequent engagement of site owners, requirements gathering, documentation, training, and testing - just to name a few.  We wanted to highlight the way we handled the technical issues of migrating a huge amount of content from SharePoint 2007 to SharePoint 2013.  Hopefully we've done that - and if one day this story helps someone else complete a successful SharePoint migration - even better.

< Part 3 - Using the Tools to Get There