User Interface Guide

Table of Contents

Making open source more inclusive
1. Introduction
2. User interface views
3. Installing the Migration Toolkit for Applications user interface
4. Configuring the instance environment
5. Creating and configuring a Jira connection
- 5.1. Configuring Jira credentials
- 5.2. Creating and configuring a Jira connection
6. Assessing and analyzing applications
7. Working with Applications

Making open source more inclusive

Red Hat is committed to replacing problematic language in our code, documentation, and web properties. We are beginning with these four terms: master, slave, blacklist, and whitelist. Because of the enormity of this endeavor, these changes will be implemented gradually over several upcoming releases. For more details, see our CTO Chris Wright’s message.

1. Introduction

1.1. About the User Interface Guide

This guide is for architects, engineers, consultants, and others who want to use the Migration Toolkit for Applications (MTA) user interface to accelerate large-scale application modernization efforts across hybrid cloud environments on Red Hat OpenShift. This solution provides insight throughout the adoption process, at both the portfolio and application levels: inventory, assess, analyze, and manage applications for faster migration to OpenShift via the user interface.

Note	The migration solution that was provided in the Migration Toolkit for Applications 5.x releases (migration and modernization of Java applications) is now available with Migration Toolkit for Runtimes 1.0.

1.2. About the Migration Toolkit for Applications

What is the Migration Toolkit for Applications?

Migration Toolkit for Applications (MTA) accelerates large-scale application modernization efforts across hybrid cloud environments on Red Hat OpenShift. This solution provides insight throughout the adoption process, at both the portfolio and application levels: inventory, assess, analyze, and manage applications for faster migration to OpenShift via the user interface.

MTA uses an extensive default questionnaire as the basis for assessing your applications, or you can create your own custom questionnaire, enabling you to estimate the difficulty, time, and other resources needed to prepare an application for containerization. You can use the results of an assessment as the basis for discussions between stakeholders to determine which applications are good candidates for containerization, which require significant work first, and which are not suitable for containerization.

MTA analyzes applications by applying one or more rulesets to each application considered to determine which specific lines of that application must be modified before it can be modernized.

MTA examines application artifacts, including project source directories and application archives, and then produces an HTML report highlighting areas needing changes.

How does the Migration Toolkit for Applications simplify migration?

The Migration Toolkit for Applications looks for common resources and known trouble spots when migrating applications. It provides a high-level view of the technologies used by the application.

MTA generates a detailed report evaluating a migration or modernization path. This report can help you to estimate the effort required for large-scale projects and to reduce the work involved.

1.3. About the user interface

The user interface for the Migration Toolkit for Applications allows a team of users to assess and analyze applications for risks and suitability for migration to hybrid cloud environments on Red Hat OpenShift.

Use the user interface to assess and analyze your applications to get insights about potential pitfalls in the adoption process, at both the portfolio and application levels as you inventory, assess, analyze, and manage applications for faster migration to OpenShift.

2. User interface views

The Migration Toolkit for Applications (MTA) user interface has two views:

Administration view
Migration view

In Administration view, you configure the instance environment, working with credentials, repositories, HTTP and HTTPS proxy definitions, custom migration targets, and issue management.

In Migration view, you perform application assessments and analyses, review reports, and add applications for assessment and analysis.

3. Installing the Migration Toolkit for Applications user interface

You can install the Migration Toolkit for Applications (MTA) user interface as part of the process of installing the MTA Operator on the OpenShift Container Platform.

The MTA Operator is a structural layer that manages resources deployed on Kubernetes (database, front end, back end) to automatically create an MTA instance.

3.1. Persistent volume requirements

To successfully deploy, the MTA Operator requires 2 RWO persistent volumes (PVs) used by different components. If the rwx_supported configuration option is set to true, the MTA Operator requires an additional 2 RWX PVs that are used by Maven and the hub file storage. The PVs are described in the table below:

Table 1. Required persistent volumes
Name	Default size	Access mode	Description
`hub database`	10 GiB	RWO	Hub database
`hub bucket`	100 GiB	RWX	Hub file storage; required if the `rwx_supported` configuration option is set to `true`
`keycloak postgresql`	1 GiB	RWO	Keycloak back end database
`cache`	100 GiB	RWX	Maven m2 cache; required if the `rwx_supported` configuration option is set to `true`

3.2. Installing the Migration Toolkit for Applications Operator and the user interface

You can install the Migration Toolkit for Applications (MTA) and the user interface on OpenShift Container Platform versions 4.13-4.15 when you install the Migration Toolkit for Applications Operator.

Prerequisites

4 vCPUs, 8 GiB RAM, and 40 GiB persistent storage.
OpenShift Container Platform 4.13-4.15 installed.
You must be logged in as a user with cluster-admin permissions.

For more information, see OpenShift Operator Life Cycles.

Procedure

In the OpenShift Container Platform web console, click Operators → OperatorHub.
Use the Filter by keyword field to search for MTA.
Click the Migration Toolkit for Applications Operator and then click Install.
On the Install Operator page, click Install.
Click Operators → Installed Operators to verify that the MTA Operator appears in the openshift-mta project with the status Succeeded.
Click the MTA Operator.
Under Provided APIs, locate Tackle, and click Create Instance.

The Create Tackle window opens in Form view.
Review the custom resource (CR) settings. The default choices should be acceptable, but make sure to check the system requirements for storage, memory, and cores.

To work directly with the YAML file, click YAML view and review the CR settings that are listed in the spec section of the YAML file.

The most commonly used CR settings are listed in this table:

Table 2. Tackle CR settings
Name	Default	Description
`cache_data_volume_size`	`100 GiB`	Size requested for the cache volume; ignored when `rwx_supported=false`
`cache_storage_class`	Default storage class	Storage class used for the cache volume; ignored when `rwx_supported=false`
`feature_auth_required`	`True`	Flag to indicate whether keycloak authorization is required (single user/“noauth”)
`feature_isolate_namespace`	`True`	Flag to indicate whether namespace isolation using network policies is enabled
`hub_database_volume_size`	`10 GiB`	Size requested for the Hub database volume
`hub_bucket_volume_size`	`100 GiB`	Size requested for the Hub bucket volume
`hub_bucket_storage_class`	Default storage class	Storage class used for the bucket volume
`keycloak_database_data_volume_size`	`1 GiB`	Size requested for the Keycloak database volume
`pathfinder_database_data_volume_size`	`1 GiB`	Size requested for the Pathfinder database volume
`maven_data_volume_size`	`100 GiB`	Size requested for the Maven m2 cache volume; deprecated in MTA 6.0.1
`rwx_storage_class`	NA	Storage class requested for the Tackle RWX volumes; deprecated in MTA 6.0.1
`rwx_supported`	`True`	Flag to indicate whether the cluster storage supports RWX mode
`rwo_storage_class`	NA	Storage class requested for the Tackle RW0 volumes
`rhsso_external_access`	`False`	Flag to indicate whether a dedicated route is created to access the MTA managed RHSSO instance
`analyzer_container_limits_cpu`	`1`	Maximum number of CPUs the pod is allowed to use
`analyzer_container_limits_memory`	`4GiB`	Maximum amount of memory the pod is allowed to use. You can increase this limit if the pod displays `OOMKilled` errors.
`analyzer_container_requests_cpu`	`1`	Minimum number of CPUs the pod needs to run
`analyzer_container_requests_memory`	`4GiB`	Minimum amount of memory the pod needs to run

Example YAML file

kind: Tackle
apiVersion: tackle.konveyor.io/v1alpha1
metadata:
  name: mta
  namespace: openshift-mta
spec:
  hub_bucket_volume_size: "25Gi"
  maven_data_volume_size: "25Gi"
  rwx_supported: "false"

Edit the CR settings if needed, and then click Create.
In Administration view, click Workloads → Pods to verify that the MTA pods are running.
Access the user interface from your browser by using the route exposed by the mta-ui application within OpenShift.
Use the following credentials to log in:
- User name: admin
- Password: Passw0rd!
When prompted, create a new password.

3.3. Installing the Migration Toolkit for Applications Operator in a disconnected OpenShift Container Platform environment

You can install the MTA Operator in a disconnected environment by following the instructions in generic procedure.

In step 1 of the generic procedure, configure the image set for mirroring as follows:

kind: ImageSetConfiguration
apiVersion: mirror.openshift.io/v1alpha2
storageConfig:
  registry:
    imageURL: registry.to.mirror.to
    skipTLS: false
mirror:
  operators:
  - catalog: registry.redhat.io/redhat/redhat-operator-index:v4.15
    packages:
    - name: mta-operator
      channels:
      - name: stable-v7.0
    - name: rhsso-operator
      channels:
      - name: stable
  helm: {}

3.4. Memory requirements for running MTA on Red Hat OpenShift Local

When installed on Red Hat OpenShift Local, MTA requires a minimum amount of memory to complete its analysis. Adding memory makes the analysis process run faster. The table below describes the MTA performance with varying amounts of memory.

Table 3. OpenShift Local MTA memory requirements
Memory (GiB)	Description
`10`	MTA cannot run the analysis due to insufficient memory
`11`	MTA cannot run the analysis due to insufficient memory
`12`	MTA works and the analysis is completed in approximately 3 minutes
`15`	MTA works and the analysis is completed in less than 2 minutes
`20`	MTA works quickly, and the analysis is completed in less than 1 minute

