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:
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.
Perform all migration activities in a controlled environment with monitoring enabled to validate each operation.
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:
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:
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
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)
Modify the RDS instance in UAT/PROD.
Create a DB parameter group for version 8.4.
Attach the created parameter group to the RDS instance.
Update parameters in the DB parameter group as required.
Select the DB engine version 8.4.46.
In Additional Configuration, select the new parameter group and click Modify.
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:
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: https://docs.google.com/spreadsheets/d/1bYawEICKIzhoTE32nk8ln9rXcZ629HwtNt6VlqW-Fno/edit?gid=0#gid=0
Migration to AskEdgi Model
1. RDS Database Backup and Restore
Take the OvalEdge database backup in .sql format:
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.
Step 2: Uninstall Java 8 from Ubuntu system
Verify removal:
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:
Install Java 17
Step 1: Update package list
Step 2: Install OpenJDK 17
Step 3: Verify the installation
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
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 will sink with the application, and the edgi-data-service-1001 will get created, indicating the AskEdgi workspace is created in the application.
AskEdgi workspace creation
Result: AskEdgi workspace appears within the application dashboard, confirming successful integration.
Copyright © 2025, OvalEdge LLC, Peachtree Corners, GA, USA.
Last updated
Was this helpful?