All Products
Search
Document Center

Data Transmission Service:Application assessment

Last Updated:Aug 21, 2026

Application assessment evaluates the migration and refactoring readiness of your applications and databases. It identifies which parts of your application require changes and provides refactoring suggestions to help you gauge the overall workload.

Prerequisites

You must have an application profile for every application collection package.

Background information

Migrating databases and applications presents several challenges:

  • Difficulty estimating the application refactoring workload.

  • Difficulty creating a detailed database migration plan.

  • Difficulty refactoring applications after migration, especially those that have been unmaintained for a long time.

Create an application assessment

  1. Enter the basic information, and select the target database and version for the assessment.

  2. Select one or more application profiles to assess.

    Note

    You can create an application assessment only after the associated database assessment for each selected application profile is complete.

  3. Select a completed database assessment project.

Overall assessment results

The assessment results are the core of the application assessment, presented from three perspectives: overall, migration group, and application node.

The assessment results initially display overall information. This aggregated assessment of your applications and databases helps you gauge the overall migration and refactoring effort.

  • Architecture list: Based on the relationships between databases and applications, ADAM uses intelligent algorithms to organize your components into migration groups. A migration group is the smallest migratable unit, meaning its migration does not affect data dependencies outside the group.

    Note

    Call relationships between applications are not considered.

  • Migration score: ADAM provides a quantitative score that represents the difficulty of migration and refactoring. A higher score indicates a lower application refactoring cost.

    Note

    The migration score is affected by the completeness of the collected data. Always consider your actual business requirements when estimating the migration cost.

  • Overall compatibility: Measures the compatibility of application SQL and database objects.

    Note

    Because the collected SQL is influenced by the database system itself, do not use the compatibility score as the sole basis for your assessment.

  • Architecture blueprint: A topology diagram that visualizes the status of each migration group. 2022-08-09_10-41-45

Migration group assessment results

A migration group is the smallest migratable subset of applications and databases. Migrating a single migration group does not create data dependencies on database nodes in other groups.

A migration group includes application nodes and database nodes. Click an application node to view the assessment and refactoring details for that specific node.

The assessment for a single application node consists of three main parts: application dependency, SQL compatibility, and application refactoring points.

  • Application dependency: Shows the database dependencies of the target application node, down to the schema level. The application dependency view provides a topology diagram of the application node's connections to its dependent database nodes. It also provides an application dependency database details table, with columns such as ID, Database profile ID, Database name, and Involved schemas.

  • SQL compatibility: Assesses the compatibility of application SQL, providing specific conversion rules and refactoring locations for each statement. This feature provides both an assessment summary and compatibility details. In the SQL compatibility dialog box, on the assessment summary tab, the compatibility ratio pie chart on the left shows the number of SQL statements in each compatibility state. The incompatible SQL operation ratio pie chart on the right shows the distribution of incompatible statements by operation type. The table below counts the number of compatible, compatible with modifications, and incompatible SQL statements for each operation type (UPDATE, INSERT, and SELECT). In the SQL compatibility dialog box, switch to the compatibility details tab, where you can filter the results using the compatibility filter. The table shows detailed information for each SQL statement, including its ID, schema, SQL type, compatibility status, source SQL, target SQL, and call stack. The compatibility status is one of the following: compatible, compatible with modifications, or incompatible.

    • Compatible: The application requires no refactoring and can run directly on the target database.

    • Compatible with modifications: ADAM provides a converted SQL statement. To ensure compatibility, replace the original SQL in your application with this converted statement.

    • Incompatible: The SQL statement cannot run on the target database. You must modify the application code or the SQL statement based on the provided refactoring suggestions.

  • Application refactoring points: Shows where the application requires refactoring and provides suggestions. This feature provides both a refactoring summary and refactoring details. In the application refactoring points dialog box, on the refactoring summary tab, you can view a breakdown of refactoring points by level (such as L1, L2, and L3) and a list of the primary rules triggered, including their instance counts and descriptions. For example, a rule might suggest a data type conversion for a function parameter. In the application refactoring points dialog box, select the refactoring details tab. You can use the refactoring point drop-down list at the top to filter the results. The details table includes columns such as SQL ID, rule ID, refactoring suggestion, source SQL, target SQL, and call stack. Common refactoring suggestions include remove from dual (Rule 34087), column name is reserved in PostgreSQL (Rule 33027), convert ROWID to CTID (Rule 34088), and rownum to limit (Rule 34086). The source SQL, target SQL, and call stack columns each provide a View link to inspect the specific SQL content and its call location.