The test results indicate that the minimum amount of memory for running MTA on OpenShift Local is 12 GiB.

Note

The tests were performed by running the MTA binary analysis through the user interface.
All the analyses used the tackle-testapp binary.
All the tests were conducted on an OpenShift Local cluster without the monitoring tools installed.
Installing the cluster monitoring tools requires an additional 5 GiB of memory.

3.4.1. Eviction threshold

Each node has a certain amount of memory allocated to it. Some of that memory is reserved for system services. The rest of the memory is intended for running pods. If the pods use more than their allocated amount of memory, an out-of-memory event is triggered and the node is terminated with a OOMKilled error.

To prevent out-of-memory events and protect nodes, use the --eviction-hard setting. This setting specifies the threshold of memory availability below which the node evicts pods. The value of the setting can be absolute or a percentage.

Example of node memory allocation settings

Node capacity: 32 GiB
--system-reserved setting: 3 GiB
--eviction-hard setting: 100 MiB

The amount of memory available for running pods on this node is 28.9 GiB. This amount is calculated by subtracting the system-reserved and eviction-hard values from the overall capacity of the node. If the memory usage exceeds this amount, the node starts evicting pods.

3.5. Red Hat Single Sign-On

MTA delegates authentication and authorization to a Red Hat Single Sign-On (RHSSO) instance managed by the MTA operator. Aside from controlling the full lifecycle of the managed RHSSO instance, the MTA operator also manages the configuration of a dedicated realm that contains all the roles and permissions that MTA requires.

If an advanced configuration is required in the MTA managed RHSSO instance, such as adding a provider for User Federation or integrating identity providers, users can log into the RHSSO Admin Console through the /auth/admin subpath in the mta-ui route. The admin credentials to access the MTA managed RHSSO instance can be retrieved from the credential-mta-rhsso secret available in the namespace in which the user interface was installed.

A dedicated route for the MTA managed RHSSO instance can be created by setting the rhsso_external_access parameter to True in the Tackle CR that manages the MTA instance.

For more information, see Red Hat Single Sign-On features and concepts.

3.5.1. Roles and Permissions

The following table contains the roles and permissions (scopes) that MTA seeds the managed RHSSO instance with:

tackle-admin

Resource Name

Verbs

addons

delete
get
post
put

adoptionplans

post

applications

delete
get
post
put

applications.facts

delete
get
post
put

applications.tags

delete
get
post
put

applications.bucket

delete
get
post
put

assessments

delete
get
patch
post
put

businessservices

delete
get
post
put

dependencies

delete
get
post
put

identities

delete
get
post
put

imports

delete
get
post
put

jobfunctions

delete
get
post
put

proxies

delete
get
post
put

reviews

delete
get
post
put

settings

delete
get
post
put

stakeholdergroups

delete
get
post
put

stakeholders

delete
get
post
put

4. Configuring the instance environment

You can configure the following in Administration view:

General
Credentials
Repositories
HTTP and HTTPS proxy settings
Custom migration targets
Issue management

4.1. General

You can enable or disable the following options:

Reviewing applications without running an assessment first
Downloading HTML reports
Downloading CSV reports

4.2. Configuring credentials

You can configure the following types of credentials in Administration view:

Source control
Maven
Proxy

4.2.1. Configuring source control credentials

You can configure source control credentials in the Credentials view of the Migration Toolkit for Applications (MTA) user interface.

Procedure

In Administration view, click Credentials.
Click Create new.
Enter the following information:
- Name
- Description (Optional)
In the Type list, select Source Control.
In the User credentials list, select Credential Type and enter the requested information:
- Username/Password
  - Username
  - Password (hidden)
- SCM Private Key/Passphrase
  - SCM Private Key
  - Private Key Passphrase (hidden)
    
    Note
    
    Type-specific credential information such as keys and passphrases is either hidden or shown as [Encrypted].
Click Create.

MTA validates the input and creates a new credential. SCM keys must be parsed and checked for validity. If the validation fails, the following error message is displayed: “not a valid key/XML file”.

4.2.2. Configuring Maven credentials

You can configure new Maven credentials in the Credentials view of the Migration Toolkit for Applications (MTA) user interface.

Procedure

In Administration view, click Credentials.
Click Create new.
Enter the following information:
- Name
- Description (Optional)
In the Type list, select Maven Settings File.
Upload the settings file or paste its contents.
Click Create.

MTA validates the input and creates a new credential. The Maven settings.xml file must be parsed and checked for validity. If the validation fails, the following error message is displayed: “not a valid key/XML file”.

4.2.3. Configuring proxy credentials

You can configure proxy credentials in the Credentials view of the Migration Toolkit for Applications (MTA) user interface.

Procedure

In Administration view, click Credentials.
Click Create new.
Enter the following information:
- Name
- Description (Optional)
In the Type list, select Proxy.
Enter the following information.
- Username
- Password
  
  Note
  
  Type-specific credential information such as keys and passphrases is either hidden or shown as [Encrypted].
Click Create.

MTA validates the input and creates a new credential.

4.3. Configuring repositories

You can configure the following types of repositories in Administration view:

Git
Subversion
Maven

4.3.1. Configuring Git repositories

You can configure Git repositories in the Repositories view of the Migration Toolkit for Applications (MTA) user interface.

Procedure

In Administration view, click Repositories and then click Git.
Toggle the Consume insecure Git repositories switch to the right.

4.3.2. Configuring subversion repositories

You can configure subversion repositories in the Repositories view of the Migration Toolkit for Applications (MTA) user interface.

Procedure

In Administration view, click Repositories and then click Subversion.
Toggle the Consume insecure Subversion repositories switch to the right.

4.3.3. Configuring a Maven repository and reducing its size

You can use the MTA user interface to both configure a Maven repository and to reduce its size.

Configuring a Maven repository

You can configure a Maven repository in the Repositories view of the Migration Toolkit for Applications (MTA) user interface.

Note	If the `rwx_supported` configuration option of the Tackle CR is set to `false`, the Consume insecure artifact repositories switch is disabled and this procedure is not possible.

Procedure

In Administration view, click Repositories and then click Maven.
Toggle the Consume insecure artifact repositories switch to the right.

Reducing the size of a Maven repository

You can reduce the size of a Maven repository in the Repositories view of the Migration Toolkit for Applications (MTA) user interface.

Note	If the `rwx_supported` configuration option of the Tackle CR is set to `false`, both the Local artifact repository field and the Clear repository button are disabled and this procedure is not possible.

Procedure

In Administration view, click Repositories and then click Maven.
Click the Clear repository link.

Note

Depending on the size of the repository, the size change may not be evident despite the function working properly.

4.4. Configuring HTTP and HTTPS proxy settings

You can configure HTTP and HTTPS proxy settings with this management module.

Procedure

In the Administration view, click Proxy.
Toggle HTTP proxy or HTTPS proxy to enable the proxy connection.
Enter the following information:
- Proxy host
- Proxy port
Optional: Toggle HTTP proxy credentials or HTTPS proxy credentials to enable authentication.
Click Insert.

4.5. Seeding an instance

If you are a project architect, you can configure the instance’s key parameters in the Controls window, before migration. The parameters can be added and edited as needed. The following parameters define applications, individuals, teams, verticals or areas within an organization affected or participating in the migration:

Stakeholders
Stakeholder groups
Job functions
Business services
Tag categories
Tags

You can create and configure an instance in any order. However, the suggested order below is the most efficient for creating stakeholders and tags.

Stakeholders:

Create Stakeholder groups
Create Job functions
Create Stakeholders

Tags:

Create Tag categories
Create Tags

Stakeholders and defined by:

Email
Name
Job function
Stakeholder groups

4.5.1. Creating a new stakeholder group

There are no default stakeholder groups defined. You can create a new stakeholder group by following the procedure below.

Procedure

In Migration view, click Controls.
Click Stakeholder groups.
Click Create new.
Enter the following information:
- Name
- Description
- Member(s)
Click Create.

4.5.2. Creating a new job function

Migration Toolkit for Applications (MTA) uses the job function attribute to classify stakeholders and provides a list of default values that can be expanded.

You can create a new job function, which is not in the default list, by following the procedure below.

Procedure

In Migration view, click Controls.
Click Job functions.
Click Create new.
Enter a job function title in the Name text box.
Click Create.

4.5.3. Creating a new stakeholder

You can create a new migration project stakeholder by following the procedure below.

Procedure

In Migration view, click Controls.
Click Stakeholders.
Click Create new.
Enter the following information:
- Email
- Name
- Job function - custom functions can be created
- Stakeholder group
Click Create.

4.5.4. Creating a new business service

Migration Toolkit for Applications (MTA) uses the business service attribute to specify the departments within the organization that use the application and that are affected by the migration.

You can create a new business service by following the procedure below.

Procedure

In Migration view, click Controls.
Click Business services.
Click Create new.
Enter the following information:
- Name
- Description
- Owner
Click Create.

4.5.5. Creating new tag categories

Migration Toolkit for Applications (MTA) uses tags in multiple categories and provides a list of default values. You can create a new tag category by following the procedure below.

Procedure

