# Existing Customer Migration This article outlines the process for migrating existing customer environments to the AskEdgi model. It covers account setup, deployment, release migration, database and Java upgrades, Docker image building, ECS updates, encryption key configuration, and integration with AskEdgi services. The document also includes verification and validation steps to ensure successful migration and post-deployment health checks. ## Purpose of the document The purpose of this article is to describe the detailed steps required to migrate existing OvalEdge customer environments to the new AskEdgi model, ensuring minimal downtime, configuration consistency, and operational continuity across all environments. ## Pre-Migration Setup Before starting the migration, ensure that the following prerequisites are in place:

Requirement	Description
Access	Valid access credentials to AWS Master and Child accounts.
Backup	Full RDS database snapshot of UAT and Production environments.
Network Access	All necessary IPs and domains for whitelisting are identified.
Bridge Servers	Bridge client and server are operational for EFS transfer.

{% hint style="warning" %} Perform all migration activities in a controlled environment with monitoring enabled to validate each operation. {% endhint %} ## Migration and Deployment Process ### 1. Account Setup Through Control Tower automation, a new SaaS + AskEdgi environment is created for each customer. Standard Operating Procedures (SOPs) are automatically generated and synchronized with the AWS Master account. ### 2. Deployment CloudFormation StackSets are created in the Master account and deployed to child accounts. **StackSets perform the following actions:**

Action	Description
Bootstrapping	Initializes child accounts for migration.
Resource Provisioning	Deploys templates required for environment setup.

### 3. Release Migration The following release upgrades are performed within the same account: | Component | From Version | To Version | | -------------- | ------------ | ---------- | | OE Application | 6.3.X | 7.2.X | | RDS | 8.0.X | 8.4.X | | NIFI | 1.18.0 | 1.28.0 | | Java | 8 | 17 | {% hint style="info" %} Ensure all release dependencies are validated before proceeding. {% endhint %} ### 4. RDS and MySQL Migration #### Step 1: RDS Database Backup Take RDS snapshots of customer UAT and Production environments before upgrading to version 7.2.X.

#### Step 2: MySQL Version Upgrade (8.0.40 to 8.4.46) 1. Modify the RDS instance in UAT/PROD. 2. Create a **DB parameter** group for version **8.4**. 3. Attach the created parameter group to the **RDS instance**. 4. Update parameters in the **DB parameter** group as required.

5. Select the DB engine version **8.4.46**.

6. In Additional Configuration, select the new parameter group and click **Modify**.

7. Wait for the modification to complete.

* **Result:** RDS is successfully upgraded to version 8.4.46. * Mysql migration from 8.0.40 to 8.4.46 is completed.

### 5. Java Upgrade * Update the Java version from 8 to 17 (**OpenJDK**) in the Docker file.

#### 6. Docker Image Building Perform the following steps to build and push the Docker image: * Collect the updated **oasis.properties** file and update it in run.sh. * Collect the updated **logging.properties** file and update it in the image build folder. * Use hardened Tomcat for image build.

* Build and push the image using the commands below: ``` docker build -t oesaasinfra/saasrepo:cdw-7.2.3-10-09-2025 . docker push oesaasinfra/saasrepo:cdw-7.2.3-10-09-2025 ``` {% hint style="info" %} Ensure the oe log-rotation parameters are included in the logging.properties file. {% endhint %} ### 7. ECS Deployment Update the newly built 7.2.X image in the Customer UI and JOB task definitions, then deploy to ECS services. **UI Task Definition** * Update the ECS service with the latest image and desired task count set to 1.

**JOB Task Definition** * Perform similar updates for JOB task definitions.

**Deploy in UI/Job Service in ECS** * Select the latest version number of the task definition and desired task as 1, scroll down, and click on update.

**Deployment Verification** * Ensure both services (UI and JOB) are running successfully.

### 8. Encrypt-Decrypt Key Change If the default encryption key is used, change it from the default to a random key. Checklist: ## Migration to AskEdgi Model ### 1. RDS Database Backup and Restore * Take the OvalEdge database backup in .sql format: ``` mysqldump -u root -p --single-transaction --skip-lock-tables ovaledgedb > ovaledgedb.sql ``` * Restore the backup to the new account RDS instance running version **8.4.6**. ### 2. EFS Migration * Take a backup of all NIFI folders in **.zip format**.

