Known issues, limitations, and notes Innovation Release

These are the known issues, limitations, and notes for:

• Data migration limitations

• Oracle limitations

• Postgres limitations

• Schema ingestion known issues

• HM Migration Portal known issues

• Other known issues

Data migration limitations

Case sensitivity in object names

EDB DMS doesn’t currently support migrating schemas, tables, and columns that have case-sensitive names.

Upgraded destinations clusters

You can't use clusters provisioned in Hybrid Manager (HM) versions 1.2 and earlier as migration destinations after you upgrade the HM instance to version 1.3 or later. You must create a new cluster in the upgraded environment to use it as a valid migration destination.

Considerations and limitations for multiple migrations to a single destination

The DMS supports running multiple data migrations from one source to one destination database, but certain restrictions apply.

• Table usage: You can actively use each destination table only in a single migration at any given time.

• Unique resourceID (applies to migrations to external destinations): When running multiple migrations to an external destination, you must assign a unique resourceID to each instance of the EDB DMS agent in writer mode with the DBCONFIG_DATABASES_0__RESOURCEID=${Resource_ID} parameter. Setting this parameter prevents concurrent migrations from attempting to use the same table simultaneously, which can cause data loss or duplication.

  Note

  This resourceID requirement doesn't apply to migrations targeting HM-managed Postgres instances.

• Performance planning (applies to migrations to external destinations): While performance generally remains strong with the recommended specifications, if you run five or more migrations to the same external destination database, to prevent resource contention, consider allocating additional CPU, memory, and volume IOPS/throughput to the destination. This is especially important if the destination is an external database.

• Resource management: Each migration job requires a dedicated, non-concurrent use of the necessary DMS agent components.

  DMS agent in reader mode (source): Don't use a single running instance of the EDB DMS agent in reader mode for more than one concurrent migration from the same source database. The HM console removes a source database from the available list once it's active in a migration. However, you can use a single DMS agent in reader mode for subsequent migrations or for concurrent migrations from different source databases.

  DMS agent in writer mode (external destination): Each migration requires its own instance of the DMS agent in writer mode, even if the migration shares the same destination as another migration.

Oracle limitations

Unsupported Oracle data types

A limited number of Oracle data types and features aren't supported by EDB DMS.

See the Debezium documentation for detailed comments on supported data types.

Unsupported Oracle data types include:

• BFILE
• LONG
• LONG RAW
• RAW
• UROWID
• User-defined types (REF, Varrays, Nested Tables)
• ANYDATA
• XMLTYPE
• Spatial

EDB DMS supports replicating Oracle tables that contain BLOB, CLOB, or NCLOB columns only if these also have the primary key constraint. If the tables don't have the primary key constraint, the streaming replication supports only INSERT operations.

BINARY_FLOAT and BINARY_DOUBLE types in Oracle that might contain Nan, +INF, and -INF values aren't supported by EDB DMS.

EDB DMS doesn't support values containing a null character (0x00) for text field types like VARCHAR and CLOB in Oracle.

Oracle 21c databases

The DMS agent supports migrating Oracle 21c databases. However, Migration Portal doesn't. This means that to migrate 21c databases, you must manually perform the schema migration.

Oracle XE compatibility restrictions

Oracle XE (Express Edition) does not support enabling supplemental logging at the database level. Because this is a core requirement for Change Data Capture (CDC), EDB DMS is not fully compatible with Oracle XE as a source database.

• Expected errors — When using Oracle XE, the DMS Agent (reader) will typically fail and log exceptions similar to - Debezium consumer $NAME stopped with exception: an exception occurred in the change event producer. This connector will be stopped.

• Limited functionality — Only snapshot-only migrations are expected to function. Even during successful snapshots, Debezium error messages may still appear in the logs.

• Usage policy — Snapshot-only migrations on Oracle XE are suitable only for testing or evaluation purposes. This configuration is not supported for production use cases.

Postgres limitations

Unsupported domain type definitions in columns

The EDB DMS doesn't support migrating tables with columns that have user-defined domains as data types for the following data type domains:

• DATE
• TIME
• TIMESTAMP
• INTERVAL
• UUID
• ENUM
• JSON
• XML
• POINT
• LTREE
• TSVECTOR

TSVECTOR type migration workaround

Although we don't support migrating TSVECTOR type columns, you can apply this workaround to enable their migration. For example, this messages table in source database contains a TSVECTOR column:

CREATE TABLE messages (
    title       text,
    body        text,
    tsv         tsvector
);

Before starting the migration, create a table in the destination database without the TSVECTOR column:

CREATE TABLE messages (
    title       text,
    body        text,
);

When you perform the migration, you must exclude the TSVECTOR column in the HM console when you review the tables on the Review your Tables page by clearing the tsv column check box.

After the migration finishes, the title and body columns are migrated to the target database. Now you can add the TSVECTOR column to the target table:

ALTER TABLE messages ADD COLUMN tsv TSVECTOR DEFAULT NULL;

Then run the following UPDATE statement to populate the column for all migrated data:

UPDATE messages SET tsv = to_tsvector('english', CONCAT(title, ' ', body)) WHERE tsv IS NULL;

Schema ingestion known issues

Additional schemas ingested for EDB Postgres Advanced Server sources