In Migration view, click Controls.
Click Tags.
Click Create tag category.
Enter the following information:
- Name
- Rank - the order in which the tags appear on the applications
- Color
Click Create.

Creating new tags

You can create a new tag, which is not in the default list, by following the procedure below.

Procedure

In Migration view, click Controls.
Click Tags.
Click Create tag.
Enter the following information:
- Name
- Tag category
Click Create.

5. Creating and configuring a Jira connection

You can track application migrations by creating a Jira issue for each migration from within the MTA user interface. To be able to create Jira issues, you first need to do the following:

Create an MTA credential to authenticate to the API of the Jira instance that you create in the next step.
Create a Jira instance in MTA and establish a connection to that instance.

5.1. Configuring Jira credentials

To define a Jira instance in MTA and establish a connection to that instance, you must first create an MTA credential to authenticate to the Jira instance’s API.

Two types of credentials are available:

Basic auth - for Jira Cloud and a private Jira server or data center
Bearer Token - for a private Jira server or data center

To create an MTA credential, follow the procedure below.

Procedure

In Administration view, click Credentials.

The Credentials page opens.
Click Create new.
Enter the following information:
- Name
- Description (optional)
In the Type list, select Basic Auth (Jira) or Bearer Token (Jira):
- If you selected Basic Auth (Jira), proceed as follows:
  1. In the Email field, enter your email.
  2. In the Token field, depending on the specific Jira configuration, enter either your token generated on the Jira site or your Jira login password.
    
    Note
    
    To obtain a Jira token, you need to log in to the Jira site.
  3. Click Save.
    
    The new credential appears on the Credentials page.
- If you selected Bearer Token (Jira), proceed as follows:
  1. In the Token field, enter your token generated on the Jira site.
  2. Click Save.
    
    The new credential appears on the Credentials page.

You can edit a credential by clicking Edit.

To delete a credential, click Delete.

Note	You cannot delete a credential that has already been assigned to a Jira connection instance.

5.2. Creating and configuring a Jira connection

To create a Jira instance in MTA and establish a connection to that instance, follow the procedure below.

Procedure

In Administration view, under Issue Management, click Jira.

The Jira configuration page opens.
Click Create new.

The New instance window opens.

Enter the following information:

Name of the instance
URL of the web interface of your Jira account
Instance type - select either Jira Cloud or Jira Server/Data center from the list

Credentials - select from the list

Note

If the selected instance type is Jira Cloud, only Basic Auth credentials are displayed in the list.

If the selected instance type is Jira Server/Data center, both Basic Auth and Token Bearer credentials are displayed. Choose the type that is appropriate for the particular configuration of your Jira server or data center.

By default, a connection cannot be established with a server with an invalid certificate. To override this restriction, toggle the Enable insecure communication switch.
Click Create.

The new connection instance appears on the Jira configuration page.

Once the connection has been established and authorized, the status in the Connection column becomes Connected.

If the Connection status becomes Not connected, click the status to see the reason for the error.

The Jira configuration table has filtering by Name and URL and sorting by Instance name and URL.

Note	A Jira connection that was used for creating issues for a migration wave cannot be removed as long as the issues exist in Jira, even after the migration wave is deleted.

6. Assessing and analyzing applications

You can use the Migration Toolkit for Applications (MTA) user interface to both assess and to analyze applications.

Assessing applications refers to estimating the risks and costs involved in preparing applications for containerization, including time, personnel, and other factors. The results of an assessment can be used as the basis for discussions between stakeholders to determine which applications are good candidates for containerization, which require significant work, and which are not suitable for containerization.

Analyzing applications refers to using rules to determine which specific lines in an application must be modified before the application can be migrated or modernized.

6.1. Assessment module introduction

The Assessment module in Migration Toolkit for Applications (MTA) offers the following functionality for assessing and analyzing applications:

Assessment hub

The Assessment hub integrates tightly with the Application inventory.

Enhanced questionnaire capabilities

Previously, MTA supported a single, built-in questionnaire. MTA 7.0 not only includes that questionnaire, but also supports importing and exporting questionnaires. You can design custom questionnaires using YAML syntax, with a downloadable template provided. The syntax provides:

Conditional questions: The syntax supports excluding or including questions based on the application or archetype if a certain tag is present on the application or archetype.
Application auto-tagging according to answers: The syntax supports defining tags to be applied to applications if a certain answer has been provided.
Automated answers from tags in application archetypes

For more details, see Custom questionnaire.

The default questionnaire remains in MTA but can now be customized and saved. For more details, see Default questionnaire.

Multiple questionnaires

Assessment supports multiple questionnaires, relevant to one or more applications.

Archetypes

You can group applications with similar characteristics into archetypes. This allows you to assess multiple applications at once, rather having to assess each one separately. Each archetype has a shared taxonomy of tags, stakeholders, and stakeholder groups. All associated applications inherit assessment and review from the archetypes to which they belong. Automated answers are provided by tags in application archetypes.

Criteria tags are tags that the archetype requires to include an application as a member.
Archetype tags are tags that are applied to the group of applications that is known as an archetype. They are applied to the archetype entity.

For more details, see Working with Archetypes.

Copy assessment/review option

The Archetype feature makes the previous Copy assessment/review option redundant, so it has been removed from MTA 7.0.

6.2. Assessing applications

You can use the Migration Toolkit for Applications (MTA) to determine the risks involved in containerizing an application.

A built-in questionnaire is provided for assessing the risks involved in containerizing an application. For more details, see Default questionnaire.

Custom questionnaires can also be used. For more details, see Custom questionnaire.

Note

The procedure described below uses a built-in questionnaire for assessing the risks involved in containerizing an application. By default, this procedure is required before reviewing the application. However, you might want to skip this step and use your questionnaire instead. In that case, use the Skipping assessment option.

Procedure

In Migration view, click Application inventory.
Select the application you want to assess.
In the MTA user interface, select Migration view.
Click Application Inventory in the left menu bar. A list of all the available applications appears in the main pane.
Select an application from the list that appears in the main pane.
Click the Options menu at the right end of the row, and select Assess from the drop-down menu. .MTA application assessment
From the list of available questionnaires, click Take for one of the questionnaires.
Select Stakeholders and Stakeholder groups from the lists to track who contributed to the assessment for future reference.

Note

You can add Stakeholder Groups or Stakeholders on the Controls pane of Migration view. See section Seeding an instance for information how to add stakeholders and stakeholder groups.
Click Next.
Answer each question and then click Next.
Click Save and Review to view the assessment.
1. In the Review pane, click Proposed action to select the action to perform on the application.
2. Click Effort estimate to select the estimated effort to migrate the application.
3. Enter values for Business criticality and Work priority on a scale of 1 to 10.
4. Enter Comments of the assessment.
5. Scroll down to view the Assessment summary.
6. Click Submit review to save the assessment review.
The applications list reappears, showing that you assessed the application.
- An In-progess icon appears under the Assessment column for the application shows that MTA is assessing the application.
- A Completed icon appears under the Assessment column for the application shows that MTA has completed assessing the application.

Note	You can assess only one application at a time.

6.2.1. MTA questionnaire

Migration Toolkit for Applications (MTA) uses questionnaires for assessing the risks involved in containerizing an application. By default, this procedure is required prior to reviewing the application.

Through interaction with the questionnaire, and assessment process, the system is enriched with application knowledge which is exposed in a collection of reports. The reports provide information about applications, risks associated with migration, and generate an adoption plan informed by the prioritization, business criticality and dependencies of the applications submitted for assessment.

There is the option to use the Default questionnaire.

There is also the option to use the Custom questionnaire.

Assessment questionnaires

To view the available questionnaires, select the Administration profile.

Select the Assessment questionnaires menu option.

The Assessment questionnaires page provides the option to:

Import a questionnaire, for more details, see Importing questionnaires.
Export a questionnaire, for more details, see Exporting questionnaires.

Custom questionnaire

Migration Toolkit for Applications (MTA) allows you to import custom questionnaires using a custom YAML syntax for questionnaire definition.

The syntax supports:

Conditional questions
Automated answers based on tags present on the assessed application or archetype
Autotagging of applications based on answers

Questionnaire fields