* Copy the zipped backup files to the EFS of the newly created bridge server in the new AWS account.

### 3. Networking Configuration Migration * Retrieve customer IPs from the old environment. * Whitelist retrieved customer IPs in the new setup. * Map the OE Application and NIFI Load Balancer DNS in Route53 using the new Load Balancer DNS values. ### 4. Customer Whitelisting Request the customer to whitelist the new NAT IP or Network Load Balancer IP in the Bridge Client VM firewall/security configuration. ### 5. Secrets Manager Migration * Copy the encrypt-decrypt key from the old environment. * Paste the same key in the Secrets Manager of the new account.

### 6. NIFI Server and Client UI Changes **Client UI Changes** * Disable the NIFI flow.

* Stop the RouteOnAttribute processor.

* Delete connections from **Bridge1**.

* Add a new processor **OEEncryptDecryptProcessor 7.2.3-SNAPSHOT.**

* Connect the flow to the new processor (**OEEncryptDecryptProcessor**). * Configure relationships and terminate success paths as needed. * Right-click on OEEncryptDecryptProcessor and in relationships, select the terminate and click the **OK** button.

* Right-click on Name Success To\_Bridge1 and click on configure. Select the success in the DETAILS Section and click on **Apply**.

* Right-click on RouteOnAttribute, OEEncryptDecryptProcessor, and start the processors. * Enable the NIFI FLOW Processor by right-clicking on the NIFI FLOW Processor box.

* Restart the processors and re-enable the NIFI Flow. **Result**: Bridge Client UI is updated and running with the new encryption configuration.

### 7. Bridge Client Java Migration #### Step 1: Stop NIFI Service Ensure NIFI service is stopped before upgrading Java. ``` Command : java -version ``` #### Step 2: Uninstall Java 8 from Ubuntu system ``` sudo apt list --installed | grep -i openjdk sudo apt purge openjdk-8-* sudo apt autoremove --purge sudo apt clean ``` **Verify removal:** ``` java -version javac -version ``` #### Step 3 (Optional): Remove any manual installations If Java was manually installed (for example, extracted .tar.gz under /usr/lib/jvm or /opt/java), remove these installations: ``` sudo rm -rf /usr/lib/jvm/* sudo rm -rf /opt/java ``` #### Install Java 17 **Step 1: Update package list** ``` sudo apt update ``` **Step 2: Install OpenJDK 17** ``` sudo apt install openjdk-17-jdk -y ``` **Step 3: Verify the installation** ``` java -version ``` * Once Java 17 is installed, download the latest version of Nar into the lib folder and start the NiFi client as shown in the screenshot below.

* Check the status of the bridge client and server in the application bridge page.

## Validation and Testing

Validation	Description
BridgeCall	Conducted with customer to verify IP whitelisting and connector validation.
Connector Health	Ensure all connectors show a healthy status post migration.
App Availability	Confirm that the application UI and JOB services are running successfully.

BridgeCall must be required with the customer to verify the IP whitelisting and connectors validation. Connectors Validation: Once all activities are done in migration, validate the connectors and check that the connectors are healthy.

## AskEdgi Integration * Once the migrated application is validated and all connectors are healthy, the edgiInsightService synchronizes with the application. * Upon successful sync, the edgi-data-service-1001 instance is created, indicating the AskEdgi workspace has been successfully provisioned within the application. Once the Application is validated with healthy connectors, the [edgiInsightService](https://eu-west-2.console.aws.amazon.com/ecs/v2/clusters/ovaledgeprod/services/ovaledgeprod-edgiInsightService/health?region=eu-west-2) will sink with the application, and the [edgi-data-service-1001](https://eu-west-2.console.aws.amazon.com/ecs/v2/clusters/ovaledgeprod/services/edgi-data-service-1001/health?region=eu-west-2) will get created, indicating the AskEdgi workspace is created in the application.

**AskEdgi workspace creation**