Before migrating from EAServer 5.x to EAServer 6.0:
Make a backup of your existing 5.x installation.
Consider what you need to migrate. For example, exclude unused components, outdated samples, obsolete code, and so on, if no longer needed.
If possible, migrate from a server you are not using for production. EAServer 5.x may need patches to ensure proper migration to EAServer 6.0. Patching the server may alter its behavior, and require the server to be restarted numerous times (after patch application, and after patch removal).
Develop a migration strategy for clusters. If all servers in the cluster have the same components, you need only migrate the primary server, then use 6.0 clustering to synchronize with other 6.0 servers.
Consider facilities that are no longer supported in EAServer 6.0, since they will either cause migration failures, or be marked as ineligible for migration. For example, PowerBuilder components with a version earlier than 10.0, CORBA/EJB Web Service Toolkit Web services, and OCI 8 or earlier connection caches are no longer supported in EAServer 6.0. See “Unsupported features”.
Decide whether you will execute the migration process in GUI mode, or from the command line.
Determine whether the 5.x and 6.0 server will be on the same machine, and whether the 5.x server will be running during the migration process. This determines whether the migration is performed in local mode or remote mode. Java Message Service (JMS) and Web service migration are not available in local mode.
Check for packages with mixed component types, or applications that contain non-J2EE components. You must separate mixed-component packages, and non-J2EE packages from applications and migrate them separately. See “Packages with mixed component types”.
Consider your migration strategy. You may want to migrate entities one at a time, checking successful migration of the single entity before moving on to the next entity. The same may apply for entity types. For example, you might want to migrate connection caches first, and ensure they have been migrated successfully. Then migrate components that use those connection caches.
Determine whether there are dependencies in your 5.x server that may need to be manually migrated to 6.0 to allow successful migration. For example:
Are there Java classes in the system class path that may be needed for successful deployment?
Are there configuration or ini files that may be needed at runtime by the component you are migrating?
Are there environment variables that may be needed by components?
Do any of your components have dependencies on the JAGUAR environment variable? The run-server script sets a system property for the JAGUAR environment variable, and also sets it to the same value as DJC_HOME. This means any components running inside the server that depend on JAGUAR being set at the root of the server installation maintain the correct value. However, you should still consider how your components depend on the JAGUAR environment variable.For example, you must manually migrate the $JAGUAR/foobar_app/config directory to the $DJC_HOME/foobar_app/config directory, if $JAGUAR/foobar_app/config is not automatically migrated due to settings in your application that specify a dependency on this directory.