name: Name of the questionnaire. name is required and must be unique for the entire MTA instance.
description: An optional short description of the questionnaire.
thresholds: Required the threshold definition for each risk category for the application or the archetype to be considered affected by that risk level. The higher risk level always takes precedence. For example, if yellow threshold is established in 30% and red in 5%, and the answers for an application or archetype to have 35% yellow and 6% red, the risk level for the application or archetype will be red.
- red: Required numeric percentage (example: 30 for 30%) of red answers the questionnaire can have until the risk level is considered red.
- yellow: Required numeric percentage (example: 30 for 30%) of yellow answers the questionnaire can have until the risk level is considered yellow.
- unknown: Required numeric percentage (example: 30 for 30%) of unknown answers the questionnaire can have until the risk level is considered unknown.
riskMessages: Required messages to be displayed in reports for each risk category. The risk_messages map is defined by the following fields:
- red: Required string message to display in reports for the red risk level.
- yellow: Required string message to display in reports for the yellow risk level.
- green: Required string message to display in reports for the green risk level.
- unknown: Required string message to display in reports for the unknown risk level.
sections: Required list of sections that the questionnaire will include.
- name: Name is the required string to be displayed for the section.
- order: Required int order in which the question should appear in the section.
- comment: Optional string to describe the section.
- questions: Required list of questions that belong to the section.
  - order: Required int order in which the question should appear in the section.
  - text: Required string of the question to be asked.
  - explanation: Optional string of additional explanations for the question.
  - includeFor: Optional list that defines a question should be displayed if any of the tags included in the list is present in the target application or archetype.
    
    category: Required string category of the target tag.
    
    tag: Required string for the target tag.
  - excludeFor: Optional list defines that a question should be skipped if any of the tags included in the list is present in the target application or archetype.
    
    category: Required string category of the target tag.
    
    tag: Required string for the target tag.
  - answers: Required list of answers for the given question.
    
    order: Required int order in which the question should appear in the section.
    
    text: Required string the actual answer for the question.
    
    risk: Required to be one of red, yellow, green, or unknown. The risk level of the current answer implied.
    
    rationale: Optional string explaining the justification for the answer being considered a risk.
    
    mitigation: Optional string for an explanation of the potential mitigation strategy for the risk implied by this answer.
    
    applyTags: Optional list that defines a list of tags to be automatically applied to the assessed application or archetype if this answer is selected.
    
    category: Required string category of the target tag.
    
    tag: Required string for the target tag.
    
    autoAnswerFor: Optional list defines a list of tags that will lead to this answer being automatically selected when the application or archetype is assessed.
    
    category: Required string category of the target tag.
    
    tag: Required string for the target tag.

Note	Anything marked as required is mandatory and must be completed. Otherwise, the YAML will not validate on upload. Each subsection defines a new struct/object in YAML. For example: `... name: Testing thresholds: red: 30 yellow: 45 unknown: 5 ...`

YAML template

A YAML template is provided to guide you through building your custom questionnaire.

The template is available for download by clicking Download YAML template on the Assessment questionnaires page.

To view the YAML template, click (here).

name: Uploadable Cloud Readiness Questionnaire Template
description: This questionnaire is an example template for assessing cloud readiness. It serves as a guide for users to create and customize their own questionnaire templates.
required: true
sections:
  - order: 1
    name: Application Technologies
    questions:
      - order: 1
        text: What is the main technology in your application?
        explanation: Identify the main framework or technology used in your application.
        includeFor:
          - category: Language
            tag: Java
        answers:
          - order: 1
            text: Quarkus
            risk: green
            rationale: Quarkus is a modern, container-friendly framework.
            mitigation: No mitigation needed.
            applyTags:
              - category: Runtime
                tag: Quarkus
            autoAnswerFor:
              - category: Runtime
                tag: Quarkus
          - order: 2
            text: Spring Boot
            risk: green
            rationale: Spring Boot is versatile and widely used.
            mitigation: Ensure container compatibility.
            applyTags:
              - category: Runtime
                tag: Spring Boot
            autoAnswerFor:
              - category: Runtime
                tag: Spring Boot
          - order: 3
            text: Legacy Monolithic Application
            risk: red
            rationale: Legacy monoliths are challenging for cloud adaptation.
            mitigation: Consider refactoring into microservices.
      - order: 2
        text: Does your application use a microservices architecture?
        explanation: Assess if the application is built using a microservices architecture.
        answers:
          - order: 1
            text: Yes
            risk: green
            rationale: Microservices are well-suited for cloud environments.
            mitigation: Continue monitoring service dependencies.
          - order: 2
            text: No
            risk: yellow
            rationale: Non-microservices architectures may face scalability issues.
            mitigation: Assess the feasibility of transitioning to microservices.
          - order: 3
            text: Unknown
            risk: unknown
            rationale: Lack of clarity on architecture can lead to unplanned issues.
            mitigation: Conduct an architectural review.

      - order: 3
        text: Is your application's data storage cloud-optimized?
        explanation: Evaluate if the data storage solution is optimized for cloud usage.
        includeFor:
          - category: Language
            tag: Java
        answers:
          - order: 1
            text: Cloud-Native Storage Solution
            risk: green
            rationale: Cloud-native solutions offer scalability and resilience.
            mitigation: Ensure regular backups and disaster recovery plans.
          - order: 2
            text: Traditional On-Premises Storage
            risk: red
            rationale: Traditional storage might not scale well in the cloud.
            mitigation: Explore cloud-based storage solutions.
          - order: 3
            text: Hybrid Storage Approach
            risk: yellow
            rationale: Hybrid solutions may have integration complexities.
            mitigation: Evaluate and optimize cloud integration points.
thresholds:
  red: 1
  yellow: 30
  unknown: 15
riskMessages:
  red: Requires deep changes in architecture or lifecycle
  yellow: Cloud friendly but needs minor changes
  green: Cloud Native
  unknown: More information needed

Conditional questions

The syntax supports excluding or including questions based on tags existing on the application or archetype. For example:

...
  questions:
    - order: 1
      text: What is the main JAVA framework used in your application?
      explanation: Identify the primary JAVA framework used in your application.
      includeFor:
        - category: Language
          tag: Java
...

Automated answers

Automated answers mean that answers are automatically selected when the application or archetype is assessed.

In the following example, if an application or archetype is tagged Runtime/Quarkus, then the Quarkus answer is automatically selected. While if an application or archetype is tagged Runtime/Spring Boot, then the 'Spring Boot' answer choice is automatically selected.

...
  text: What is the main technology in your application?
    explanation: Identify the main framework or technology used in your application.
      answers:
        - order: 1
          text: Quarkus
          risk: green
          autoAnswerFor:
            - category: Runtime
              tag: Quarkus
        - order: 2
          text: Spring Boot
          risk: green
          autoAnswerFor:
            - category: Runtime
              tag: Spring Boot
...

Autotagging of applications based on answers

Autotagging of applications based on answers means that tags are automatically applied to the assessed application or archetype, if this answer is selected.

The tags are transitive.

Each tag is defined by the following two required elements:

category: Category of the target tag (String).
tag: Definition for the target tag as (String).

In the following example, if the answer selected is Quarkus, then the Runtime/Quarkus tag is applied to the assessed application or archetype. While if the answer selected is Spring Boot, then the Runtime/Spring Boot tag is applied to the assessed application or archetype.

...
questions:
  - order: 1
    text: What is the main technology in your application?
    explanation: Identify the main framework or technology used in your application.
    answers:
      - order: 1
        text: Quarkus
        risk: green
        applyTags:
          - category: Runtime
            tag: Quarkus
      - order: 2
        text: Spring Boot
        risk: green
        applyTags:
          - category: Runtime
            tag: Spring Boot
...

Default questionnaire

The default questionnaire is named Legacy Pathfinder. Pathfinder is a questionnaire-based tool that evaluates the suitability of applications for modernization in containers on an enterprise Kubernetes platform.

Through interaction with the questionnaire and the review process, the system is enriched with application knowledge, which is exposed through a collection of reports. The reports provide information about applications suitability for Kubernetes, highlight associated risks, and generate an adoption plan informed by the applications' prioritization, business criticality and dependencies.

The default questionnaire can be exported to YAML.

To view the Legacy Pathfinder YAML, click (here).

