Friday, March 25, 2011

Moving Large MOSS 2007 Sites and Content


[Note : This post is part of  my main blog on “SharePoint 2010 Migration”]

What is Moving Large Sites?

  • If your Site Collection is over 200GB and hence the underplaying dedicated content database should be over 200GB exceeding the Microsoft recommended Max size for Content Database.
  • The Content and Site segregation effort is to move out such data to separate Site Collections and in to a separate content database or an existing smaller database if you prefer, there by reducing the over all size of your larger content database.
  • The your site collection could have several Lists and Libraries with over 1000 items and over 2000 items per list or library and they might be continuing to grow.
  • The site collection may also has several Document libraries that are over several GB in sizes and may or may not fall under the above said categories of over 100o items.
  • You will need to analyze to understand where things are growing.  I will cover the steps for this in the Analysis section below.
  • Hence your design for moving such content requires a very flexible approach to pick and choose each given list, library and may be an entire site (SPWeb) to be moved to given new site collection or an existing site collection.
  • I call this moving selective content to separate sites as “Segregation”.

Design Considerations

  • You want to ensure that the segregated content in the new site collection carries all content, date and time stamps, metadata, pages and applicable settings, security information.
  • You want to your segregation approach to be able to handle each given scenario such as move a site, move a list or library.

Available tools and options

MOSS 2007 has following two options when it comes to moving/copying content:

  • Content Migration APIs (PRIME): More granular support (Up to item level), full fidelity.
  • STSADM export/import operations: Uses the above API but less granular (Web Level Only), less fidelity.
  • Content Deployment UI interface via the Central Admin interface, does not apply here as it is meant for deploying to a target site.

Design Approach

  • Based on the need to support the individual items consider implementing a data file so that you can feed the data file to your process.
  • The configuration data file should mention a give list , library or a site as Source Object to be moved.
  • For each such Source Object, a Target should be mentioned.

    • The target can be a  new or an existing site collection,

    • For existing site collection, the location within the site collection as where to be moved.

    • For a new site collection , the name, URL, type of site template will need to be determined.

  • For entire segregation process a default set of parameters should be motioned such as minimum version to be migrated such as last 10 versions. And Only on demand this parameter should able to be overridden for any given Source Object to be migrated.

  • The segregation export and import should support entire set of metadata, version history, file status as is (if checked out if possible) , user permissions configuration.

The segregation should also support consistent, as-is migration of data from source to target.

Design Constraints and Decisions

Implementation Approach:


Site Collection Creation and re-parenting see me other blog.
Locking the Exporting Site Collection see my other blog.
Export and Import API call specifics see my other blog.
Drawbacks of current List Export and Import Content Migration APIs see my other blog.
Hot to programmatically copy Web Level, List level and List Item Level Security Information see my other blog.

No comments: