About Migration

In Oracle Communications Unified Assurance, the Historical database stores historical event data, flow data, and log data to support Event, Flow, and Log Analytics capabilities, and provides a UI for you to interact with the data.

In previous releases, the Historical database was an Elasticsearch database, with Kibana providing the UI. In version 6.1, OpenSearch replaces Elasticsearch, and OpenSearch Dashboards replaces Kibana.

You must migrate your existing Elasticsearch data and objects to OpenSearch when you update to Unified Assurance version 6.1. Most of your objects and data can be migrated automatically, but some custom artifacts must be manually recreated.

Because licensing for Elasticsearch will no longer be available, all customers must move to version 6.1 and migrate to OpenSearch before March 31, 2026. On this date, Elasticsearch license keys will expire. Elasticsearch will stop accepting new data, and you will lose access to existing unmigrated data.

Supported Migration Paths

Your migration path depends on your current Unified Assurance and operating system versions. The following table lists the supported migration paths for each version and interim steps. Because downtime is required for each major version upgrade and operating system upgrade, you will need to schedule a maintenance window.

• If you are currently running Unified Assurance version 4 or 5, you must upgrade or update to a final version of version 5, upgrade your operating system, and finally, upgrade to version 6.1.

  This process requires downtime during major version upgrades (4 to 5 and 5 to 6) and the operating system upgrade.

  See Upgrading from Assure1 to Unified Assurance in Unified Assurance Installation Guide.

• If you are currently running Unified Assurance version 6 on Linux 7, you must upgrade your operating system, then update to version 6.1.

  This process requires downtime during the operating system upgrade.

  See Upgrading Unified Assurance to a New Linux System or Upgrading Unified Assurance on an Existing Linux System in Unified Assurance Installation Guide.

• If you are currently running Unified Assurance version 6 on Linux 8, you can update to version 6.1.

  This process requires minimum downtime if you are using the Flow Collector microservice, which must be redeployed after updating the microservice cluster.

  See Updating Unified Assurance in Unified Assurance Installation Guide for information about updating.

Migration Process Overview

Migration involves the following high level tasks:

1. Upgrade or update your Unified Assurance environment and operating system. This process automatically migrates Elasticsearch objects to OpenSearch by running AnalyticsWizard. See the following topics in Unified Assurance Installation Guide for complete details:

   • Upgrading from Assure1 to Unified Assurance

   • Upgrading Unified Assurance to a New Linux System

   • Upgrading Unified Assurance on an Existing Linux System

   • Updating Unified Assurance

2. Migrate indexes by running MigrateHistoricalData. You can migrate entire indexes in one operation or in smaller time-based increments, depending on the index type and size:

   • Event Analytics: Indexes are typically smaller. You can migrate them entirely in one operation.

   • Flow Analytics: Indexes can be much bigger. Oracle recommends migrating them in time-based increments, deleting the migrated indexes from Elasticsearch as you go.

   • Log Analytics: Oracle does not recommend migrating your log indexes. These can be much bigger, and the data structure for the previous Filebeat indexes is not compatible with Fluentbit or the new OpenSearch Dashboards interface. If you migrate your logs, it will only be for reference purposes; you will not be able to see them in the UI or take advantage of logging dashboards for them.

   See Migrating Indexes.

3. Manually recreate artifacts that are incompatible between Elasticsearch and OpenSearch.

   See Manually Migrated Artifacts for information about which artifacts need to be manually migrated and Manual Migration Tasks for information about migrating them.

4. Finalize the migration and remove Elasticsearch, including all remaining indexes and related components, by running AnalyticsWizard a final time.

   See Finalizing the Migration.

Migrated Artifacts

You migrate most artifacts and indexes automatically but you must migrate some incompatible artifacts manually.

Automatically Migrated Artifacts

The following Elasticsearch features and components are automatically migrated when you run Package update as part of updating to version 6.1:

• Saved objects:

  • Configurations

  • URLs

  • Index patterns

  • Queries

  • Maps

  • Searches

  • Visualizations

  • Dashboards

• Anomaly detection jobs, including any customizations

• Index lifecycle management (ILM) policies. The ILM policies for the Elasticsearch indexes, including any customizations you made, are automatically migrated to index state management (ISM) policies for the corresponding indexes in OpenSearch.

• Roles, users, and rolemaps

• Pipelines

• Aliases

See About Automatically Migrating Artifacts for details about the migration process for these objects.

After migrating these objects, you run MigrateHistoricalData to migrate indexes. You provide input about which indexes and time ranges to migrate, and MigrateHistoricalData migrates them for you. See Migrating Indexes.

Manually Migrated Artifacts

The following Elasticsearch features and components cannot be automatically migrated. You must manually recreate any that are applicable to your environment.

• Elasticsearch dashboards created with Kibana Lens or Canvas. Other dashboards are migrated automatically.

• Custom Elasticsearch Watcher watches. These are replaced by OpenSearch notification channels and monitors; the default notification channel and monitor that send detected anomalies to the Event database are set up automatically.

• Elasticsearch Snapshot Management policies for automated backups

• Custom Unified Assurance database queries. The default sample query is included automatically.

• Any custom Elasticsearch Machine Learning functionality other than anomaly detection jobs.

See Manual Migration Tasks for guidance on migrating these artifacts.

Architecture

As part of the first migration task, AnalyticsWizard deploys an instance of Elasticsearch on one port and an instance of OpenSearch on another port on the same Historical database server. This temporary architecture lets you migrate objects and indexes between live databases without significant downtime or data loss.

With Elasticsearch, the Historical database consisted of a single-node cluster. You initially migrate to a single-node cluster on OpenSearch. After completing the migration, you can add additional servers to the cluster by installing Unified Assurance on them and running AnalyticsWizard. AnalyticsWizard detects that a cluster exists and prompts you to add the server to it. See Adding Nodes to the Historical Database Cluster in Unified Assurance Implementation Guide.

If you are using redundant clusters, you scale both clusters in the same way. For example, if you add two additional nodes to the primary cluster, add two additional nodes to the redundant cluster as well.

See the following in Unified Assurance Concepts for more information about the migrated Historical database architecture:

• Historical Database Scalability and Redundancy

• Observability Analytics Architecture

• Flow Analytics Architecture

Terminology Changes

The following table maps some equivalent terminologies and technologies from Elasticsearch to OpenSearch.

System Requirements

For complete information about general system requirements for Unified Assurance, including system and hardware requirements, see Unified Assurance Architecture in Unified Assurance Installation Guide.

The following requirements are specific to migration:

• OpenSearch requires at least 2GB of memory, which is approximately the same amount as Elasticsearch.

• Until you finalize the migration process, both Elasticsearch and OpenSearch will be running on the same server. Because OpenSearch requires approximately the same amount of memory as Elasticsearch, the migration process requires at least twice the memory of your current Elasticsearch implementation. If needed, you can add more memory before migrating, or scale back your Elasticsearch heap size. After finalizing the migration and removing Elasticsearch, you can scale up your OpenSearch heap size to use the full amount.

• Migrating indexes can take significant memory and storage space, especially if you are migrating Flow Analytics indexes. The index migration process uses approximately 1-2GB of active memory.

  • If you intend to migrate your indexes in one operation, you will need two times the disk space that you previously had, until you finalize the migration process by removing Elasticsearch.

  • If you intend to migrate your indexes incrementally, you will need enough disk space for each increment, times two. Because Machine Learning and Anomaly Detection use a lot of memory, Oracle recommends that you pause Elasticsearch Machine Learning jobs and do not start Anomaly Detection in OpenSearch until migration is complete.