name: Legacy Pathfinder
description: ''
sections:
  - order: 1
    name: Application details
    questions:
      - order: 1
        text: >-
          Does the application development team understand and actively develop
          the application?
        explanation: >-
          How much knowledge does the team have about the application's
          development or usage?
        answers:
          - order: 2
            text: >-
              Maintenance mode, no SME knowledge or adequate documentation
              available
            risk: red
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: >-
              Little knowledge, no development (example: third-party or
              commercial off-the-shelf application)
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: Maintenance mode, SME knowledge is available
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: Actively developed, SME knowledge is available
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: greenfield application
            risk: green
            rationale: ''
            mitigation: ''
      - order: 2
        text: How is the application supported in production?
        explanation: >-
          Does the team have sufficient knowledge to support the application in
          production?
        answers:
          - order: 3
            text: >-
              Multiple teams provide support using an established escalation
              model
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: >-
              External support provider with a ticket-driven escalation process;
              no inhouse support resources
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: >-
              Separate internal support team, separate from the development
              team, with little interaction between the teams
            risk: red
            rationale: ''
            mitigation: ''
          - order: 4
            text: >-
              SRE (Site Reliability Engineering) approach with a knowledgeable
              and experienced operations team
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: >-
              DevOps approach with the same team building the application and
              supporting it in production
            risk: green
            rationale: ''
            mitigation: ''
      - order: 3
        text: >-
          How much time passes from when code is committed until the application
          is deployed to production?
        explanation: What is the development latency?
        answers:
          - order: 3
            text: 2-6 months
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: Not tracked
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: More than 6 months
            risk: red
            rationale: ''
            mitigation: ''
          - order: 4
            text: 8-30 days
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: 1-7 days
            risk: green
            rationale: ''
            mitigation: ''
          - order: 6
            text: Less than 1 day
            risk: green
            rationale: ''
            mitigation: ''
      - order: 4
        text: How often is the application deployed to production?
        explanation: Deployment frequency
        answers:
          - order: 3
            text: Between once a month and once every 6 months
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: Not tracked
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: Less than once every 6 months
            risk: red
            rationale: ''
            mitigation: ''
          - order: 4
            text: Weekly
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: Daily
            risk: green
            rationale: ''
            mitigation: ''
          - order: 6
            text: Several times a day
            risk: green
            rationale: ''
            mitigation: ''
      - order: 5
        text: >-
          What is the application's mean time to recover (MTTR) from failure in
          a production environment?
        explanation: Average time for the application to recover from failure
        answers:
          - order: 5
            text: Less than 1 hour
            risk: green
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: Not tracked
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: 1-7 days
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 2
            text: 1 month or more
            risk: red
            rationale: ''
            mitigation: ''
          - order: 4
            text: 1-24 hours
            risk: green
            rationale: ''
            mitigation: ''
      - order: 6
        text: Does the application have legal and/or licensing requirements?
        explanation: >-
          Legal and licensing requirements must be assessed to determine their
          possible impact (cost, fault reporting) on the container platform
          hosting the application. Examples of legal requirements: isolated
          clusters, certifications, compliance with the Payment Card Industry
          Data Security Standard or the Health Insurance Portability and
          Accountability Act. Examples of licensing requirements: per server,
          per CPU.
        answers:
          - order: 1
            text: Multiple legal and licensing requirements
            risk: red
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 2
            text: 'Licensing requirements (examples: per server, per CPU)'
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: >-
              Legal requirements (examples: cluster isolation, hardware, PCI or
              HIPAA compliance)
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: None
            risk: green
            rationale: ''
            mitigation: ''
      - order: 7
        text: Which model best describes the application architecture?
        explanation: Describe the application architecture in simple terms.
        answers:
          - order: 3
            text: >-
              Complex monolith, strict runtime dependency startup order,
              non-resilient architecture
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 5
            text: Independently deployable components
            risk: green
            rationale: ''
            mitigation: ''
          - order: 1
            text: >-
              Massive monolith (high memory and CPU usage), singleton
              deployment, vertical scale only
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 2
            text: >-
              Massive monolith (high memory and CPU usage), non-singleton
              deployment, complex to scale horizontally
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: 'Resilient monolith (examples: retries, circuit breakers)'
            risk: green
            rationale: ''
            mitigation: ''
  - order: 2
    name: Application dependencies
    questions:
      - order: 1
        text: Does the application require specific hardware?
        explanation: >-
          OpenShift Container Platform runs only on x86, IBM Power, or IBM Z
          systems
        answers:
          - order: 3
            text: 'Requires specific computer hardware (examples: GPUs, RAM, HDDs)'
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: Requires CPU that is not supported by red Hat
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: 'Requires custom or legacy hardware (example: USB device)'
            risk: red
            rationale: ''
            mitigation: ''
          - order: 4
            text: Requires CPU that is supported by red Hat
            risk: green
            rationale: ''
            mitigation: ''
      - order: 2
        text: What operating system does the application require?
        explanation: >-
          Only Linux and certain Microsoft Windows versions are supported in
          containers. Check the latest versions and requirements.
        answers:
          - order: 4
            text: Microsoft Windows
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: >-
              Operating system that is not compatible with OpenShift Container
              Platform (examples: OS X, AIX, Unix, Solaris)
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: Linux with custom kernel drivers or a specific kernel version
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: 'Linux with custom capabilities (examples: seccomp, root access)'
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 5
            text: Standard Linux distribution
            risk: green
            rationale: ''
            mitigation: ''
      - order: 3
        text: >-
          Does the vendor provide support for a third-party component running in
          a container?
        explanation: Will the vendor support a component if you run it in a container?
        answers:
          - order: 2
            text: No vendor support for containers
            risk: red
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: Not recommended to run the component in a container
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: >-
              Vendor supports containers but with limitations (examples:
              functionality is restricted, component has not been tested)
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: >-
              Vendor supports their application running in containers but you
              must build your own images
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 5
            text: Vendor fully supports containers, provides certified images
            risk: green
            rationale: ''
            mitigation: ''
          - order: 6
            text: No third-party components required
            risk: green
            rationale: ''
            mitigation: ''
      - order: 4
        text: Incoming/northbound dependencies
        explanation: Systems or applications that call the application
        answers:
          - order: 3
            text: >-
              Many dependencies exist, can be changed because the systems are
              internally managed
            risk: green
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 4
            text: Internal dependencies only
            risk: green
            rationale: ''
            mitigation: ''
          - order: 1
            text: >-
              Dependencies are difficult or expensive to change because they are
              legacy or third-party
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: >-
              Many dependencies exist, can be changed but the process is
              expensive and time-consuming
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 5
            text: No incoming/northbound dependencies
            risk: green
            rationale: ''
            mitigation: ''
      - order: 5
        text: Outgoing/southbound dependencies
        explanation: Systems or applications that the application calls
        answers:
          - order: 3
            text: Application not ready until dependencies are verified available
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: >-
              Dependency availability only verified when application is
              processing traffic
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: Dependencies require a complex and strict startup order
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: Limited processing available if dependencies are unavailable
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: No outgoing/southbound dependencies
            risk: green
            rationale: ''
            mitigation: ''
  - order: 3
    name: Application architecture
    questions:
      - order: 1
        text: >-
          How resilient is the application? How well does it recover from
          outages and restarts?
        explanation: >-
          If the application or one of its dependencies fails, how does the
          application recover from failure? Is manual intervention required?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: >-
              Application cannot be restarted cleanly after failure, requires
              manual intervention
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: >-
              Application fails when a soutbound dependency is unavailable and
              does not recover automatically
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: >-
              Application functionality is limited when a dependency is
              unavailable but recovers when the dependency is available
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: >-
              Application employs resilient architecture patterns (examples:
              circuit breakers, retry mechanisms)
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: >-
              Application containers are randomly terminated to test resiliency;
              chaos engineering principles are followed
            risk: green
            rationale: ''
            mitigation: ''
      - order: 2
        text: How does the external world communicate with the application?
        explanation: >-
          What protocols do external clients use to communicate with the
          application?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: 'Non-TCP/IP protocols (examples: serial, IPX, AppleTalk)'
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: TCP/IP, with host name or IP address encapsulated in the payload
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: 'TCP/UDP without host addressing (example: SSH)'
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: TCP/UDP encapsulated, using TLS with SNI header
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: HTTP/HTTPS
            risk: green
            rationale: ''
            mitigation: ''
      - order: 3
        text: How does the application manage its internal state?
        explanation: >-
          If the application must manage or retain an internal state, how is
          this done?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 3
            text: State maintained in non-shared, non-ephemeral storage
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 1
            text: Application components use shared memory within a pod
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 2
            text: >-
              State is managed externally by another product (examples:
              Zookeeper or red Hat Data Grid)
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: Disk shared between application instances
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: Stateless or ephemeral container storage
            risk: green
            rationale: ''
            mitigation: ''
      - order: 4
        text: How does the application handle service discovery?
        explanation: How does the application discover services?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: >-
              Uses technologies that are not compatible with Kubernetes
              (examples: hardcoded IP addresses, custom cluster manager)
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: >-
              Requires an application or cluster restart to discover new service
              instances
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: >-
              Uses technologies that are compatible with Kubernetes but require
              specific libraries or services (examples: HashiCorp Consul,
              Netflix Eureka)
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: Uses Kubernetes DNS name resolution
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: Does not require service discovery
            risk: green
            rationale: ''
            mitigation: ''
      - order: 5
        text: How is the application clustering managed?
        explanation: >-
          Does the application require clusters? If so, how is clustering
          managed?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: 'Manually configured clustering (example: static clusters)'
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: Managed by an external off-PaaS cluster manager
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: >-
              Managed by an application runtime that is compatible with
              Kubernetes
            risk: green
            rationale: ''
            mitigation: ''
          - order: 4
            text: No cluster management required
            risk: green
            rationale: ''
            mitigation: ''
  - order: 4
    name: Application observability
    questions:
      - order: 1
        text: How does the application use logging and how are the logs accessed?
        explanation: How the application logs are accessed
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: Logs are unavailable or are internal with no way to export them
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: >-
              Logs are in a custom binary format, exposed with non-standard
              protocols
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: Logs are exposed using syslog
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: Logs are written to a file system, sometimes as multiple files
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 5
            text: 'Logs are forwarded to an external logging system (example: Splunk)'
            risk: green
            rationale: ''
            mitigation: ''
          - order: 6
            text: 'Logs are configurable (example: can be sent to stdout)'
            risk: green
            rationale: ''
            mitigation: ''
      - order: 2
        text: Does the application provide metrics?
        explanation: >-
          Are application metrics available, if necessary (example: OpenShift
          Container Platform collects CPU and memory metrics)?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: No metrics available
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 2
            text: Metrics collected but not exposed externally
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 3
            text: 'Metrics exposed using binary protocols (examples: SNMP, JMX)'
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: >-
              Metrics exposed using a third-party solution (examples: Dynatrace,
              AppDynamics)
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: >-
              Metrics collected and exposed with built-in Prometheus endpoint
              support
            risk: green
            rationale: ''
            mitigation: ''
      - order: 3
        text: >-
          How easy is it to determine the application's health and readiness to
          handle traffic?
        explanation: >-
          How do we determine an application's health (liveness) and readiness
          to handle traffic?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: No health or readiness query functionality available
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: Basic application health requires semi-complex scripting
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: Dedicated, independent liveness and readiness endpoints
            risk: green
            rationale: ''
            mitigation: ''
          - order: 2
            text: Monitored and managed by a custom watchdog process
            risk: red
            rationale: ''
            mitigation: ''
          - order: 5
            text: Health is verified by probes running synthetic transactions
            risk: green
            rationale: ''
            mitigation: ''
      - order: 4
        text: What best describes the application's runtime characteristics?
        explanation: >-
          How would the profile of an application appear during runtime
          (examples: graphs showing CPU and memory usage, traffic patterns,
          latency)? What are the implications for a serverless application?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: >-
              Deterministic and predictable real-time execution or control
              requirements
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: >-
              Sensitive to latency (examples: voice applications, high frequency
              trading applications)
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 3
            text: Constant traffic with a broad range of CPU and memory usage
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: Intermittent traffic with predictable CPU and memory usage
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: Constant traffic with predictable CPU and memory usage
            risk: green
            rationale: ''
            mitigation: ''
      - order: 5
        text: How long does it take the application to be ready to handle traffic?
        explanation: How long the application takes to boot
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: More than 5 minutes
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: 2-5 minutes
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 3
            text: 1-2 minutes
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: 10-60 seconds
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: Less than 10 seconds
            risk: green
            rationale: ''
            mitigation: ''
  - order: 5
    name: Application cross-cutting concerns
    questions:
      - order: 1
        text: How is the application tested?
        explanation: >-
          Is the application is tested? Is it easy to test (example: automated
          testing)? Is it tested in production?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: No testing or minimal manual testing only
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: Minimal automated testing, focused on the user interface
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 3
            text: >-
              Some automated unit and regression testing, basic CI/CD pipeline
              testing; modern test practices are not followed
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: >-
              Highly repeatable automated testing (examples: unit, integration,
              smoke tests) before deploying to production; modern test practices
              are followed
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: >-
              Chaos engineering approach, constant testing in production
              (example: A/B testing + experimentation)
            risk: green
            rationale: ''
            mitigation: ''
      - order: 2
        text: How is the application configured?
        explanation: >-
          How is the application configured? Is the configuration method
          appropriate for a container? External servers are runtime
          dependencies.
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: >-
              Configuration files compiled during installation and configured
              using a user interface
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: >-
              Configuration files are stored externally (example: in a database)
              and accessed using specific environment keys (examples: host name,
              IP address)
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: Multiple configuration files in multiple file system locations
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: >-
              Configuration files built into the application and enabled using
              system properties at runtime
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 5
            text: >-
              Configuration retrieved from an external server (examples: Spring
              Cloud Config Server, HashiCorp Consul)
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 6
            text: >-
              Configuration loaded from files in a single configurable location;
              environment variables used
            risk: green
            rationale: ''
            mitigation: ''
      - order: 4
        text: How is the application deployed?
        explanation: >-
          How the application is deployed and whether the deployment process is
          suitable for a container platform
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 3
            text: Simple automated deployment scripts
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 1
            text: Manual deployment using a user interface
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: Manual deployment with some automation
            risk: red
            rationale: ''
            mitigation: ''
          - order: 4
            text: >-
              Automated deployment with manual intervention or complex promotion
              through pipeline stages
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 5
            text: >-
              Automated deployment with a full CI/CD pipeline, minimal
              intervention for promotion through pipeline stages
            risk: green
            rationale: ''
            mitigation: ''
          - order: 6
            text: Fully automated (GitOps), blue-green, or canary deployment
            risk: green
            rationale: ''
            mitigation: ''
      - order: 5
        text: Where is the application deployed?
        explanation: Where does the application run?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: Bare metal server
            risk: green
            rationale: ''
            mitigation: ''
          - order: 2
            text: 'Virtual machine (examples: red Hat Virtualization, VMware)'
            risk: green
            rationale: ''
            mitigation: ''
          - order: 3
            text: 'Private cloud (example: red Hat OpenStack Platform)'
            risk: green
            rationale: ''
            mitigation: ''
          - order: 4
            text: >-
              Public cloud provider (examples: Amazon Web Services, Microsoft
              Azure, Google Cloud Platform)
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: >-
              Platform as a service (examples: Heroku, Force.com, Google App
              Engine)
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 7
            text: Other. Specify in the comments field
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 6
            text: Hybrid cloud (public and private cloud providers)
            risk: green
            rationale: ''
            mitigation: ''
      - order: 6
        text: How mature is the containerization process, if any?
        explanation: If the team has used containers in the past, how was it done?
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: Application runs in a container on a laptop or desktop
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: Some experience with containers but not yet fully defined
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: >-
              Proficient with containers and container platforms (examples:
              Swarm, Kubernetes)
            risk: green
            rationale: ''
            mitigation: ''
          - order: 5
            text: Application containerization has not yet been attempted
            risk: green
            rationale: ''
            mitigation: ''
      - order: 3
        text: How does the application acquire security keys or certificates?
        explanation: >-
          How does the application retrieve credentials, keys, or certificates?
          External systems are runtime dependencies.
        answers:
          - order: 0
            text: unknown
            risk: unknown
            rationale: ''
            mitigation: ''
          - order: 1
            text: Hardware security modules or encryption devices
            risk: red
            rationale: ''
            mitigation: ''
          - order: 2
            text: >-
              Keys/certificates bound to IP addresses and generated at runtime
              for each application instance
            risk: red
            rationale: ''
            mitigation: ''
          - order: 3
            text: Keys/certificates compiled into the application
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 4
            text: Loaded from a shared disk
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 5
            text: >-
              Retrieved from an external server (examples: HashiCorp Vault,
              CyberArk Conjur)
            risk: yellow
            rationale: ''
            mitigation: ''
          - order: 6
            text: Loaded from files
            risk: green
            rationale: ''
            mitigation: ''
          - order: 7
            text: Not required
            risk: green
            rationale: ''
            mitigation: ''