When viewing the list of schemas for a source EDB Postgres Advanced Server database that you registered with the HM agent, you may observe additional schemas that don't directly correspond to schemas you explicitly created. These extra schemas are generated internally by EDB Postgres Advanced Server as part of its Oracle compatibility feature set to represent Oracle PACKAGE objects. This is a known issue that we expect to correct in a future release. In the meantime, you can disregard these generated schemas for migration purposes.

HM Migration Portal known issues

Disabling the automatic Migration Portal project creation requires a workaround

There is a known issue in 2025.12 and earlier versions affecting the internal beacon-server service where setting the autocreate_mp_projects: false parameter in the ConfigMap doesn't prevent the automatic creation of Migration Portal projects.

Workaround: To prevent the automatic creation of Migration Portal projects and enforce manual creation, set the parameter max_automatic_project_creation_bytes to an extremely low value, for example 1, within the beacon-server ConfigMap. This low threshold ensures that all schemas exceed the limit, successfully bypassing the automatic creation process.

1. Edit the beacon-server ConfigMap:

   → WrapCopy

   kubectl edit configmap beacon-server-config -n upm-beacon

2. Locate the beacon_server.yaml block and insert or modify the max_automatic_project_creation_bytes section under server. Set the value to an extremely low number, like 1, to ensure automatic creation is bypassed:

   → WrapCopy

   apiVersion: v1
   data:
     beacon_server.yaml: |
     # [...]
       server:
       # [...]
         migration_portal_configuration:
           max_automatic_project_creation_bytes: 1

3. Apply the changes by restarting the beacon_server deployment:

   → WrapCopy

   kubectl rollout restart deployment upm-beacon-server -n upm-beacon

   Warning

   The upm-beacon-server supports all database registration and schema ingestion activities across the entire HM instance using HM agents. Restarting the upm-beacon-server will halt all ongoing database registrations and schema ingestions, regardless of the project. Ensure you coordinate this restart with other users.

   Databases that already appear in the Estate > Migrations tab, for which schema ingestions have finished, are not affected by restarts.

4. You can monitor the status of your restarted service:

   → WrapCopy

   kubectl get pods -n upm-beacon

HM warning persists after manual Migration Portal project creation

In versions 2025.12 and earlier, when the automatic creation of a Migration Portal project fails (for example, due to the ingested schemas exceeding the default size limit of 300 MB or a different specified limit), the HM console displays a persistent warning instructing the user to manually create the projects. This warning continues to display in the HM console even after the user has successfully created the necessary Migration Portal projects for their Oracle schemas.

Automatic Migration Portal project creation fails with invalid resource_id characters

The automatic creation of Migration Portal projects fails (with error message Failed to create) if the resource_id specified for the registered Oracle database contains characters that are invalid.

This failure occurs because the resource_id value is used in the construction of the Migration Portal project name, which currently doesn't support special characters like hyphens (-), which prevent project creation.

Workaround: To ensure successful automatic creation of Migration Portal projects, the resource_id value specified in the HM agent configuration for Oracle databases must conform to the following naming rules:

• It can include alphanumeric characters (A–Z, a–z, 0–9).
• It can include the underscore (_) character, but it cannot begin with an underscore.
• It must not start with a number.
• It must not contain special characters, such as the hyphen (-).

Migration Portal database pods fail to start after upgrade

Description: Following an upgrade to the 2026.01 Innovation Release, the PostgreSQL pods for the Migration Portal (for example, mp-epas-16, mp-epas-17) may enter a CrashLoopBackOff or ImagePullBackOff state. This occurs because the deployment is referencing an incorrect image digest or tag that is no longer available in the repository.

Workaround: To resolve the error and restore the Migration Portal to a healthy state, manually delete the affected pods using kubectl delete pod <pod-name>. The deployment will automatically recreate the pods using the correct, updated image.

SSL connection error (x25519) when migrating schema to EPAS 18 using Migration Portal

Description: When using the Migration Portal's online schema migration feature to target an EDB Postgres Advanced Server (EPAS) database version 18 in a FIPS-enforced environment, the connection may fail with the Migration Portal UI error: Failed to connect: Failed to initialize pool: SSL error: Cannot decode named group: x25519. This is due to the FIPS environment enabled for the Hybrid Manager Migration Portal.

This issue occurs because Postgres 18 defaults to the x25519 SSL group, which is currently not supported by certain components used by the Migration Portal application. This issue specifically affects the Online Migration option, where the destination database is either an HM-managed EPAS database cluster or self-managed EPAS database.

Workaround: To resolve the connection failure, you must manually update the supported SSL groups list on the destination database cluster to include only FIPS-compliant NIST curves (such as prime256v1).

Other known issues

Data migrations supported without a Load Balancer in RHOS environments only

Description: The primary method for exposing Kafka (which is required for data migrations) within Hybrid Manager is via Load Balancers (an exception is the RHOS environment, where a native route is used to expose Kafka). Therefore, in non-RHOS environments where the Load Balancer is disabled, the data migration workflows will not function, as there is no fallback mechanism to support exposing Kafka using NodePort mode.

Workaround: To enable data migration workflows in non-RHOS environments such as RKE, you must configure a Load Balancer.