Migrate pre-Dimensions 12 deployment data‌

You can migrate existing deployment data from pre-Dimensions CM 12 to version 14 and use it with the new deployment model. There are two separate processes that enable you to use your existing deployment areas:

  • The Dimensions CM 14 database upgrade that is performed automatically during installation.

  • A manual standalone upgrade/migration process (documented here) that migrates your existing deployment information into the new format first introduced with Dimensions CM 12.1. You can run this migration process when you are ready to bring a deployment area online for use in Dimensions CM 14.

Important:

  • You cannot deploy to an area that has not been upgraded.

  • You must upgrade the metadata in an area before upgrading it. For details about the dmmeta Metadata Utility, see the Command- Line Reference.

You can migrate existing deployment data from pre-Dimensions CM version 12 to 14 for one or all of your registered deployment areas. The areas being migrated must be online, accessible, and have valid login credentials specified against them for the migration process to work. For each area being migrated the process performs the following operations:

  • Checks that the remote area is online and available.

  • Scans the contents of the remote area for files that were placed there by Dimensions CM.

  • Creates an initial area version that represents the current contents of that area based on the scan.

  • Creates an area audit trail that reflects the area version that was just created.

  • Validates that the area version just created is correct.

Prepare for migration‌

To successfully run the migration process you must first decide which areas need to be migrated and have those areas online and available. By default, the migration process attempts to migrate all active deployment areas currently registered in your database. If you are only using some of your deployment areas you should only migrate these and leave the others until needed.

Run the following checks against each area to make the migration process run smoothly:

  • Check the area is online and is accessible to Dimensions CM. If it is running on a Dimensions CM agent, verify that the agent has been started and is running.

  • Check the area definition has an area user and password associated with it. Failure to do so means that the migration of this area are skipped.

Note:  

  • Unix: Run an AUDIT operation against each area before upgrading.

  • This note applies only to areas hosted on z/OS mainframes on the MVS file system (not the z/OS UNIX file system).

    The migration process described below explores all MVS data sets inside the area root. Some of the data sets may have been migrated to tape using the HSM product and the upgrade automatically recalls the data sets from tape. However, if this must done for hundreds of data sets it can be a long process as they are recalled one at a time. We recommend that you perform the upgrade one area at a time (using the -area switch on the command) and make sure that all the relevant data sets are recalled prior to issuing the command. This is a more efficient than a bulk recall of all the data sets. You can also skip old areas that are no longer needed (these areas are likely to be on tape).

Run the migration process‌

You must run the migration process on a Dimensions CM server installation using dmdba. See the Administration Guide for details about invoking dmdba.

For each Dimensions CM base database that you want to migrate, perform the following steps:

  1. Log in as a valid CM administrator and set up the environment.

  2. Invoke dmdba against the SYSTEM (on Oracle) or PCMS_SYS (MSSQL) databases, for example:

    dmdba system/manager@dim14 (Oracle) 
    dmdba pcms_sys@dim14 (MSSQL)

  3. Run the following dmdba command:

    UPGRADEDEPLOY <baseDb>@<dsn>

    where:

    <baseDb>@<dsn> refers to the name of the Dimensions CM base database that you want to upgrade.

    The UPGRADEDEPLOY command can also accept these optional qualifiers:

    • area <areaId>

      Forces the migration process to only process the specified area identifier. If this qualifier is not specified all registered deployment areas are migrated.

    • –hidden

      Automatically registers any migrated files that are not displayed in the deployment views.

    • -force

      Forces the migration process to attempt to re-migrate the area even if it has already been migrated.

    Example commands:

    • To upgrade all the deployment areas in CM_TYPICAL:

      SYSTEM> UPGRADEDEPLOY cm_typical@dim14

    • To upgrade only the deployment area LIVE in CM_TYPICAL:

      SYSTEM> UPGRADEDEPLOY cm_typical@dim14 –area live

    • To upgrade only the deployment area LIVE in CM_TYPICAL and hide the migrated files:

      SYSTEM> UPGRADEDEPLOY cm_typical@dim14 –area live - hidden

Migration process restrictions

  • After you upgrade to Dimensions CM 14, the history for deployment areas only displays the new 'Deployment' event type and does not display pre-Dimensions CM 12 history. However, all of the pre- Dimensions CM 12 data can be queried from the PCMS_PROMOTE_HISTORY published view.

  • The audit trail created by the migration process only consists of an initial area version and a list of all the items that are currently deployed to that area. Details of requests or baselines that might have also been deployed to that area are not created.

  • When running the migration, any z/OS systems that are hosting deployment areas must have already been upgraded to Dimensions CM 14. Failure to do so causes the migration process to fail.

  • Items that have been upgraded as a result of this migration process cannot be rolled back unless they are specifically redeployed.