thresholds:
  red: 5
  yellow: 30
  unknown: 5
riskMessages:
  red: ''
  yellow: ''
  green: ''
  unknown: ''
builtin: true

Exporting a questionnaire

Procedure

Export a questionnaire:

In the Administration view, select Assessment questionnaires.
Select the questionnaire.
Click the Options menu .
Select Export.
Select the location of the download.
Click Save.

Importing questionnaire

Procedure

In the Administration view, select Assessment questionnaires.
To import a questionnaire, click Import questionnaire.
Click Upload.
Navigate to the location of your questionnaire, and click Open.
Click Import.

Warning

UNIQUE constraint failed: Questionnaire.Name

The name of the imported questionnaire must be unique. If the name, which is defined in the YAML syntax (name:<name of questionnaire>), is duplicated, the import will fail and an error is returned UNIQUE constraint failed: Questionnaire.Name. The name of the YAML file is irrelevant.

Viewing a questionnaire

Procedure

To view a questionnaire:

In the Administration view, select Assessment questionnaires.
Click the Options menu .
Select View.
The question contained in the questionnaire are displayed, with the answer choices and weigth displayed in the drop-down option.

Deleting a questionnaire

You can delete a questionnaire.

Important

Deleting a questionnaire

Deleting a questionnaire deletes its answers for all applications that use it in all archetypes.

Procedure

In the Administration view, select Assessment questionnaires.
Select the questionnaire.
Click the Options menu .
Select Delete.
Confirm delete by clicking on the Name of the questionnaire.

Note	The Legacy Pathfinder questionnaire cannot be deleted.

6.2.2. Assessment Module

The assessment process for applications that are to be migrated in Migration Toolkit for Applications (MTA) has been separated from other features.

In the MTA user interface, the Assessment Module appears in a separate menu item. Selecting the item shows the currently saved applications.

The MTA assesses applications that are to be migrated, according to a set of questions relevant to the application, such as dependencies.

Creating a new application

You can create a new application in MTA.

Prerequisites

Be logged on to an MTA server.

Procedure

In the MTA user interface, select the Migration working mode.
Click Application Inventory in the left menu bar.
Click Create new. The New application dialog appears.
In the form, supply the following information:
1. Name: unique name for the new application
2. Description: short description of the application (optional)
3. Business service: purpose of the application (optional)
4. Tags: software tags that characterize the application
5. Owner: registered software owner from drop-down list (optional)
6. Contributors: contributors from drop-down list (optional)
7. Comments: relevant comments on the migrated application
Click Source code and enter the following fields.
1. Repository type: Git or Subversion
2. Source Repository: URL of the repository where the software code is saved
3. Branch: application code branch in the repository
4. Root path: [get info] (optional/mandatory)
Click Binary and enter the following fields.
1. Group: [get info] (optional/mandatory)
2. Artifact: [get info] (optional/mandatory)
3. Version: software version of the application
4. Packaging: [get info] (optional/mandatory)
Click Create. The dialog closes and the new application appears in the list of defined applications.

Opening an existing application

This procedure describes how to open and edit an application that has already been defined in MTA.

Prerequisites

Be logged on to an MTA server.

Procedure

In the MTA user interface, select the Migration working mode.
Click Application Inventory in the left menu bar. A list of all the available applications appears in the main pane.
Click edit to open the application settings, and review the application settings. See procedure above for a list of application settings.

Running an assessment on an application

Prerequisites

Be logged on to an MTA server.

Procedure

