Before migrating data, your schema must be present on the destination database. There are two ways to handle this, and both start with opening your Migration Portal project and resolving any compatibility issues:
Simplified (recommended): Use Migration Portal to resolve incompatibilities only, then let Hybrid Manager (HM) import the schema as part of the migration. HM manages constraint ordering automatically — no manual constraint handling required. Select Schema and data as the migration scope when creating the migration.
Manual: Use Migration Portal to resolve incompatibilities and import the schema directly to the destination. You must manage constraint ordering yourself and reapply deferred constraints after data migration completes. Select Data only as the migration scope when creating the migration.
A third scope option, Schema only, is also available when creating a migration in HM. Use this if you want to migrate the database structure without migrating any table data — for example, to validate the schema on the destination before committing to a full migration.
Opening your Migration Portal project
The EDB Postgres AI agent automatically extracts the DDL from your Oracle source and makes it available in Migration Portal. Use Migration Portal to convert and migrate your Oracle schemas.
Prerequisites
You registered your Oracle database with HM via the EDB Postgres AI agent.
Optional: Your HM administrator enabled and configured the AI Copilot to help resolve schema incompatibilities in Migration Portal.
Accessing your project
After registering your Oracle database with the EDB Postgres AI agent, a Migration Portal project is created automatically — one per registered database, based on the resource_id in your beacon_agent.yaml.
Warning
Any DDL changes made after the Migration Portal project was created — including new schemas, new tables, updated tables, or deleted tables — are not reflected in the auto-created project.
To find your project:
Navigate to your Oracle database's detailed view. You can get there from either of these paths:
a. Estate > Migrations > [your database].
b. [your project] > Migrate > Databases > [your database].
Select the Schemas tab.
Select the project link in the MP Project column to open the Migration Portal's project-scoped workspace for this database.
If no project link appears in the MP Project column, the project wasn't created automatically. Expand the section below to create one manually.
Creating a Migration Portal project manually
Automatic project creation won't trigger if:
The ingested DDL exceeds the 300 MB default limit (or an administrator-configured customized limit).
Your Hybrid Manager administrators disabled automatic project creation.
See Managing Migration Portal projects for the steps to create — or delete — a project. Once the project is ready, a project link appears — select it to open Migration Portal and begin resolving incompatibilities using the AI Copilot or QuickHelp.
Converting schema and resolving compatibility issues
Use Migration Portal to convert your Oracle DDL to be compatible with EDB Postgres Advanced Server. Use the AI Copilot and QuickHelp to resolve any compatibility issues that arise during conversion. Additional resources:
- Using Migration Portal
- Enabling and configuring the AI Copilot in HM (administrator task)
- Migration Portal's AI Copilot
- Performing a schema assessment
Note
Migrated PL/SQL bodies (triggers, procedures, functions, and packages) retain unqualified object references from the Oracle source. Review these references in your converted DDL before importing to avoid runtime failures on the destination. See Unqualified object references in migrated PL/SQL bodies for details and workarounds.
Importing schema
After resolving all incompatibilities in Migration Portal, proceed to Configure the EDB Data Migration Service (DMS) agent. When you create the migration, select Schema and data as the scope — HM imports the converted schema with constraints applied in the correct order, and automatically reapplies deferred constraints after data migration completes.
After resolving all compatibility issues in Migration Portal, import the schema into the destination database.
Handling constraints
Import constraints in stages to avoid performance degradation during migration:
Include now (before data migration):
NOT NULLconstraints. These constraints have negligible performance impact and no conflict risk during the snapshot phase.Exclude now — DMS applies automatically: primary key (PK) constraints. The DMS writer applies the primary key after each table's snapshot completes (delayed-PK behavior), using it to deduplicate snapshot data. Don't import PKs manually.
Exclude now, apply after streaming starts: unique key (UK) constraints on tables that have a primary key. PK-based deduplication during the snapshot ensures no duplicate rows exist when you apply these constraints.
Exclude now — apply post-snapshot with deduplication: unique key (UK) constraints on tables that have no primary key. See UK-identity tables below for source preparation and the post-snapshot procedure. Don't create these constraints on the destination before the snapshot completes.
Exclude now, reapply after migration: foreign key, check, and exclusion constraints. These constraints cause unnecessary CPU and memory overhead while data is actively being migrated.
When following the steps below, disable Constraints in Migration Portal to disable foreign key, check, and exclusion constraints. Primary key and unique constraints must also be excluded — confirm these constraints aren't applied during the import.
Note
PK and UK presence on the destination affects delivery semantics — without them, DMS falls back to at-least-once delivery. NOT NULL has no effect on delivery semantics.
Note
For tables without any key constraints, DMS provides at-least-once delivery. Deduplicate rows as part of your post-migration verification.
UK-identity tables: supplemental logging and post-snapshot constraints
A UK-identity table is a source table that has no primary key and uses a unique key as its only row identifier.
Before starting the migration, enable supplemental logging on the UK columns on the source Oracle database for each UK-identity table. DMS needs this logging to emit change events keyed by those columns so streaming works correctly after you add the constraint on the destination.
-- Run on the source Oracle database for each UK-identity table. ALTER TABLE <schema_name>.<table_name> ADD SUPPLEMENTAL LOG GROUP <log_group_name> (<col_1>, <col_2>) ALWAYS;
Don't create the unique constraint on the destination before the snapshot completes. With delayed-PK enabled, the DMS writer treats tables as keyless if they have no PK on the destination — even if a UK exists. Snapshot writes use plain INSERT operations with no conflict handling, and any retry before snapshot finishes will hit the UK constraint and cause an infinite retry loop.
After the snapshot for a UK-identity table completes, follow the deduplication and constraint procedure in Applying unique constraints on UK-identity tables.
Use this option when you don't need to rename any schemas, tables, or columns.
Select Migrate to > Online migration.
Select your schemas. In the object list beneath the database, disable Constraints. Select Next.
Enter the details of your destination cluster.
Find your cluster's information under Clusters > Postgres Clusters > [cluster name] > Connect.
Select Test connection to verify connectivity to the destination, then select Save and continue.
Select Next and wait for the import to complete.
Connect to the destination database and confirm the schemas are present.
Use this option when you need to map schemas, tables, or columns to different names in the destination.
Select Migrate to > Offline migration.
Select your schemas. In the object list beneath the database, disable Constraints. Select Next.
Select Download SQL file.
Edit the object names directly in the downloaded DDL. Ensure that renamed objects are also updated in any dependent views, constraints, or other references. See Mapping schemas, tables, and columns for details.
Connect to the destination database and apply the modified DDL file.