Migration Ugliness – SharePoint 2010 Content Migration Limitations

One of the biggest challenges you’ll face as a SharePoint administrator is moving content around.  If you followed the head to head migration stand off that happened today you’d have seen users wanted to see their workflows migrate.  Initially I was thinking.  I really want to see a single list of the out of the box limitations with the API and with the built in migration methods in SharePoint 2007 and 2010. (You’d be amazed how little changed in this area. Guess we didn’t yell loud enough.)

There are a lot of reasons why you’d migrate, but preserving your content is the key.  The reason SharePoint migration tools are popular is because of limitations in the Content Migration API (formerly known as PRIME API), Import/Export in STSADM and Import/Export in Powershell.  PowerShell Export-SPWeb and Import-SPWeb you can migrate sites, site collections, lists and document libraries between entirely different SharePoint 2010 farms. (If this post is too deep and your just looking for basic commands to do the migration look at SharePoint Monitors overview of the commands and powershell command.

The closest to full fidelity is first stsadm backup/restore then database attach.  Even database attach will loose the settings that are in the config database, so be careful when you hear full fidelity migration from anyone.

I’ve found it extremely difficult to find a single clear list of what limitations are in the box and what I should be looking for in a SharePoint Migration tool.  Special kudos to conversations on twitter with @glapointe @toddklindt and information from migration expert Alex Kirillov @alexkirillov from Quest Software (PM of Quest’s Migration Manager) and added to this list based on my own experience, what I’ve found on blogs and MSDN/TechNet and would love to see the limitations all in one place.  Ultimately it would be great to have a single list and ultimately get this fixed… especially as people are restructuring their data and both getting ready to upgrade, during migration, and post migration cleanup and further restructuring.

What Doesn’t Migrate with SharePoint Built in Import/Export and other known issues:

• Item created by, created date, last modified date
• Workflows (Definitions)
• Workflow State & Tasks
• Workflow History
• Check in/check out state
• Audit logs
• Usage Logs that have not been processed
• List configuration/app configuration
• Site collection settings (Site Collection Ownership, Quota, email notification settings and a lot more)
• Personalized views
• Alerts
• Recycle bin state/items including admin and user Recycle bin items
• Lookup lists have issues due to remapping of object GUIDs
• Object GUIDS are not preserved (This causes all sorts of weird things and can cause issues down the road. Empty folders may not migrate)  This includes using import/export in STSADM or Windows Powershell, SOAP or Web services as well both result in loss of object id consistency including reparenting. The only way to avoid this is using the Content Migration object model.
• Empty objects may not migrate (Discussion lists may have some problems related to this, and some folder structures may be remapped.)
• Users that no longer exist are removed during import/export (related to ownership being re-written)
• Surveys that are not completed will not be exported
• Global Navigation inheritance issues (parenting challenges)
• Known issues with conflicts when used with content deployment
• No migration of features, solutions or assemblies associated with site/web (Must be manually migrated if separate farm and exist on destination)
• Content overwritten if exists
• Site dependencies on Site Collection Gallery lists (example if you migrate a web the parent site collection may have galleries that the web uses i.e. galleries include some look and feel, masterpages, images, features, and webparts.) known to have issues (Need more detail)
• No list level migration (granularity is site level in 2007; Windows Powershell SharePoint Cmdlet in 2010 gives you list level) Thanks @toddklindt
• Scale limitations (reliability goes down the larger the site <25GB Note: if you add the "no compression" parameter it increases the likelihood that large exports will work. Best case is dedicated databases as database migration is higher fidelity)
• Portal Template Global Nav known to have issues (Need detail. Problem appears to be associated with site collection property loss)
• Security remapping AD group challenges for groups between 2 untrusted forests
• Versions of aspx pages (Need more detail)
• Can’t change site template during migration
• Can’t consolidate sites during migration
• No good list of what fails to import
• blocked file types
• files over max file size
• Objects that don’t contain objects may not be migrated (See comments in Gary LaPointe’s Export lists blog)
• Post migration sync (No way to migrate again. If template already chosen or not blank)
• No support between farms of different builds and versions. Have to be exact same version number (This may be different in 2010).
• No ability to target a specific content without manual intervention (limiting all others or setting capacity high)

This list is in progress.  Feel free to ping me on twitter to update or add things on this list.  I’ve added text such as “need more detail” where I don’t know the exact issue and could use clarification.

Question any vendor tool that says they do full fidelity migrations since much of this list is not available in the Content Migration API.  How are they doing? That’s the follow up question.  You do have the ability to retain the GUIDs the Object IDs and as a developer using the content migration API you have the ability to target migrations at the list level.  What about SharePoint Designer?  It uses the same API and has all the limitations above plus it’s own scale limitations for size of CMP files. Some of the known issues around SPD scale are listed won’t fix.

Both WSS and MOSS in 2007 and as well in 2010 you’ll see a lot of use of this API at various different places:

• Content Deployment
• STSADM -o export and import
• Copy/Move operations in Site Manager
• Variations
• Windows Powershell cmdlet import/export
• Unattached recovery uses a form of the migration API in SharePoint 2010

What’s fixed with content migration in 2010?

Well, the unattached recovery gives us a new API for interacting with a database that’s not apart of the farm, but ultimately I’ve found a lot of the same issues.  Try to recover a site and a workflow for example.  You do get more granularity in recovery if you can find what was lost.  Powershell export can give you more granularity, but the data faces a lot of the same issues.

Excellent Resources and Blogs on different aspects of Import/Export Content Migration and Content Deployment

Gary LaPointe

Automation Blog post on Import Export Copy & Delete Lists with some of his fabulous powershell cmdlets

Chris O’Brien UK SharePoint MVP

STSADM Import & Export and Content Deployment

SharePoint Designer

SharePoint Designer and STSADM Import Export

Stefan Gossner from Content Management Team at Microsoft

Data protection and recovery for Office SharePoint Server (White paper)

Deep dive into the SharePoint Deployment and Migration API (Multi-Part!)

 

Here’s some info from MSDN on the Content Migration API detail on SharePoint 2010 (but also applies to 2007):

What the Content Migration APIs Are Not

“The content migration APIs are designed to move content from a source location to a specific destination; these APIs are not designed for backup and restore purposes. Following are some of the limitations of the content migration APIs with respect to backing up and restoring data.

• No configuration or application data can be exported or imported.

• The largest object you can export is a SharePoint Foundation site (SPWeb object).

• The following content cannot be exported or imported: alerts, audit trail, change log history, check in/check out state, recycle bin items, recycle bin state, security state, workflow tasks, and workflow state.”