In the MTA user interface, select the Migration working mode.
Click Application Inventory in the left menu bar. A list of all the available applications appears in the main pane.
Select an application from the list that appears in the main pane, click the Options menu at the end of the row, and select Assess from the drop-down menu.
Assessment Action appears in the main pane. Select one of the questionnaires and click Take.
The main pane shows the Application assessment questions.
1. The left edge lists the questions.
2. The main area of the pane shows the specific fields for the question.
Enter the question into the field or select from a list.
Click Next to continue to the next question, and repeat the step above.
In the last question, enter information and click Save to start the assessment, or Save and review to review the assessment.
- If you selected Save, then the main pane returns to the list of questionnaires in step 4 above.
- If you selected Save and review, then the questionnaire Review appears in the main pane. See Reviewing and application.

6.3. Tagging an application

You can attach various tags to the application that you are going to analyze. The tags allow classifying applications in multiple dimensions.

Tagging can be either automatic or manual.

6.3.1. Manual tagging

You can tag an application manually, both before or after you run an analysis.

Procedure

In Migration view, click Application inventory.
Click the Analysis tab.
In the row of the required application, click the pen icon.
The Update application window opens.
Select the desired tags from the Select a tag(s) drop-down list.
Click Save.

6.3.2. Automatic tagging

MTA translates the technology stack information that the analysis module collects into tags and automatically adds the tags to the application. Automatic tagging is especially useful when dealing with large portfolios of applications.

Automatic tagging of applications is enabled by default. You can disable it by unselecting the Enable automated tagging checkbox in the Advanced section of the Analysis configuration wizard.

Note	To tag an application automatically, make sure that the Enable automated tagging checkbox is selected before you run an analysis of the application.

6.3.3. Viewing the tags of an application

You can view the tags attached to a particular application.

Note	You can view the tags that were attached automatically only after you have run an analysis of the application.

Procedure

In Migration view, click Application inventory.
Click the Analysis tab.
Click the name of the required application.
A side drawer opens. In the side drawer, click the Tags tab.

You can see the tags attached to the application.

The tags can be filtered by source and tag category. The sources are Analysis and Manual.

The categories are displayed in a drop-down list, for example, HTTP, MVC, Web, Observability, Persistence, Application Type, Data Center.

6.3.4. Creating tags

You can create custom tags for applications that MTA assesses or analyzes.

Procedure

In Migration view, click Controls.
Click the Tags tab.
Click Create tag, which opens a dialog.
In the Name field enter a unique name for the tag.
Click the Tag category field and select the category tag to associate with the tag.
Click Create.

6.3.5. Editing tags

You can edit defined tags.

Procedure

In Migration view, click Controls.
Click the Tags tab. A list of tag categories appears in the main pane.
Click the arrow to the left of the category name, opening a list of tags in the category.
Select Edit from the drop-down menu, opening a dialog.
Edit the tag’s name in the Name field.
Click the Tag category field and and select the category tag to associate with the tag.
Click Save.

6.3.6. Editing tag categories

You can edit defined tag categories.

Procedure

In Migration view, click Controls.
Click the Tags tab.
Select a defined tag category and click Edit to the right of the tag category.
Edit the tag category’s name in the Name field.
Edit the category’s Rank value.
Click the Color field and select a color for the tag category.
Click Save.

6.4. Reviewing an analysis report

An MTA analysis report contains a variety of sections, including a listing of the technologies used by the application, the dependencies of the application, and the lines of code that must be changed to successfully migrate or modernize the application.

For more information on the contents of an MTA analysis report, see the Reviewing the reports.

Procedure

In Migration view, click Reports.
In the Current landscape pane, select All questionnaires or a single questionnaire from the drop-down list to see an overview of the risk distribution (High, Medium, Low, Unassessed/Unknown).
In the Identified risks pane, filter the report results by selecting a component from the drop-down list (Questionnaire, Section, Question, Answer, Risk), and select an item from the resulting filter drop down list.
You can also sort the results by clicking a column heading (Questionnaire, Section, Question, Answer, Risk).

6.5. Reviewing applications

You can use the Migration Toolkit for Applications (MTA) user interface to determine the migration strategy and work priority for each application.

Procedure

In Migration view, click Application inventory.
Select the application you want to review.

Only one application can be reviewed at a time.

Click the Options menu at the right end of the row, and select Review from the drop-down list. The application Review parameters appear in the main pane.
Click Proposed action and select the action.
Click Effort estimate and set the level of effort required to perform the assessment with the selected questionnaire.
In the Business criticality field enter how critical the application is to the business.
In the Work priority field enter the application’s priority.
If you have any comments for the questionnaire, then enter them in the Comments field.
Click Submit review.

The fields from Review are now populated on the Application details page.

6.6. Application review tab

You can view the review details of any application on the Application inventory page.

Procedure

In Migration view, click Application inventory.
Select an application, opening a Details pane at the right of the window.
Click the Reviews tab in the pane. The application information appears, showing the application’s questions.

6.7. Working with Archetypes

Migration Toolkit for Applications (MTA) includes archetypes that group applications that are assessed for migration, according to common characteristics. These application groups, or archetypes, enable MTA to apply questionnaires populated with questions that apply to common application characteristics.

Application archetypes are defined by criteria tags and the application taxonomy. Each archetype selects the how the assessment module assesses the applications according to the charecteristics defined in that archetype. If the tags of an application match the criteria tags of an archetype, then the application is associated with the archetype.

Creation of an archetype is defined by a series of tags, stakeholders, and stakeholder groups.

Criteria tags are tags that the archetype requires to include an application as a member.

Note	Criteria tags do not partially match an application For example, if application a only has tag a, but the archetype a criteria tags include tag a AND tag b, then application a will not be a member of archetype a.

Archetype tags are tags that are applied to the group of applications that is known as an archetype. They are applied to the archetype entity.

6.7.1. Defining an archetype

Open the MTA web console.
In the left menu, click Archetypes and then click Create new archetype.
In the form that opens, enter the following information for the new archetype:
1. Name: Name of the new archetype. (mandatory)
2. Description: Description of the new archetype. (optional)
3. Criteria Tags: Tags that associate the assessed applications with the archetype. (mandatory). If criteria tags are updated, the process to calculate the applications, with which the archetype is associated with, is triggered again.
4. Archetype Tags: That the archetype assesses in the application. (mandatory)
5. Stakeholder(s): Specific stakeholders involved in the application development and migration. (optional)
6. Stakeholders Group(s): Groups of stakeholders involved in the application development and migration. (optional)
Click Create. The new archetype appears in the list.

After you create an archetype, every application in the inventory whose tags match those of the archetype is automatically associated to that archetype.

Archetype inheritance

Inheritance is the default, meaning that all the associated applications inherit assessment and review from the archetype groups to which they belong. However, inheritance can be overridden. Inherited assessment and review is overridden for an application by completing an individual assessment and review.

Archetype assessment

An archetype is considered to have been assessed when all required questionnaires have been answered.

An archetype is considered reviewed when it has been reviewed once, even though multiple questionnaires have been marked as required.

If an application is associated with archetypes, the application is considered assessed when all associated archetypes have been assessed.

6.7.2. Deleting an archetype

Deleting an archetype deletes any associated assessment. All associated applications move to an Unassessed state.

6.8. Configuring and running an application analysis

You can analyze more than one application at a time against more than one transformation target in the same analysis.

Procedure

In Migration view, click Application inventory.
Click the Analysis tab.
Select the applications you want to analyze.
Review the credentials assigned to the application.
Click Analyze.
Select the Analysis mode from the list. Valid options are:
- Binary.
- Source code.
- Source code and dependencies.
- Upload a local binary. This option only appears if you are analyzing a single application.
If you choose Upload a local binary, a window opens and you are prompted to Upload a local binary. Either drag and drop a file into the area provided or click Upload and then select the file to upload.
Click Next.
Select one or more target options for the analysis:
- Application server migration to:
  - JBoss EAP 7
  - JBoss EAP 8
- Containerization
- Quarkus
- OracleJDK to OpenJDK
- OpenJDK - upgrades to one of the following JDK versions:
  - OpenJDK 11
  - OpenJDK 17
  - OpenJDK 21
- Linux - ensures there are no Microsoft Windows paths hard-coded into your applications
- Jakarta EE 9 - for migrating from Java EE 8 to Jakarta EE 9
- Spring Boot on Red Hat Runtimes
- Open Liberty
- Camel - for migrating from Apache Camel 2 to Apache Camel 3 and from Apache Camel 3 to Apache Camel 4
- Azure
  - Azure App Service
  - Azure Kubernetes Service
Click Next.
Select one of the following Scope options to better focus the analysis:
- Application and internal dependencies only.
- Application and all dependencies, including known Open Source libraries.
- Select the list of packages to be analyzed manually. If you choose this option, type the file name and click Add.
- Exclude packages. If you choose this option, type the name of the package name and click Add.
Click Next.
In Advanced, you can attach additional custom rules to the analysis. Select Manual or Repository.

Note

Attaching custom rules is optional if you have already attached a migration target to the analysis. If you have not attached any migration target, you must attach rules.
- In Manual mode, click Add Rules. Then either drag and drop the relevant files or select them from their directory and click Add.
- In Repository mode, you can add rule files from a Git or Subversion repository.

