Phase 1: Analysis and preparation

During this phase, the project team does a complete analysis on the differences between version 4.3 and version 5.1, especially on the application logic layer. The project team can base on the documentation of the existing application system to identify the part that can be migrated automatically and the part that can not be migrated automatically and prepare what is necessary for the migration. Do the following:
  1. Gather all the definition files of the existing application system version 4.3. In the migration tool, it can migration the definition files on the server side from version 4.3 to version 5.1. The migration tool can process the tags based on the specification of version 4.3. If there are any special tag definitions, the migration tool might not be able to migrate it successfully or properly. For this situation, the project team needs to customize the migration tool to extend the process to contain the special definition for the application or do it manually later.
  2. The migration tool cannot migrate the business logic of the application to version 5.1 directly. The tool just creates a skeleton with the name corresponding to the server operation or the action in the flow. However, you can make extensions on the migration tool to move the business logic to the generated code automatically. The project team must do an investigation to check whether it is worth or not to extend the migration tool to add more functions.
  3. For the integrity, do not customize the migration process on the part of the screen flow generation. The business flow generation and the version 5.1 tooling artifact generation.
  4. The project team must package the application into a jar file and then copies the jar file into the plug-in directory of the migration tool and modifies the plug-in.xml to include the library because the migration tool refers to the applications when it does the migration.
  5. Because the migration tool can migration the non-step server operation to a Single Action EJB or a Business Process, the project team must separate the definition files and the application jar into different sets if the application will be migrated to have both set. The migration tool allows you to create multiple projects to migrate different sets of applications.
  6. The supported services in the server side leave JDBC Table Service and Electronic Journal Service, and the SNA LU0/6.2 communication services are changed to JCA connectors, the project team must find the substitutive solution (or implement a new service based on the new service architecture) for these unsupported services. For example, Lotus Notes(R) support, LDAP support, MQ connector, the relevant JCA connector. The migration tool can migrate the server side service definition by modifying the class information regarding the services that supported in BTT 5.1. The migration tool also modifies the DummyDB2Journal.
  7. The event mechanism is changed to fit version 5.1 framework to be distributable and span different server. The project team must check and modify the application accordingly if the event mechanism is adopted in the server side in the current application system.
  8. For the client application, there is no change. The project team does not need to migration it to version 5.1. The only thing is to verify the migrating invoker and the related property files to check whether they match the server operation name or not.
  9. If the future application only runs on WebSphere(R) Application Server, use WebSphere Studio Application Developer to migrate the application. If the future application runs on WebSphere Business Integration Server Foundation, using WebSphere Studio Application Developer Integration Edition and you will have more features supported. The migration tool will provide fewer features on WebSphere Studio Application Developer than WebSphere Studio Application Developer Integration Edition. The difference is there will be no supported for generating the business process. In WebSphere Studio Application Developer, the step operations or the flow processor will not be able to migrate. The project team needs to change it to be non-step operations, or just skip it and create the Single Action EJB manually. Also, the non-step operation can only be migrated to a Single Action EJB.
Related information
Events
Bean Invoker Factory