Moving to ASAP Cloud Native from a Traditional Deployment

Supported Releases

You can move to ASAP cloud native from all supported traditional ASAP releases. In addition, you can move to ASAP cloud native within the same release, starting from the ASAP release 7.3.0.6.0.

About the Move Process

The move to ASAP cloud native involves offline preparation as well as maintenance outage. This section outlines the general process as well as the details of the steps involved in the move to ASAP cloud native. However, there are various places where choices have to be made. It is recommended that a specific procedure be put together after taking into account these choices in your deployment context.

The ASAP cloud native application layer runs on different hardware locations (within a Kubernetes cluster) than the ASAP traditional application layer.

The process of moving to ASAP cloud native involves the following sets of activities:

Pre-move development activities, which includes the following tasks:
- Building ASAP cloud native images (cloud native task)
- Creating project specification ASAP cloud native (cloud native and solution task)
- Creating an ASAP cloud native instance for testing (cloud native task)
- Validating your solution cartridges (solution task)
- Deleting the test ASAP cloud native instance (cloud native task)
Data synchronization activities, which include the following tasks:
- Preparing a new database server (database task)
- Synchronizing the current database server (database task)
Tasks for moving to ASAP cloud native, which include the following:
- Quiescing the ASAP traditional instance (solution task)
- Backing up the database (database task)
- Creating an ASAP cloud native instance (cloud native task)
- Performing a smoke test (solution task)
- Importing the database (database task)
- Switching all upstream systems (solution task)
  For more information about creating backup and rolling back the ASAP database, see "Creating a Backup of the ASAP Schemas" and "Rolling Back the ASAP Database" in ASAP Installation Guide.

Pre-move Development Activities

In preparation to move your traditional ASAP instance into an ASAP cloud native environment, you must do the following activities:

Build the ASAP cloud native image with the same ENV_ID, database users credentials, default users credentials, same port numbers, and cartridges deployed in the traditional deployment. This task includes creating the ASAP image and using the ASAP cloud native download packages. See "Creating an ASAP Cloud Native Image" for details.

Note:
The values of ENV_ID and port numbers are present in the asap73ServerLinux.response file (if moving from 7.3.x traditional deployment) or asap74ServerLinux.response file (if moving from 7.4.x traditional deployment) of the ASAP installation directory.
Create an ASAP cloud native test instance and test your instance.
Validate the solution.
Shut down your test instance and remove the associated secrets and ingress.

Moving to an ASAP Cloud Native Deployment

Moving to an ASAP cloud native deployment from an ASAP traditional deployment requires performing the following tasks:

Quiesce the ASAP traditional instance. See "Quiescing the Traditional Instance of ASAP".
Create the ASAP cloud native image. See "Creating the ASAP Cloud Native Image".
Import the restored data from the traditional instance to the cloud native instance.
Create the ASAP cloud native instance. See "Creating an ASAP Cloud Native Instance".
Perform a smoke test. See "Performing a Smoke Test". Once the ASAP cloud native instance passes the smoke test and is optionally resized to the desired target value, shut down the ASAP traditional instance fully.
Switch all upstream systems to the ASAP cloud native instance. See "Switching Integration with Upstream Systems".

Quiescing the Traditional Instance of ASAP

At the start of the maintenance window, the ASAP traditional instance must be quiesced. This involves stopping database jobs, stopping all upstream and peer systems from sending messages (for example, http/s, JMS, and SAF) to ASAP, and ensuring all human users are logged out. It also involves pausing the JMS queues so that no messages get queued or dequeued. The result is that ASAP is up and running, but completely idle.

Restoring the Database

Before creating the final ASAP image, restore the database. For more information, see "Rolling Back the ASAP Database" in ASAP Installation Guide and follow these steps:

Update hostname in tbl_listeners of the CTRL database by running the following command:
```
update tbl_listeners set HOST_NAME='asaphost';
```
where 'asaphost' is the name of the host in which ASAP is deployed.
Update the hostname in the TBL_ASAP_SRP table of the SARM by running the following command:
```
update TBL_ASAP_SRP set HOST_NAME='asaphost';
```
Update the SRP_HOST_NAME field in the TBL_ASAP_SRP table by running the following command:
```
update TBL_ASAP_SRP set SRP_HOST_NAME='asaphost';
```

Switching Integration with Upstream Systems

After you shut down the ASAP traditional instance fully, do the following:

Ensure that the ASAP cloud native instance has its JMS.
Configure the upstream to resume sending messages. See "Integrating ASAP" for more details.

Reverting to Your ASAP Traditional Deployment

During the move to ASAP cloud native, if there is a need to revert to your ASAP traditional deployment, the exact sequence of steps that you need to perform depends on the options you have chosen while moving to ASAP cloud native.

In general, the ASAP traditional deployment application layer should be undisturbed through the upgrade process. The ASAP traditional instance can simply be started up again, still pointing to its database.

Cleaning Up

Once the ASAP cloud native instance is deemed operational, you can release the resources used for the ASAP traditional application layer.

You can delete the database used for ASAP traditional instance and release its resources as well.