Stay organized with collections
Save and categorize content based on your preferences.
Legacy conversion workspaces are an older, more limited type of conversion
workspaces. Legacy conversion workspaces don't support Gemini-enhanced
conversion features or the interactive SQL editor. You can only use them to convert your
source schema with the Ora2Pg migration tool.
We don't recommend using the legacy type of conversion workspaces for your
migrations as they present multiple other limitations to the conversion
workflow:
Interactive conversion workspace
Legacy conversion workspace
Schema and code object conversion happens in Database Migration Service.
You perform schema and code object conversions outside
Database Migration Service by using the Ora2Pg migration tool.
You can apply converted sources to the destination database directly
in Database Migration Service.
You are responsible for applying the converted schema to the destination
database in your Cloud SQL for PostgreSQL destination instance.
You can test your draft schema and code directly in Database Migration Service
to ensure they can be successfully applied to your destination instance.
You can't test your draft schema and code without affecting
the destination instance.
Automatically adds missing rowid columns for tables that
don't have primary keys and unique constraints.
You must add missing primary keys to destination tables after you
apply the schema.
Table 1: Conversion workspace feature comparison
Use legacy conversion workspaces
If your scenario requires the use of legacy conversion workspaces,
modify the migration process with the following actions:
Write an Ora2Pg configuration file.
Refer to the
Ora2Pg documentation for guidance on how to use
the Ora2Pg conversion tool. Expand the following sections for the full
list of directives supported in Database Migration Service.
Ora2Pg configuration supported in Database Migration Service
Database Migration Service supports the following configuration items for Ora2Pg files:
BOOLEAN_VALUES
DATA_TYPE
DEFAULT_NUMERIC
ENABLE_MICROSECOND
EXPORT_SCHEMA
MODIFY_STRUCT
MODIFY_TYPE
PG_INTEGER_TYPE
PG_NUMERIC_TYPE
PG_SCHEMA
PRESERVE_CASE
REPLACE_AS_BOOLEAN
REPLACE_COLS
REPLACE_TABLES
REPLACE_ZERO_DATE
SCHEMA
Database Migration Service uses connection profiles to define
connectivity details, so you don't need to define the following information
in your Or2Pg configuration file:
ORACLE_DSN
ORACLE_HOME
ORACLE_PWD
ORACLE_USER
PG_DSN
PG_PWD
PG_USER
Additionally, Database Migration Service doesn't use the WHERE
configuration directive to limit the records to migrate.
Manually apply converted schema to the destination database.
After you create the Ora2Pg configuration and create the workspace,
you must apply the generated code by yourself directly on the destination
database.
Migrate tables without primary keys.
Database Migration Service migrates only tables that have primary keys.
If your source database includes tables that don't have primary keys,
you need to manually create primary keys or unique constraints in the
converted tables in the destination database after you
apply the converted schema. Expand the following section for more details.
Add primary key constraints in the destination database
To migrate Oracle tables without primary keys, do the following:
Connect to your destination Cloud SQL instance with a SQL client. You
can use the following methods:
psql client. You can use this method to connect
to your instance private IP, but it might require that you create
a Compute Engine virtual machine.
gcloud sql connect command. This command
works only for Cloud SQL instances that have a public IP address
enabled.
Create the missing primary key constraints for your tables. For more
information about primary keys, see
Primary Keys in the PostgreSQL documentation.
You can also expand the following sections to see sample SQL commands:
Create primary keys using existing columns
Your table might already have a logical primary key based on a
column or a combination of columns. For example, there might be
columns with a unique constraint or index configured. Use these
columns to generate a new primary key for tables in your source
database. For example:
ALTERTABLETABLE_NAMEADDPRIMARYKEY(COLUMN_NAME);
Create a primary key using all columns
If you don't have a pre-existing constraint that could serve as a
primary key, create primary keys using all columns of the table. Make
sure that you don't exceed the maximum length of the primary key
allowed by your PostgreSQL instance. For example:
When creating a composite primary key like this, you need to explicitly
list all column names you want to use. It's not possible to use a statement
to retrieve all column names for this purpose.
Create a unique constraint with the ROWID pseudocolumn
Oracle databases use the
ROWID pseudocolumn to store
the location of each row in a table. To migrate Oracle tables
that don't have primary keys, you can add a ROWID
column in the destination PostgreSQL database. Database Migration Service
populates the column with the corresponding numeric values from
the source Oracle ROWID pseudocolumn.
To add the column and to set it as the primary key, run the following:
After you perform the conversion workflow with the legacy workspace,
you can proceed with the standard migration procedures. See
Create a migration job.
[[["Easy to understand","easyToUnderstand","thumb-up"],["Solved my problem","solvedMyProblem","thumb-up"],["Other","otherUp","thumb-up"]],[["Hard to understand","hardToUnderstand","thumb-down"],["Incorrect information or sample code","incorrectInformationOrSampleCode","thumb-down"],["Missing the information/samples I need","missingTheInformationSamplesINeed","thumb-down"],["Other","otherDown","thumb-down"]],["Last updated 2025-08-25 UTC."],[],[],null,["# About legacy conversion workspaces\n\nLegacy conversion workspaces are an older, more limited type of conversion\nworkspaces. Legacy conversion workspaces don't support Gemini-enhanced\nconversion features or the interactive SQL editor. You can only use them to convert your\nsource schema with the Ora2Pg migration tool.\n| **Important:** Database Migration Service supports Ora2Pg versions `21.1` - `23.2`.\n\nWe don't recommend using the legacy type of conversion workspaces for your\nmigrations as they present multiple other limitations to the conversion\nworkflow:\n\nUse legacy conversion workspaces\n--------------------------------\n\nIf your scenario requires the use of legacy conversion workspaces,\nmodify the migration process with the following actions:\n\n1. Write an Ora2Pg configuration file.\n\n Refer to the\n [Ora2Pg documentation](https://ora2pg.darold.net/documentation.html#CONFIGURATION) for guidance on how to use\n the Ora2Pg conversion tool. Expand the following sections for the full\n list of directives supported in Database Migration Service. \n\n #### Ora2Pg configuration supported in Database Migration Service\n\n Database Migration Service supports the following configuration items for Ora2Pg files:\n - `BOOLEAN_VALUES`\n - `DATA_TYPE`\n - `DEFAULT_NUMERIC`\n - `ENABLE_MICROSECOND`\n - `EXPORT_SCHEMA`\n - `MODIFY_STRUCT`\n - `MODIFY_TYPE`\n - `PG_INTEGER_TYPE`\n - `PG_NUMERIC_TYPE`\n - `PG_SCHEMA`\n - `PRESERVE_CASE`\n - `REPLACE_AS_BOOLEAN`\n - `REPLACE_COLS`\n - `REPLACE_TABLES`\n - `REPLACE_ZERO_DATE`\n - `SCHEMA`\n\n Database Migration Service uses connection profiles to define\n connectivity details, so you don't need to define the following information\n in your Or2Pg configuration file:\n - `ORACLE_DSN`\n - `ORACLE_HOME`\n - `ORACLE_PWD`\n - `ORACLE_USER`\n - `PG_DSN`\n - `PG_PWD`\n - `PG_USER`\n\n Additionally, Database Migration Service doesn't use the `WHERE`\n configuration directive to limit the records to migrate.\n2. [Create a legacy conversion workspace, and upload the Ora2Pg file to convert\n your schema](/database-migration/docs/oracle-to-postgresql/create-conversion-workspace#legacy-ws).\n3. Manually apply converted schema to the destination database.\n\n\n After you create the Ora2Pg configuration and create the workspace,\n you must apply the generated code by yourself directly on the destination\n database.\n | **Important:** With legacy conversion workspaces, you can't test the schema before you migrate. If you encounter any issues when you apply the converted schema, you need to clear the faulty schema from the destination database, adjust your Ora2Pg file, and re-create the legacy conversion workspace with the Ora2Pg file.\n4. Migrate tables without primary keys.\n\n\n Database Migration Service migrates only tables that have primary keys.\n If your source database includes tables that don't have primary keys,\n you need to manually create primary keys or unique constraints in the\n converted tables in the destination database after you\n apply the converted schema. Expand the following section for more details. \n\n #### Add primary key constraints in the destination database\n\n To migrate Oracle tables without primary keys, do the following:\n 1. Connect to your destination Cloud SQL instance with a SQL client. You can use the following methods:\n - [`psql` client](/sql/docs/postgres/connect-admin-ip). You can use this method to connect to your instance private IP, but it might require that you create a Compute Engine virtual machine.\n - [`gcloud sql connect`](/sdk/gcloud/reference/sql/connect) command. This command works only for Cloud SQL instances that have a public IP address enabled.\n 2. Create the missing primary key constraints for your tables. For more information about primary keys, see [Primary Keys](https://www.postgresql.org/docs/current/ddl-constraints.html#DDL-CONSTRAINTS-PRIMARY-KEYS) in the PostgreSQL documentation.\n\n You can also expand the following sections to see sample SQL commands: \n\n #### Create primary keys using existing columns\n\n Your table might already have a logical primary key based on a\n column or a combination of columns. For example, there might be\n columns with a unique constraint or index configured. Use these\n columns to generate a new primary key for tables in your source\n database. For example: \n\n ```sql\n ALTER TABLE TABLE_NAME\n ADD PRIMARY KEY (COLUMN_NAME);\n ```\n\n \u003cbr /\u003e\n\n #### Create a primary key using all columns\n\n If you don't have a pre-existing constraint that could serve as a\n primary key, create primary keys using all columns of the table. Make\n sure that you don't exceed the maximum length of the primary key\n allowed by your PostgreSQL instance. For example: \n\n ```sql\n ALTER TABLE TABLE_NAME\n ADD PRIMARY KEY (COLUMN_NAME_1, COLUMN_NAME_2, COLUMN_NAME_3, ...);\n ```\n\n When creating a composite primary key like this, you need to explicitly\n list all column names you want to use. It's not possible to use a statement\n to retrieve all column names for this purpose. \n\n #### Create a unique constraint with the `ROWID` pseudocolumn\n\n Oracle databases use the\n [`ROWID` pseudocolumn](https://docs.oracle.com/en/database/oracle/oracle-database/19/sqlrf/ROWID-Pseudocolumn.html) to store\n the location of each row in a table. To migrate Oracle tables\n that don't have primary keys, you can add a `ROWID`\n column in the destination PostgreSQL database. Database Migration Service\n populates the column with the corresponding numeric values from\n the source Oracle `ROWID` pseudocolumn.\n\n To add the column and to set it as the primary key, run the following: \n\n ```sql\n ALTER TABLE TABLE_NAME ADD COLUMN rowid numeric(33,0) NOT NULL;\n CREATE SEQUENCE TABLE_NAME_rowid_seq INCREMENT BY -1 START WITH -1 OWNED BY TABLE_NAME.rowid;\n ALTER TABLE TABLE_NAME ALTER COLUMN rowid SET DEFAULT nextval('\u003cvar translate=\"no\"\u003eTABLE_NAME\u003c/var\u003e_rowid_seq');\n ALTER TABLE TABLE_NAME ADD CONSTRAINT CONSTRAINT_DISPLAY_NAME PRIMARY KEY (rowid);\n ```\n\nWhat's next\n-----------\n\nAfter you perform the conversion workflow with the legacy workspace,\nyou can proceed with the standard migration procedures. See\n[Create a migration job](/database-migration/docs/oracle-to-postgresql/create-migration-job)."]]