The Right Tool For The Job

When planning a data migration effort in SharePoint, you will undoubtedly be confronted by the classic build vs. buy decision.  Ultimately, your decision will be based on the changes to the data as it is moved from system to system.  For simple migrations where you are just switching from one provider to another (running the exact same software on both the old and new servers), a simple DB backup of the SharePoint Configuration and Content DBs should suffice.  However, when some type of data transformation is necessary, the decision becomes less clear.

The last project I worked on seemed straightforward enough - a migration from SharePoint 2007 at hosting provider A to SharePoint 2007 at hosting provider B.  However, a few requirements surfaced that made this trickier than a simple DB backup and restore.

The main complexity surfaced when the schema at the new facility was different from the schema at the source facility.  Why?  Because the custom application was modified and many of the fields that used to be used were no longer necessary.  My first inclination was to copy the entire  Content DB, and simply pare down the data to the desired schema.  However, seeing how the new environment was being setup as a completely "clean" environment, this was determined to be an unsatisfactory solution.

The next simplest mechanism for moving the desired data was to export the required lists to Excel spreadsheets, remove the unnecessary columns, and import them at the destination site.  Easy, right?  Not so fast - unfortunately, SharePoint will set the modification and creation information based on the import date, not the dates in the source data.  Since we were dealing with very sensitive data with strict auditing requirements, this was deemed unsatisfactory.

This left us with fewer options.  We could have just written code to copy directly from the source to the destination - but that's never as easy as it first appears.  Many unforeseen problems often arise that can take up days of programming time.  Ultimately, we made the decision to purchase an off the shelf tool to assist in the data migration - "The Metalogix Migration Manager."

Using this tool greatly simplified our data migration - however, it was not without its share of limitations.  Like any tool, it requires enough understanding of the platform in order to work well.  For example, we still needed to understand how the Content Types were mapped; how Workflows were being used and what data was associated with those workflows; how users were assigned to tasks and how to deal with mapping non-existent users in the new environment.

In the end, we ended up writing a fair amount of code to make the migration run smoothly.  One of my colleagues felt that we should have just written the entire data migration by hand.  I disagree.  I feel the investment in the tool was well worth the money and saved us from dealing with the bulk of the data transfer. Instead, it allowed us to focus on some of the more tricky/more interesting aspects of the move.

Using our custom code and the off the shelf tool in conjunction ultimately led to a successful migration.  Could we have done it all on our own and not used the tool?  Sure, but at a significantly higher cost.  Plus, the client ended up with a license for a tool that could be used for future migrations.

Bottom line - if you are doing any type of data migration in SharePoint, make sure you have someone that understands the platform and consider getting that person the tools they need to be successful.  Trying to save a bit on the tool cost will almost certainly cost you more in the long run.

What do you think?  Have you had a trying experience with a data migration?