Migration overview

The goal of migration is for you to be able to continue to work in the current version of the product with projects that you developed in earlier versions. Projects that you created in earlier versions can be migrated to this version.
Projects from earlier versions are migrated using the Workspace Migration wizard. When projects from earlier versions are detected in the current version, the Workspace Migration wizard starts automatically and selects the projects to migrate. There are three general methods to bring projects from earlier versions into the current version:
  • Export and import projects as archive files: You can export projects from earlier versions using the Export Archive File feature (File > Export > Other > Archive File) and import them into your workspace.
  • Share projects from a source code management system: You can import projects from earlier versions that exist in a source code management (SCM) system.
  • Open a version 9.5.x or version 9.1.x workspace in the current version: When a workspace from version 9.5.x or version 9.1.x is opened in the current version, the projects within that workspace can be migrated to the current version. Also, the workspace itself is migrated.

Versions of workspaces and projects that can be directly migrated to version 9.6.x

You can migrate workspaces and projects directly from the following earlier versions of this product:
  • V9.5.x
  • V9.1.x

Target runtimes and servers that are supported in version 9.6.x

All application server runtimes that were available in V9.5.x and V9.1.x are also supported in this version.

Note: Portal Server 9.0.x is supported in version 9.6.1 and later, but not in version 9.6.

Compatibility of migrated projects and workspaces with earlier versions

This section describes the compatibility of a project (or other artifact) to work with earlier versions of the product.
  • Compatibility of migrated workspaces with earlier versions:
    Important: If you open a workspace from an earlier version in the current version, then you cannot open the workspace again in the earlier version. If you open a workspace from an earlier version in the current version, the workspace is automatically migrated to the current version.

    Projects in the migrated workspace can, however, be shared with earlier versions. For example, you can share a projects by exporting the project resources or sharing the project through a source code management system.

  • Compatibility of migrated projects with earlier versions:
    • Projects migrated from versions 9.5.x and 9.1.x to the current version are compatible for sharing back to the original version.

For more information about compatibility of migrated projects with earlier versions, see Compatibility with version 9.5.x and version 9.1.x.

Tools for migrating

If you are familiar with how projects were migrated in earlier versions of the product, then you might want to note the following changes made in version 9.5.x and continued in this version:
  • Workspace migration wizard for migrating projects and other artifacts: The new Workspace Migration wizard helps you to do the following things:
    • You can select which projects to migrate.
    • You can see which files are modified during the migration process.
    • For projects that target runtimes that are not available in the current version, you can choose which runtime to use instead.
    • For workspaces that contain metadata related to servers that are not supported or available in your current workbench, you can choose to remove the server metadata.
  • Migration validator and validation view: You can view detailed migration results for each migrated project.

Migrating when working with a source code management system

During the migration process, any files that are under management of a source code management (SCM) system that must be modified are automatically checked out. However, these files are not automatically checked in; you must check in the files manually. For details, see Migrating workspaces and projects from version 9.5.x or version 9.1.x.

If you are migrating a project that is in an SCM system, then do the following steps to simplify tracking which files must be checked in after migrating:
  1. In the earlier version of the workspace, check out the entire project from the SCM system. By checking out the entire project manually before going through the migration process, all files in the project are already in a read/write state for the migration process.
  2. Migrate the project.
  3. Check in the project.

After migrating the project, if you need to restore the project to a point that is earlier than when you migrated the project, you must delete the project from your workspace and start the migration process again. If you delete the project, ensure that you select the option to delete the contents on disk.

Feedback