Set any of the following options, if needed:

Target
Source(s)
Excluded rules tags: Rules with these tags are not processed. Add or delete as needed.
Enable transaction report: Select the checkbox to generate a DIVA report that displays the call stack, which executes operations on relational database tables.

Enable automated tagging: Select the checkbox to automatically attach tags to the application. This checkbox is selected by default.

Note

The Transactions report is a Technology Preview feature only. Technology Preview features are not supported with Red Hat production service level agreements (SLAs) and might not be functionally complete. Red Hat does not recommend using them in production. These features provide early access to upcoming product features, enabling customers to test functionality and provide feedback during the development process.

Note	Automatically attached tags are displayed only after you run the analysis. You can attach tags to the application manually, instead of enabling automated tagging or in addition to it.

Note	Analysis engines use standard rules for a comprehensive set of migration targets, but if the target is not included or is a customized framework, custom rules can be added. Only manually uploaded custom rule files are validated.

Click Next.
In Review, verify the analysis parameters.

Click Run.

Analysis status is Scheduled as MTA downloads the image for the container to execute. When the image is downloaded, the status changes to In-progress.

Note	Analysis takes minutes to hours to run depending on the size of the application and the capacity and resources of the cluster.

Tip

MTA relies on Kubernetes scheduling capabilities to determine how many analyzer instances are created based on cluster capacity. If several applications are selected for analysis, by default, only one analyzer can be provisioned at a time. With more cluster capacity, more analysis processes can be executed in parallel.

When analysis is complete, you can click the Report link to see the results of the analysis.

6.8.1. Viewing analysis details

You can view the details of an analysis by clicking the Options menu kebab and selecting Analysis details. The details are displayed in the Analysis details for customers window. You can choose either YAML or JSON format.

Note	You can view the details of an analysis only after you start running the analysis. If the status of an analysis is Not started, the Analysis details option is disabled.

6.8.2. Downloading an analysis report

For your convenience, you can download analysis reports. By default, this option is disabled, but you can enable it as described below.

Procedure

In Administration view, click General.
Toggle the Allow reports to be downloaded after running an analysis. switch.
Go to Migration view and click Application inventory.
Open the page of the application for which you ran an analysis.
Click Reports.
Click the HTML or YAML link.

Clicking the HTML link downloads a compressed file named analysis-report-app-<application_name>.tar. Extracting the file creates a folder with the same name as the application.

Clicking the YAML link downloads an uncompressed file named analysis-report-app-<application_name>.yaml.

6.9. Creating custom migration targets

Architects or users with admin permissions can create and maintain custom rulesets associated with custom migration targets. Architects can upload custom rule files and assign them to various custom migration targets. The custom migration targets are then available for selecting in the analysis configuration wizard.

Using ready-made custom migration targets makes unnecessary the cumbersome task of configuring custom rules for each analysis run. This simplifies analysis configuration and execution for non-admin users or third-party developers and makes using the MTA tool easier and more straightforward.

Prerequisites

You must be logged in as a user with admin permissions.

Procedure

In Administration view, click Custom migration targets.
Click Create new.
Fill in the name and description of the target.
In the Image section, upload an image file for the target’s icon. The file can be in either PNG or JPEG format, up to 1 MB. If you do not upload any file, a default icon is used.
In the Custom rules section, select either Upload manually or Retrieve from a repository.
- If you have selected Upload manually, upload or drag and drop the required rule files from your local drive.
- If you have selected Retrieve from a repository, proceed as follows:
  1. Choose Git or Subversion.
  2. Fill in Source repository, Branch and Root path.
  3. If the repository requires credentials, enter them in the Associated credentials field.
Click Create.

The new migration target appears on the Custom migration targets page. It can now be used by non-admin users in Migration view.

7. Working with Applications

You can use the Migration Toolkit for Applications (MTA) user interface to do the following:

Add applications
Assign application credentials
Import a list of applications
Download a CSV template for importing application lists

7.1. Application attributes

You can add applications to the Migration Toolkit for Applications (MTA) user interface manually or by importing a list of applications.

MTA user interface applications have the following attributes:

Name (free text)
Description (optional; free text)
Business service (optional; chosen from a list)
Tags (optional; chosen from a list)
Owner (optional; chosen from a list)
Contributors (optional; chosen from a list)
Source code (path entered by user)
Binary (path entered by user)

7.2. Adding applications

You can add an application to the Application Inventory for assessment and analysis.

Tip	Before creating an application, it is helpful to set up business services, check tags and tag categories, and create additions as needed.

Procedure

In Migration view, click Application Inventory.
Click Create new.
Under Basic information enter the following information or choose from a list:
- Name
- Description (optional)
- Business service (optional)
- Manual tags (optional; one or more)
- Owner (optional)
- Contributors (optional; one or more)
- Comments (optional)
Click the arrow to the left of Source Code.
Enter the following information or choose from a list:
- Repository type - select Git or Subversion
- Source repository
- Branch
- Root path
Click the arrow to the left of Binary.
Enter the following information:
- Group
- Artifact
- Version
- Packaging
Click Create.

7.3. Editing an application

You can edit an existing application in the Application Inventory and the re-run an assessment or an analysis.

Prerequisites

Be logged on to an MTA server.

Procedure

In Migration view, click Application Inventory.

In the MTA user interface, select the Migration working mode.
Click Application Inventory in the left menu bar. A list of all the available applications appears in the main pane.
Click Edit to open the application settings, and review the application settings. See procedure above for a list of application settings.
If you changed any application settings, then click Save.

7.4. Assigning application credentials

You can assign credentials to one or more applications.

Procedure

In Migration view, click Application inventory.
Click the Analysis tab.
Click the Options menu to the right of Analyze and select Manage credentials.
Select one credential each from the Source credentials list and from the Maven settings list.
Click Save.

7.5. Importing a list of applications

You can import a .csv file containing a list of applications and their attributes to the Migration Toolkit for Applications (MTA) user interface.

Note	Importing a list of applications only adds applications, it does not overwrite any existing ones.

Procedure

Review the import file to ensure it contains all the required information in the required format.
In Migration view, click Application Inventory.
Click the Options menu to the right of Review.
Click Import.
Browse to the desired file and click Open.
Optional: Select Enable automatic creation of missing entities. By default, this option is selected.
Verify the import has completed and check the number of rows accepted or rejected.

Review the imported applications by clicking the arrow to the left of the checkbox.

Important

Rows accepted may not match the number of applications in the Application inventory list because some rows are dependencies. To verify, check the Record Type column of the CSV file for applications defined as 1 and dependencies as 2.

7.6. Downloading a CSV template for importing application lists

You can download a CSV template for importing application lists.

Procedure

In Migration view, click Application inventory.
Click the Options menu to the right of Review.
Click Manage imports to open the Application imports page.
Click the Options menu to the right of Import and then click Download CSV template.

7.7. Creating migration waves

Creating a migration wave is a way to group applications that you want to migrate on a given schedule.

In addition, a migration wave enables you to track each migration by exporting a list of the wave’s applications to the Jira issue management system. This automatically creates a separate Jira issue for each application of the migration wave.

Procedure

In Migration view, click Migration waves.
Click Create new.

The New migration wave window opens.
Enter the following information or select from drop-down lists:
- Name (optional; if not given, you can use the start and end dates to identify migration waves)
- Potential start date; it must be later than the current date
- Potential end date; it must be later than the start date
- Stakeholders (optional)
- Stakeholder groups (optional)
Click Create.

The new migration wave appears in the list of existing migration waves.
To assign applications to a migration wave, click the Options menu () to the right of the migration wave and select Manage applications from the menu.

The Manage applications window opens. The window displays the list of applications that are not assigned to any other migration wave.
Select the checkboxes of the applications that you want to assign to the migration wave and click Save.

Note

The owner and the contributors of each application associated with the migration wave are automatically added to the migration wave’s list of stakeholders.
To update a migration wave, select Update from its Options menu (three dots).

The Update migration wave window opens.

7.8. Creating Jira issues for a migration wave

You can use a migration wave for creating Jira issues automatically for each application assigned to the migration wave.

Procedure

In Migration view, click Migration waves.
Click the Options menu () to the right of the migration wave for which you want to create Jira issues and select Export to Issue Manager.

The Export to Issue Manager window opens.
Select the instance type (Jira Cloud or Jira Server/Datacenter).
Select the instance, project and issue type from the lists.
Click Export.

The status of the migration wave on the Migration waves page changes to Issues Created. To see the status of each individual application of a migration wave, click the Status column.

A separate Jira issue is created for each application associated with the migration wave. The following fields of each issue are filled in automatically:
- Title: Migrate <application name>
- Reporter: Username of the token owner
- Description: Created by Konveyor

After you exported a migration wave to the Issue Manager and the Jira issues are created, you can no longer change them from within the MTA user interface. Even if you delete the migration wave, the Jira issues remain.

On the Application inventory page, you can see if any particular application is associated with a migration wave by opening the application’s Details tab.

You cannot delete an application if it is linked to a Jira ticket or if it is associated with a Migration wave.

To unlink an application from a Jira ticket, click the Unlink from Jira icon in the details view of the application or in the details view of a Migration wave.

Revised on 2024-02-05 13:40:16 UTC