Release6.0.2 Migration Process

Introduction

This document assists users in migrating from an older version of OvalEdge to the latest version.

What is Migration

The process of migrating from an older version of OvalEdge to a newer version involves making changes to the OvalEdge database as well as the application.

Prerequisites

These are the list of necessary steps that must be completed before initiating the migration process:

Database Backup

It is important to take a backup of your database before the migration for several reasons, including:

• Disaster Recovery: In case of any data loss or corruption during the migration process, a database backup ensures that you can recover your data and restore it to its previous state.
• Rollback Plan: Having a database backup allows you to roll back to the previous version of your database in case the migration does not go as planned or if you encounter unexpected issues.
• Testing: A backup allows you to test the migration process without risking your live production data. This way, you can ensure that the migration process is smooth and that there are no issues that may cause downtime or data loss.

Tables RowCount Validation

The validation of the Table row count is necessary to ensure that the migration is a success.

• OvalEdge provides SQL queries that display the row count of each table in the OvalEdge database before and after the migration process. Compare the pre and post-migration row counts to ensure that all data has been successfully migrated.

• The SQL Query can be downloaded from the - Query Link

  Note: This query should run on the command line.

• Using OvalEdge's SQL queries for row count validation can help ensure the accuracy of the migration process and ensure no data is lost.

WAR/Image Backup

There are several reasons why it is a good idea to create a backup of a WAR file such as:

• Rollbacks: Deploying an older WAR file can easily and quickly roll back an application if the newer version introduces bugs or other issues.
• Disaster recovery: If there is a malfunction with the server or any other significant issue, the application can be quickly restored to normal operations using a recently saved backup.

Logs Backup

Log files contain essential information about system and application events, errors, and warnings that can help in troubleshooting or investigating security incidents. Backing up log files ensures that this critical information is preserved in case of data loss or system failure. It also allows for the historical analysis of log data, which can help to identify trends or patterns over time.

Infrastructure Migration

The below table lists the minimum infrastructure for migrating to the latest version of OvalEdge.

Note: This infrastructure is a minimum recommendation for applications. The configuration may vary depending on the number of users and connectors.

Database Migration

The below table lists the recommended version of the database to run the latest version of OvalEdge.

Migrating from MySQL to MariaDB is recommended for several reasons:

• License: MariaDB is licensed under the GNU GPL, while some versions of MySQL are now owned by Oracle and use a more restrictive license. The open-source nature of MariaDB makes it more attractive to some users who want to avoid proprietary software.
• Community support: The MariaDB community is active and has many contributors, so updates and bug fixes are released more frequently than with MySQL. This can lead to better performance and stability.
• Compatibility: MariaDB is designed to be a drop-in replacement for MySQL, which means that most applications written for MySQL can run on MariaDB without any changes. This makes the migration process much easier and less risky.
• Features: MariaDB has several additional features not available in MySQL, such as the ability to use multiple storage engines and better performance with high concurrency.
• Overall, migrating to MariaDB can provide a number of benefits and is a recommended choice for those looking for an alternative to MySQL.

Note: OvalEdge does not recommend performing a database migration if the current database is anything other than MySQL 5.7 or a member of the MySQL version family (e.g, Aurora MySQL).

DevOps Migration

This section mentions any DevOps-related changes the user has to incorporate before migrating from an older version of OvalEdge to the newer version.

• Migrating from R5.2.x.y to R6.0.2: If oasis.properties is configured to read from an external path and the OvalEdge Application is running on a VM, make sure to update oasis.properties to the R6.0.2 version before migration.

Application migration

Here is a step-by-step process of application migration (with images) for hassle-free execution. 

Click on the About icon to view the version info.

Pre-Migration OvalEdge About Screen

Pre-Migration Version Table. To view this information connect to the OvalEdge database and use the below queries:

ovaledgedb;

Select * from version;

Check if Auto DB Migration has Started - This information is available in the ovaledge.log file. Path- tomcat/logs/

