Durga Apoorv Durga

Follow Apoorv on Twitter @apoorv

Treating Content Migration Like a Real Project

13-May-2010

Tags: Document Management (ECM), SharePoint Ecosystem, Web Content Management, Implementation

I was reading the excellent Web Site Migration Handbook by our good friend and colleague David Hobbs -- and a quick Twitter exchange with him got me thinking about the importance of testing and QA in migration.

Most organizations do not undertake a migration effort with the rigor and discipline that they normally would for a software project. The result is often a failed migration. You should treat a content migration project like any other major software project in terms of execution. What this means is that you should deploy a proper methodology for implementing migrations.

A typical software development methodology has the following phases at a high level:

  • Analysis
  • Design
  • Implementation
  • Testing
  • Deployment

The following table maps the activities that you carry out in a software development phase with the activities that should be carried out for a migration project. Remember though that depending on your chosen methodology, there may often be some overlap of activities between different project phases. As an example, a prototype or a PoC will usually start in the Design phase but will continue even in the implementation phase. Also, the table does not map all the possible activities but only high level ones in an attempt to map them with a formal SDLC.

 Activities in Software Development   Activities in Migration 
Requirement Analysis

Functional Specifications
  • Conduct Site/Content Inventory
    • Identify content types
    • Identify content that will not be migrated
    • Identify content parameters like type, owner, size, last modified, name, location, audience, importance and so forth
  • Analysis of the above
    • Frequency and complexity
    • Relationships
    • “Common-ness” between different content items
    • Taxonomy and Metadata assessment
Architecture Design

High Level Design

Low Level Design
  • Map content from source to destination
  • Map metadata from source to destination
  • Map users and roles
  • Identify gaps and strategies for them
  • Decide how much of manual and how much of automated migration can be done
  • Decide big bang Vs Incremental migration
  • Prototype or Proof-of-Concept
  • Design of import and export scripts
  • Test and QA plans
Implementation

Coding

Unit Testing
  • Development of migration scripts and utilities
  • Unit Testing of these scripts and utilities
  • The actual migration (both automated and manual)
  • Post extraction refinement
System Testing

Integration Testing

Regression Testing

User Acceptance Testing
  • Test and QA different migration scenarios:
    • default values getting populated properly
    • data type mapping between source and destination
    • user and roles mapping
  • Performance testing of scripts
  • User Acceptance Testing
    • Content Quality
Deployment
  • System roll over
  • System roll out
  • Post migration refinements


Depending on whether you use Waterfall, Iterative, RUP, Agile or some other methodology, there will be variations in the way you carry out some of the migration activities. However, the point is that you should treat content migration just like you would treat any other project and give it the respect it deserves.

    Excerpt from the SharePoint 2010 WCM Evaluation

    Web Content Management Report looks at... Publishing and Deployment Services in SharePoint 2010

    "In SharePoint, publishing strictly works one way; you cannot do reverse publishing from target to source. This is okay for traditional publishing, but this may become a problem if your site has user-generated content that must be published back to the staging environment..."
    (p. 474)

    CMS Vendor Evaluations

    Learn the real strengths and weaknesses of major CMS vendors from around the world, in our Web Content Management research stream.