Phase 1: Analysis and preparation

In this phase, you need to analyze the differences between BTT version 4.3 and BTT version 7.0, especially the application logic layer.

About this task
Based on the documentation of the existing application system, you can identify the parts that can be migrated automatically and the parts that cannot be migrated automatically, and then make necessary preparation for the migration. To get well prepared for the migration, you need to do the following work:
  1. Gather all the definition files of the existing application system version 4.3. The migration tool can migrate the definition files on the server side from version 4.3 to version 7.0. The migration tool can process the definition contents based on the given rules. BTT version 7.0 provides default migration rules, but if there are any special tag definitions that are not included in the default rules, the migration tool might not be able to migrate them successfully or properly. In this case, you need to customize the migration tool rules to extend the process to cover those special tag definitions for the application or migrate them manually later.
  2. The migration tool can migrate the business logic Java™ code of the application to BTT version 7.0 directly. BTT version 7.0 uses the processor, operation, and operation step on the server side of BTT, which is the same as in BTT version 4.3. The differences are in package names, class names, and changes of APIs. The migration tool can migrate BTT version 4.3 classes and APIs to the corresponding BTT version 7.0 classes and APIs.
  3. BTT version 7.0 provides more powerful Context and Formatter, and the API usage is different with that in BTT version 4.3. The migration tool of BTT version 7.0 can help you migrate the Context, Formatter, and APIs for the migration.
  4. Do manual migration to run the BTT version 4.3 event in BTT version 7.0, because the prior event mechanism is changed to fit BTT version 7.0 framework.
  5. Migrate BTT version 4.3 services. The supported services of BTT version 7.0 on the server side does not support all of the BTT version 4.3 services, and the SNA LU0/6.2 communication services are changed to JCA connectors. You must find a substitutive solution (or implement a new service based on the new service architecture) for these unsupported services. For example, Lotus Notes® support, LDAP support, MQ connector, and the relevant JCA connector. The migration tool can migrate the server side service definitions with customized migration rules, but you must find a substitutive solution for the unsupported services.
  6. The event mechanism is changed to fit version 7.0 framework so that it can be distributable and spans different servers. You must check and modify the applications accordingly if the event mechanism is adopted in the server side in the current application system.
  7. There are two kinds of client applications in BTT version 4.3. There is no change to the Swing based Java client, so you do not need to migrate it to BTT version 7.0. For JSP/HTML based client, the migration tool does not support its migration, so manual migration is needed.
  8. Migrate the BTT trace. BTT version 7.0 enhances the trace features to support more powerful functions and comprehensive APIs. BTT version 7.0 trace is completely compatible with BTT version 4.3 trace. If you do not want to use the new trace framework, the old trace can still work in BTT version 7.0 runtime container. If you want to use the new trace, use the migration tool to achieve the trace by defining specific migration rules.
  9. If the future application only runs on WebSphere® Application Server, use Rational® Application Developer to migrate the application. If the future application runs on WebSphere Process Server, use WebSphere Integration Developer to migrate the application.