Update data after migration

After you have migrated version 6.0 or 6.1 system to a version 7.0 system, and successfully tested version 7.0 system, update version 7.0 data with the latest version 6.0 or 6.1 data.

When you perform a post migration data update you will lose any changes you have made to the data you initially migrated. You should avoid changing the data you initially migrated on version 7.0 server and only use it to initially set up and test version 7.0 environment. If you need to continue adding content to site, continue to do so on version 6.0 or 6.1 system and then perform a post-migration data update to version 7.0 data.

• Steps when migrating from version 6.0.x.

  1. Stop the portal server on both the 6.0.x system and the 7.0 system.

  2. Delete the JCR database on the 7.0 portal. Refer to DBMS documentation for details on deleting database and dropping tables.

  3. Recopy JCR data from the version 6.0.x system, and connect the version 7.0 primary server to the copied data repository.
     Refer to Reusing v6.0.1.x JCR domain data for more information.

  4. Run the post-migrate-wcm-data task from the WP_PROFILE/PortalServer/migration directory of the 7.0 system.

     • Windows: WPmigrate.bat post-migrate-wcm-data -DPortalAdminPwd=foo -DWasPassword=foo -DbackupDirectory=directory -DprofileName=profile_name

     • UNIX: ./WPmigrate.sh post-migrate-wcm-data -DPortalAdminPwd=foo -DWasPassword=foo -DbackupDirectory=directory -DprofileName=profile_name

     • i: WPmigrate.sh post-migrate-wcm-data -DPortalAdminPwd=foo -DWasPassword=foo -DbackupDirectory=directory -DprofileName=profile_name

     backupDirectory
     The directory where data from the earlier server is stored for subsequent use. If this directory does not exist, the portal-pre-upgrade task creates it. For example, if you specify mybackup, the migration task stores the data under the mybackup directory.
     
     profileName
     Optional: If you are not using the default profile wp_profile, specify the appropriate profile name.

  5. Cluster only: Compare the icm.properties file on all secondary nodes with the version of the file on the primary node, and ensure that all instances of the file are identical to that on the primary node.
     If the files are not identical, copy icm.properties from the primary node on which you ran the database-transfer task to the secondary node.

     1. Stop the portal server on the secondary node.

     2. Copy
        WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

        from the primary node and replace icm.properties on the secondary node.

     3. Start the portal server on the secondary node.

  6. Once have performed these steps, review the following optional post migration steps and update system as required:

     1. If users have been updated on 6.0.x server since the original migration, run the member fixer tool on the 7.0 server after migrating updated data. Refer to Use the web content member fixer task for more information.

     2. Reset the event log to ensure that items are syndicated correctly when syndication is enabled. Refer to Reset the web content event log for further information.

     3. Syndicate the updated data from version 7.0 primary server to the other servers in system.

     4. If the page builder theme was deployed after migration, redeploy it as described in Add the Page Builder theme.

• Steps when migrating from version 6.1.x.

  1. Stop the portal server on both the 6.1.x system and the 7.0 system.

  2. Delete the JCR database on the 7.0 portal. Refer to DBMS documentation for details on deleting database and dropping tables.

  3. Update the jcr.* database properties in the WP_PROFILE/ConfigEngine/properties/wkplc_dbdomain.properties, and run the connect-database task from the WP_PROFILE/ConfigEngine.

     • Windows: ConfigEngine.bat connect-database -DPortalAdminPwd=foo -DWasPassword=foo -DTransferDomainList=jcr

     • UNIX: ./ConfigEngine.sh connect-database -DPortalAdminPwd=foo -DWasPassword=foo -DTransferDomainList=jcr

     • i: ConfigEngine.sh connect-database -DPortalAdminPwd=foo -DWasPassword=foo -DTransferDomainList=jcr

  4. Run the wcm-post-migration-data-update task from the WP_PROFILE/ConfigEngine of the 7.0 system.

     • Windows: ConfigEngine.bat wcm-post-migration-data-update -DPortalAdminPwd=foo -DWasPassword=foo -DbackupDirectory=directory -DprofileName=profile_name

     • UNIX: ./ConfigEngine.sh wcm-post-migration-data-update -DPortalAdminPwd=foo -DWasPassword=foo -DbackupDirectory=directory -DprofileName=profile_name

     • i: ConfigEngine.sh wcm-post-migration-data-update -DPortalAdminPwd=foo -DWasPassword=foo -DbackupDirectory=directory -DprofileName=profile_name

     backupDirectory
     The directory where data from the earlier server is stored for subsequent use. If this directory does not exist, the portal-pre-upgrade task creates it. For example, if you specify mybackup, the migration task stores the data under the mybackup directory.
     
     profileName
     Optional: If you are not using the default profile wp_profile, specify the appropriate profile name.

  5. Cluster only: Compare the icm.properties file on all secondary nodes with the version of the file on the primary node, and ensure that all instances of the file are identical to that on the primary node.
     If the files are not identical, copy icm.properties from the primary node on which you ran the database-transfer task to the secondary node.

     1. Stop the portal server on the secondary node.

     2. Copy
        WP_PROFILE/PortalServer/jcr/lib/com/ibm/icm/icm.properties

        from the primary node and replace icm.properties on the secondary node.

     3. Start the portal server on the secondary node.

  6. Once have performed these steps, review the following optional post migration steps and update system as required:

     1. If users have been updated on 6.1.x server since the original migration, run the member fixer tool on the 7.0 server after migrating updated data. Refer to Use the web content member fixer task for more information.

     2. Reset the event log to ensure that items are syndicated correctly when syndication is enabled. Refer to Reset the web content event log for further information.

     3. Syndicate the updated data from version 7.0 primary server to the other servers in system.

     4. If the page builder theme was deployed after migration, redeploy it as described in Add the Page Builder theme.

Parent: Deploy new functionality in a migrated portal: wp7
Use the web content member fixer task: wp7

Related tasks

Reusing v6.0.1.x JCR domain data: wp7
Reset the web content event log: wp7
Add the Page Builder theme: wp7 August 30, 2010 11:15:11 PM

  2011/12/15 documentation refresh This version (1)

+

Search Tips   |   Advanced Search