The figure below shows the architecture view of the migration tool.

As shown in the figure above, the migration tool consists of the migration
API modules and the UI features plus the custom batch migration application:
- Migration Modules: The migration modules include a set of the functions
of the migration process. The categories of the migration modules are:
- Definition transformer
- Code generator
- Tooling artifact generator
- Custom Extension
- Migration kits: The migration kits are the interfaces between the UI feature
(or the batch migration application) and the migration modules. The migration
kits access the migration factory to get the correct migration module object,
and then invoke the functions of the migration module.
- Migration module factory: It helps the migration kits to instantiate the
correct migration module object based on the definition file.
- UI Features: UI features focus on the user interface manipulation. All
of the activities that are related to the migration process will delegate
to the migration modules through the migration kits.
- Batch migration application: The batch migration application is not a
built feature in the migration tool. It has many UI interfaces and it can
invoke the migration activities one by one in default order and default parameters.
Import definition file from EAR
There are two ways
to input the definition files from an EAR file:
- Flatten the EAR file: This scenario first imports the EAR into RAD, and
then all the input files inside the web application WAR file, including definition
files and the source code of the application, are extracted and placed in
a web application project. Then, the migration tool gets the related files
from the specific URL.
Note: This approach will not work if the target files
are inside the reference jar files of the web application project. You have
to flatten the jar file too in order to get the target files by importing
them into the migration tool project or another project, for example, a Java™ application
project. Besides, this approach only works on RAD.
- Extract the files from the EAR directly: This scenario extracts the specific
files from the EAR file into the related project of the migration directly.
In this case, you need to know which package is the target staff from and
you need to indicate it for the migration tool. The advantage is that this
approach does not have the limitations of the previous one.
To reduce the operation complexity, the second approach is better
if the migration tool provides the location list of dse.ini for you to pick
up.
Batch migration mode definition file import
To perform
the batch migration, the EAR or the dse.ini path needs to be defined in an
external file. The migration file can use it as input to get the list.
Handle BTT definition files by BTT Externalizer
To
avoid the improper handling of BTT definition, it is better that you use BTT
Externalizer to carry out the definition handling and parsing