Migrating SharePoint 2007 to SharePoint 2010 from Max Herve

Part 2 of 2 - Migrating SharePoint 2007 to SharePoint 2010

This is the second of two posts regarding migration and I will focus here on some information about migrating content from SharePoint 2007 to SharePoint 2010.
There are four different options that can be used in order to bring content from SharePoint 2007 over to SharePoint 2010:

1. In Place -> Upgrade
2. Database Attach -> Upgrade
3. Third Party Tool -> Migration
4. Custom Code -> Migration

I like to classify these four methods into two categories: Upgrade and Migration. An Upgrade really is updating the software to a newer version. Option 1, the in-place upgrade, will get you SharePoint 2010 using your existing servers (possible only if SharePoint Servers hardware is x64 ready) while option 2, the database attach upgrade, will allow you to move your content to a new database host for example.

While these methods are widely used and “Out Of the Box”, I like to recommend to clients option 3, the Third Party Tool option, when there is a need to “migrate” content. In my opinion, a migration should be able to consolidate your Information Architecture, determine which content needs to come over, easily migrate content in different waves, migrate content incrementally and especially transform your content at migration time by applying content types to your documents, binding columns to Managed Metadata columns (MMS) and/or External Data columns (BCS).

A tool I have used for several migrations over the past using option 3 is Metalogix SharePoint Migration Manager (SSMM). The information below has been gathered from the Metalogix website. These guidelines can give you a good understanding of how the tool works and how to improve migration performance.

Typically, SSMM (v < 5) can migrate 1-4 GB of data per hour. SSMM only writes to SharePoint through the public API and web services, so the performance of your migration will be primarily dependent on the performance of your SharePoint servers.

Other Points to Consider:

• Installing the Migration Manager client on the Web Front End server may improve the performance of your migration. This reduces the data moving across the network to the client. Note that if you are using a load balanced environment, you should refer to Metalogix’s documentation about how this can affect the Metalogix SharePoint Extensions service.
• Running multiple clients can also improve performance. However, if you are running multiple Migration Manager clients against the same source and/or target server, you should ensure that they are accessing different parts of SharePoint. For example, writing to the same SharePoint list with two Migration Manager Clients will cause errors. See also my prior blog post (part 1) about licensing considerations of using multiple clients.
• Only use the "Preserve Document IDs" option to copy document libraries if SharePoint lookup lists are referencing the documents. This setting will have a negative impact on performance, so it should only be used when necessary.
• Creating objects through the SharePoint API will account for most of the time it takes to perform a migration. For this reason, complicated site structures (even if they are empty) will take longer to copy than a simple site structure that potentially contains more data and/or documents. In other words, it is possible that creating dozens of sites on the target server will take longer than migrating a single document library that contains a large number of documents.
• Migrating Workflows (WFs):
  
  • Out of the Box WFs: Features will be reactivated on target at migration time.
  • SharePoint Designer WFs: These workflows can be migrated only if the migration is performed at the site or site collection level. One way of accomplishing this scenario is to migrate the whole site (enabling the workflow checkbox in the migration options) and then remove or merge SharePoint libraries once the content has been moved on target.
  • Custom WFs: I did not get a chance to migrate custom WFs using the tool. I would recommend redeploying the wsp file in the new farm first and then migrating content over.

I hope this two-part post sharing some migration advice I have learned “the hard way” is useful to you. Please share your thoughts and feedback in the comments below. Happy migrating!