Export configuration for migration to a remote server

To back up server artifacts, extract database information, and export content from WebSphere Portal v6.0.1.x running on either Windows™ or UNIX™, run the WPmigrate script with the portal-pre-upgrade task from the previously prepared directory that contains the required supplementary files.

These instructions are not intended for use on IBM i. To perform a remote migration on i, install the new version of WebSphere Portal on the same server as the earlier version, and then follow the steps in the topic that explains how to export core information for migration to the same machine. After running the portal-pre-upgrade task, you can move the backup directory that contains the exported information to the remote machine where the new portal version to use is installed, and then continue the migration process. To do this, follow the steps in the topic that explains how to import core information for migration to a remote machine.


Prerequisites


Prepare for migration from v6.0.1.x
Prepare supplementary files for remote migration

From the supp_dir directory on the WebSphere Portal v6.0.1.x server, run WPmigrate with the portal-pre-upgrade task as follows:

where:

Migration log output for the portal-pre-upgrade task is stored in several different log files that you can view using a text editor. For more information, see the topic on WebSphere Portal logs.

  1. Stop the WAS and WebSphere Portal servers (server1 and WebSphere_Portal) in the new portal installation.

  2. Start the earlier WebSphere Portal server and ensure that it is accessible to the network.

  3. On the server where the earlier portal installation is located, change to the CD_root/PortalMigrationPortalRemMigPkg directory that you set up in the previous task when you assembled the supplementary files needed for migration to a remote server.

  4. To export the base server, run the portal-pre-upgrade task as follows:

    • Windows:

        WPmigrate.bat portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname

        -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword

    • UNIX:

        ./WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname

        -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword

    • i:

        WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname

        -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword

      where:
      backupDirectory

        The directory where data from the earlier server will be stored for subsequent use with the portal-post-upgrade task. 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.


      currentPortalDirectory

        The directory where the earlier portal server is installed.

      currentPortalAdminId

        The administrator ID for the earlier portal server. Not required if it is already specified in the wpconfig.properties file on the earlier portal server.

      currentPortalAdminPwd

        The administrator password for the earlier portal server.

      DbPassword

        The DBMS user password for the earlier portal server. Specify this property value in the command line only if the property is not already specified. In WebSphere Portal v6.0.1.3 or later, the property value is specified in the wpconfig_dbdomain.properties file, next to the property name release.DbPassword.

        All other database properties must be specified in the properties file.

      The following properties are optional:
      GroupExport

        Exports groups from the earlier version when the value is set to true. This property is set by default to false.

        GroupExport=true should only be used if you are using delegated access control for users and groups in the portal. For typical installations where delegated access control is not in use, exporting groups is not recommended due to its performance impact.

        If you are using delegated access control, the following considerations apply:

        • If the portal uses the WMM database repository for application groups, this option is not required as the groups are migrated automatically by the WMM to VMM migration.

        • The ability to export groups from the earlier portal depends on the number of groups and the amount of time specified in the Enterprise Java Bean (EJB) transaction setting. If the number of groups is too high to export within the amount of time specified in the EJB transaction setting, the portal-pre-upgrade task may report an error. Try increasing the wmmAPP EJB transaction time. For more information, see Configuring transactional deployment attributes in the WAS information center.


      SkipAiMigration

        Suppresses migration of composite applications when set to any value. When this property is omitted, composite applications are included in migration.

  5. For each virtual portal that you want to migrate, run the portal-pre-upgrade task, as described above, and include the additional VirtualPortal property:

    • Windows:

        WPmigrate.bat portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword -DVirtualPortal=URL context

    • UNIX:

        ./WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword -DVirtualPortal=URL context

    • i:

        WPmigrate.sh portal-pre-upgrade -DbackupDirectory=dirname -DcurrentPortalDirectory=dirname -DcurrentPortalAdminId=adminid -DcurrentPortalAdminPwd=adminpassword -DDbPassword=dbpassword -DVirtualPortal=URL context

      where:
      VirtualPortal

        The context extension for the virtual portal URL. See the URL Context description row in the Virtual Portal Manager portlet.


      Notes:

      • The backup directory that you specify for the virtual portal must be the same backup directory that you specified in the previous step to export the base server.

      • Base server migration must be done before virtual portal migration.

      • Virtual portals must be exported individually, one at a time; you cannot export a collection of virtual portals at once.

  6. Check allout.xml for any warning or error messages, and address any issues before moving on.

      If you are migrating from version v6.0.1.3 or later, look for allout.xml in the backupDirectory/profiles/<profile dir>/PortalServer/migration/work/default directory where backupDirectory is the location that you specified in the previous step.

      If allout.xml contains messages with the ID EJPXA0185W or EJPXA0186W, see Technote 1300236 for additional information.


Parent

Migrate to a remote server
v6.0 post migration steps for web content
Installation, configuration, and migration logs


Related tasks


Suppressing migration of composite applications
Running migration tasks for composite applications


Work with xmlaccess.sh

Technote 1300236

WAS V7 Information Center

  Submitted by Dhaval Patel on Oct 8, 2010 1:10:06 PM

Export configuration for migration to a remote server: wp7

Under this section --

To avoid OutOfMemory errors when migrating a large number of applications and associated artifacts, add -Xmx1024M to the Java command line in WAS_HOME/bin/WASPreUpgrade.sh\.bat . For example: "$JAVA_HOME/bin/java" -Xmx1024M \

We need add a comment stating if you are doing remote migration, then one needs the above parameter in the WASPreUpgrade.sh file - which exists in the contents of the WAS Network Deployment v7.Supplements Disc 2 when they copy it on the source server.


+

Search Tips   |   Advanced Search