Migration Process -- Analyze ContentThis step analyzes content that will be present in the to-be V7 system as well as existing V6 content. Content analysis defines content migration scope at detailed level. It tries to identify what content in V6 need to be migrated and how it will get migrated. This step also involves finding feasibility of content for automated migration versus manual migration. Output of Content Analysis: # List of V7 system content instances that can be migrated from V6 system. # List of V7 Content Types that can be mapped to V6 content and hence migrated through an automated process. # List of V7 Content Types that need to be migrated through manual process. Content analysis is a 2 step process. # Process to identify content for migration # Process to find feasibility of content for migration Process to identify content for migration This step identifies all the content pages on the site that require migration from V6 to V7. Content in an organization, that is going to be available in the new V7 system can be categorized as: # New Content Type in V7 – Content Types that are newly defined in the V7 system and were absent in the V6 system. Ex. New site decided to put news items on the site and decided to use new Content Type for the same. # Modified Content from V6 – Content present in V6 is going to be modified or content formatting is changed. # Same as V6 – Same V6 content need to be present in the new V7 system. # Always New – Content is dynamic in nature and getting updated quite frequently on the site. This category is further subdivided as: a. Old Data Required – Though content is getting replaced with new data, old data is required to be maintained for some time for site analysis or content search purpose. b. Old Data Not Required – Old data is not required to be maintained for site analysis or content search purpose. Out of the above 4 categories, first category does not need migration as content is newly defined (not present in old V6). Last three categories need to be analyzed in further detail to see how their content can be migrated. Note that, content of type ‘Always New’ need to be migrated based on its frequency of updating and also if content is required in the new system as it is part of the site analysis or search criteria. Content migration scope based on category is summarized in the table below: Analyze all content available on the site for above content categories and categorize content pages accordingly. This will identify content that needs migration. Sample Content category analysis format is illustrated below: Suppose we are analyzing a content site having pages that display various offers and promotions for products available to the end user. Offers and promotions pages are organized as channels in V7 which are in turn displayed as menu levels to the end user. Various Content Types used on these pages are Offer Summary, Offer Details, Promotion Event, Article, and MultiPage Article. ‘Application’ is a special keyword used to define application pages that are rendered by the server side logic and does not have any Content Type associated with it. ‘Offer Details’ content that is displayed on a page Offers and Promotions -> Offers -> Offers Summary -> Offer Details in the V7 system is present in the V6 system as well. But as Offer Details are changing quite frequently, say within 1 week of period, and also they are not required to be maintained for any future purpose they are categorized as ‘Always New – Old Data Not Required’. This means that content on offer details page need not be migrated. ‘Membership event’ content that is displayed on a page Offers and Promotions -> Membership Event in the V7 system is present in the V6 system and content is going to remain the same. Hence, content on this page is categorized as ‘Same as V6’. This means that content on Membership event page need to be migrated.
Establishing Automated Migration FeasibilityEarlier process has identified content that is to be migrated. Now this process checks whether that content can be migrated through an automated process or need manual intervention. To migrate the content, it is necessary to analyze the way content is structured, that is the content format, in both V6 and V7 systems. Analyzing Content Type format differences in V6 and V7 Content in Vignette, that is shown on the website and content management related items such as workflows are stored in the database. Content is stored in database tables in both the V6 as well as V7 systems but the way content is structured is quite different. In V6, every content instance is in the form of a ‘Story’ item. That is, single content type caters to all forms of content. Story is managed using set of tables, Story and Story Detail in the database. E.g. Article content instance is stored as one Story item and Offer Summary content instance is stored as other Story item in the same set of tables.
Diagram: V6 Data Format In V7, different forms of content instance have different Content Types. Each Content Type has its own set of tables. Content Type format and its table structure is user defined in V7. E.g. Article content instance is stored as an item in Article Content Type tables and Offer Summary content instance is stored as an item in Offer Summary type tables.
Diagram: V7 Data Format As can be seen here, both content format and its storage are changed in V7 from V6. For content migration, old content format in V6 need to be mapped with the new format in V7. In other words, story data in V6 system need to be mapped with the individual Content Type data in V7 system. Since content format is closely associated with the content storage in database tables, table schema in V6 need to be mapped with the table schema in V7. Mapping defines how Content Type tables will get populated from story tables. Some story attributes (column values) will get directly mapped with new Content Type related attributes whereas others may need some transformation logic. Mapping Content Type Format While migrating content from V6 into V7, it is required to check source attribute for each destination attribute in the new Content Type. Source attribute can be coming from story attribute or folder attribute in V6 or it need to be populated using some logic. Different Content Types in V7 such as Article, Offer Summary, Offer Details need to be mapped with V6 Story. Objective of this Content Type mapping exercise is to find if content present in old format Story, can be migrated using an automated process. All V7 Content Types whose attributes map to the old Story content or can be populated using some logic will be available for automated migration process. Other Content Types will need to follow manual migration process. As a sample, this article tries to map content of type ‘Article’. Typical table structure for ‘Story’ in V6 is shown below.
Diagram: V6 Table Structure V6 Table Structure Description - Content instance is organized into Story, Story Detail, Links and Images tables. T_STORY table contains meta information and common attributes for a content instance (Story). T_STORY_DETAIL table contains actual content for a story. One Story can have multiple Story details. T_LINKS table contain hyperlinks. One story detail can have multiple links. T_IMAGES table holds images. One story detail can have multiple images. Typical table structure for ‘Article’ Content Type in V7 is shown below.
Diagram: Article Content Table Structure Mapping Now let us have a look at how individual attributes in Article tables get mapped to the Story attributes. Some V7 attributes can be mapped directly to V6 attributes, some will need transformation and others will either remain blank or need manual process. Table below shows mapping for TB_ARTICLE table. Table below shows mapping for TB_ARTICLE_DETAIL table. The conclusion from the above analysis is that most of the attributes from V7 ‘Article’ table can get mapped with V6 data and hence Content Type ‘Article’ can be migrated through an automated process. Note that, in the above sample ‘Article’ Content Type, one story item from V6 is getting mapped with one article item. There might be instances where more than one story item form an article or one story item forms multiple articles. Content analysis should cater for such variations in the Content Type mapping. Such scenarios provide scope for different migration logic for the same Content Type based on different mappings. In the next and final installment of this series, we will discuss the process of defining an approach for the overall migration process, talk Java, and discuss the VBIS adapter process. If you missed the first article, tune in here: How-To: Migrating Content to Vignette Version 7 (Part 1).