Check if the DB Migration is in Progress - This information is available in Catalina.out file.

Check if the Migration is Complete - This information is available in Catalina.out file.

Note: If the migration fails due to any unforeseen issues, please contact OvalEdge and our On-Call Support Team will provide assistance in completing the migration.

Post Migration OvalEdge About Screen- Click on the about icon to view the version info.

ovaledgedb;

Select * from version;

 

Migrating from 5.2.x.y to 6.0.0.x

Please find the list of all the support links for users migrating from 5.2.x.y to 6.0.0.x below:

• Release 5.2 Migration Process
• Release 6.0 Migration Process
• Release 6.0.0.1 Migration Process
• Release 6.0.0.4 Migration Process
• Release 6.0.1 Migration Process

Advanced Jobs

Migrating from R5.2.x.y to R6.0.2

This section lists the advanced jobs that need to be executed by users migrating from R5.2.x.y to R6.0.2 (latest version).

• Migrate Data To Denormalized Tables

       (Type: MIGRATE_DATA_TO_DENORMALIZED_TABLES )

• • OvalEdge has increased the number of tables in the database; this development will distribute the data among all of the newly added and existing tables allowing the application to retrieve data from multiple tables simultaneously.

• • The execution of this advance job is a one-time process, but it is mandatory to run this job to prevent issues with the data catalog pages.
• Load oereportext table for reporting framework    
  (Type: LOADOEREPORTEXT)
  • This advance job will reload all existing OvalEdge custom reports and new reports (if any).
  • The completion of this advanced task is a one-time endeavor, as it will generate new and improved reports. 
• Servicedesk Data Migration
  (Type: SERVICDESK_DATA_MIGRATION):
  • The latest version of OvalEdge has enhanced the service desk's functionality. By executing this task, users will be able to seamlessly access their old version service tickets on the newer version, without facing any difficulties.

• • Users have to run this job only once.
• Delete Duplicate Records From Oesecure Table
  (Type: Delete Duplicate Records From Oesecure Tables ):
  • This Job identifies any duplicate records of certain tables in the database and deletes those records

• • This is a one-time task, which prevents data redundancy and improves system performance by removing duplicate records.

Migration from R6.0 Gamma to R6.0.2

This section lists the advanced jobs that need to be executed by users migrating from R6.0 Gamma to R6.0.2 (latest version).

• Load oereportext table for reporting framework    
  (Type: LOADOEREPORTEXT)
  • This advance job will reload all existing OvalEdge custom reports and new reports (if any).
  • The completion of this advanced task is a one-time endeavor, as it will generate new and improved reports. 
• Servicedesk Data Migration
  (Type: SERVICDESK_DATA_MIGRATION):
  • The latest version of OvalEdge has enhanced the service desk's functionality. By executing this task, users will be able to seamlessly access their old version service tickets on the newer version, without facing any difficulties.
  • Users have to run this job only once.

• Delete Duplicate Records From Oesecure Table
  (Type: Delete Duplicate Records From Oesecure Tables ):
  • This Job identifies any duplicate records of certain tables in the database and deletes those records.
  • This is a one-time task, which prevents data redundancy and improves system performance by removing duplicate records.

To obtain further details on advanced jobs, please refer to the guide on How to run an advanced job.

---

Appendix

The below Architectural diagram is a proposed setup for all future deployments.

Here is a brief description of the Architectural diagram above:

• The new architecture consists of two Virtual Machines (VM).
• There are two OvalEdge applications in the VM to the left, one dedicated to Serving UI Requests and the other to handling Job Requests. Elasticsearch is deployed in the same VM.
• VM to the right is the Relational Database Service (RDS) which is a private subnet and can be accessed only by the OvalEdge VM.
• These components - Route53, ACM, and Load Balancer - are illustrated here solely to depict the routing of global traffic. However, the actual configuration of these components within the AWS client depends on how they are set up.

---

Copyright © 2023, OvalEdge LLC, Peachtree Corners, GA USA