About Ispirer Systems

Ispirer Home Page Ispirer Data Migrator Database Migration


Ispirer IDM User Guide

The Ispirer Data Migration (IDM) tool is a specialized solution designed for seamless, efficient data migration from Oracle to PostgreSQL.

It emphasizes high-speed data transfer while minimizing business downtime through an iterative, controlled migration approach.

A controlled migration approach ensures data consistency between the source and target systems, even as ongoing changes occur on the source during the primary data load.

The solution runs entirely on the PostgreSQL side using Foreign Data Wrappers, does not require installing anything on the Oracle server, and interacts with the source in read-only mode. It supports parallel processing and achieves a typical throughput of 250+ GB/hour per stream (depending on hardware, network, data types).

The GUI provides an intuitive interface for managing projects, configuring connections, selecting tables, monitoring progress, and controlling the migration process without requiring deep SQL expertise.

The list of supported databases, which can serve as both source and target for your data migration, is shown in the table below.

Source Databases Oracle RDBMS (version11andabove)
Target Databases PostgreSQL RDBMS (version 14 and above)*

*Includes PostgreSQL-compatible forks and managed cloud services, such as AWS RDS, Amazon Aurora, GCP AlloyDB, Azure Database for PostgreSQL, Postgres Pro, and similar platforms

The IDM Home page displays a list of all created projects along with their associated license information.

Each Project panel shows (if provided):

  • Project name
  • Description
  • License details
  • An option to delete the project via the overflow menu

Delete button removes the project metadata: control schema, migration ledger tables, and all temporary resources from the target PostgreSQL database. This action is irreversible and should only be performed after migration is fully completed and the target schema is ready for production use.

The License Information panel on each project card displays:

  • Source and target database types
  • Estimated project data volume
  • Licensed data usage (used and available GB) for that project

Each project in the list retains its last configured migration state (Running or Stopped) and continues processing in the background according to the status of its tables and consistency mode when the project was last accessed or closed.

The license key for each project is entered during project creation and is bound to that project.

All data migration operations are performed within projects.

To create a new project, click + Add New Project button on the Home page. The Project Creation page will then open.

On this page, enter the following information:

  • Project name required field. Enter a unique project name.
  • Schema name field. Auto-filled schema name that will be created on the target database to store migration control tables and metadata. It is automatically removed when the project is deleted.
  • Project summary optional field. Short summary of the project goals and scope.

After filling in the required fields, click Create Project button to continue. Upon successful field entry, the Target Database Setup page will open.

Use the Setup Checklist panel to guide you through the essential steps and pages required to launch your project.

On the Target Database Setup page, enter the connection details for the target PostgreSQL database:

  • Host* field. The network address of the target database server where migrated data will be stored.
  • Port* field. The TCP port number used to establish a connection to the target database server.
  • Database Name* field. The name of the target database to which the data will be migrated.
  • Root Username* field. The database user account with superuser privileges (typically the postgres user or another superuser). This account is used during project setup to install extensions, create the control schema, user mappings, and other migration infrastructure.
  • Root Password* field.The password for the specified database user account.

Note: The target database must be created and available before the project starts.

Important. Ensure the following utilities are installed and configured:

Target Databases Required target extensions
must be installed manually by the superuser before setup
PostgreSQL RDBMS (version 14 and above) Postgres_fdw
DBlink
Oracle_fdw
PG_cron
Plv8

After entering the details, click Next button to continue. Upon successful field entry and database connection verification, the License Setup page will open.

Note: All installation steps below should be executed as Postgres RDBMS superuser, formally known as Postgres. It is needed only for installation purposes, and further effective operation of the IDM solution does not require any redundant administrator privileges.

Alternative credential fields are for a migration-only user, allowing data migration with minimal privileges and without administrative configuration rights.

Note: If a connection error occurs:

  • Double-check host, port, credentials, and network/firewall settings.
  • Ensure the required extensions are installed (run CREATE EXTENSION commands as superuser if needed).
  • Check that the target server is available and visible.

Contact support if the issue persists.

All data migration operations are performed within the license data usage.

On the License page, enter the following info:

  • Key license field. The unique key that authorizes the product and defines the allowed data volume for migration operations.

Click Activate button to continue. The license key is verified, and the License Details section is displayed on the same page.

Note: License verification is performed online by connecting to the to Ispirer's license server; an active internet connection is required on the user's machine.

The License Details panel shows the source and target types, expiration date, maximum allowed project data volume, and current licensed data usage (used and available GB) for this key.

Click Next button to continue. The Source Database Setup page will open.

Note: If your license has expired, you encounter any license-related issues, or have questions, please request a new license or contact us via www.ispirer.com

Also, you can book the demo and get the IDM demo license at www.ispirer.com/data-migration

On the Source Database Setup page, enter the following info:

  • Service* field. The name of the database service or instance used to connect to the source database.
  • Host* field. The network address of the source database server from which data will be migrated.
  • Port* field. The port number used to connect to the source database server.
  • Username* field. The database user account used to read data and capture changes from the source database.
  • Password* field. The password for the specified database user account.

Click Next button to continue. Upon successful field entry and Database Connection Verification, the Select Objects page will open.

If a connection error occurs:

  • Verify host, port, service name, credentials, and network connectivity.
  • Ensure the Oracle user has the minimum required privileges (see below).
  • Confirm that TNS resolution works and the listener is running.

Contact support if the issue persists.

Note: When specifying the database username and password on this page, you need sufficient privileges to successfully execute SELECT statements on system tables of the source database.

Important. Ensure that the source database user privileges are properly configured.

Note: To connect to the source database, a dedicated database user with sufficient privileges is also required; the sections below describe the minimum required permissions and provide detailed instructions for configuring them if needed.

To prepare the source-side Oracle RDBMS server, It should be visible via the network from the target server, such as:

  • Underlying connection should be allowed by firewalls
  • Database instance name should be resolved by the TNS listener in the Oracle client
  • Access rights to the appropriate database and schemata should be granted
  • Session privileges, like creating connections and reading system catalogs, should be provided

GRANT CREATE SESSION TO ORACLE_USER; GRANT CONNECT TO ORACLE_USER;

On the source Oracle-side, the migration user `ORACLE_USER` should have appropriate read-only SELECT and FLASHBACK privileges on migrating tables and the system dictionary:

GRANT SELECT, FLASHBACK ON migrating_schema.migrating_table TO ORACLE_USER;

  GRANT SELECT, FLASHBACK ON ALL_TAB_COLUMNS TO ADMIN;
  GRANT SELECT, FLASHBACK ON all_objects TO ORACLE_USER;
  GRANT SELECT, FLASHBACK ON dba_tables TO ORACLE_USER;
  GRANT SELECT, FLASHBACK ON dba_extents TO ORACLE_USER;
  GRANT SELECT, FLASHBACK ON dba_segments TO ORACLE_USER;
  GRANT SELECT, FLASHBACK ON dba_indexes TO ORACLE_USER;
  GRANT SELECT, FLASHBACK ON dba_lobs TO ORACLE_USER;
  GRANT SELECT, FLASHBACK ON V_$DATABASE TO ORACLE_USER;

To skip non-modified tables quickly and conserve resources, provide additional privileges. IDM solution does not use `ANALYZE` privilege for recalculation statistics on tables or another heavy-weighted operations, but only for flushing already collected datum

  GRANT SELECT, FLASHBACK ON ALL_TAB_MODIFICATIONS TO ORACLE_USER;
  GRANT SELECT, FLASHBACK ON ALL_TAB_STATISTICS TO ORACLE_USER;
  GRANT SELECT, FLASHBACK ON V_$LOCKED_OBJECT TO ORACLE_USER;
  GRANT SELECT, FLASHBACK ON V_$TRANSACTION TO ORACLE_USER;
  GRANT ANALYZE ANY TO ORACLE_USER;

A migration project is created empty and does not contain a list of objects for data migration.

On the Source Tables Selection page, the user needs to select which objects to include in the migration scope from the source database:

  • Select objects checkbox from the object tree. Browse the object tree on the left side of the page.
  • Expand schemas and select the desired tables (or entire schemas).
  • Check the box next to each table/schema you want to migrate.
  • To exclude an object, simply uncheck its box
  • Clear checkbox. To remove an object from the selected list if needed.

Click Next button to continue. Upon successful entry, the Target Tables Processing page will open.

On the Target Tables Processing page, configure and verify the target-side structures for the selected source tables. This step ensures that target tables exist (or are created), column mappings are correct, data types are compatible, and everything is ready for data migration.

Available actions (buttons per schema or per table):

  • Create button. Automatically creates the target schemas (if missing) and target tables for all selected source objects. Tables are created empty, without constraints, without indexes, and with triggers disabled – this is the standard preparation state for migration
  • Validate button. Runs compatibility and mapping validation on the created (or existing) target tables. Validation checks:
    • Correct mapping of source-to-target columns
    • Supported data types
    • No critical conflicts (e.g., unsupported types without custom formulas)
    • Readiness for adoption into the migration process

Click Create All and Validate All button for each schema or table included in the project scope. Wait for the validation status of each table to confirm successful execution.

Table Creation Statuses:

  • Created. The table was successfully created in the target database by the system.

  • Already exists. The table already exists on the target database and can be reused for migration.

  • Error. The table could not be created due to an error and requires user attention before proceeding.



Table Validation Statuses:

  • Ready for migration. The table has passed validation and will be included in the migration project after final setup.

  • Error. The table failed validation and cannot be included in the migration until the issue is resolved.



Note: The target table names and columns are typically converted to lowercase by default. If you used manual import/adoption earlier (e.g., via SQLWays), existing tables can be validated without recreation. Only tables with the Ready for migration status will be included in the migration process.

Only validated tables are included in the final migration scope.

The Setup Checklist panel displays the total data volume for all validated tables as Validated Tables Size. The calculation is based on the source database size. The final migrated data size may vary slightly in the target database.

Click Finalize Setup button to continue. Upon successful validation, the Migration project page will open.

Important. After finalizing the setup, the source and target connections and the selected migration scope are locked, and migration proceeds using the validated objects only for this project.

After completing the setup steps, the project configuration is locked and applied to the selected migration scope.

Migration is then performed and managed within this defined scope from the Migration Project page (also called the project dashboard or workspace), which is opened at this stage.

The workspace includes the following main components:

  • Object Tree panel displays the hierarchy of schemas and tables included in the migration scope.

  • Main project control buttons allow you to manage the migration process at the project level.

  • Project metrics on the current and completed iterations panels provide high-level visibility into migration progress and results.

  • Detailed Migration Dynamics charts visualize iteration-based metrics, including processed rows, iteration duration, and table completion.

The Object Tree panel is a sidebar that displays the project object hierarchy, organized by schemas and the tables they contain.

When a schema is expanded, each table is shown with a dedicated card\component that includes the following information:

  • Table Name field. The table name, as defined during the project Create and Validate configuration.
  • Table Consistency Mode dropdown. The configured consistency mode; after migration starts, this field displays the progress indicator.
  • Iteration Number field. Current or last completed iteration number (appears after migration starts).
  • Table Status field. The current migration status of the table.
  • Table Actions buttons. Buttons to Start / Pause / Stop / Resume the individual table.

Table Consistency Mode dropdown. Select the mode via the dropdown in each table card or globally at the project level (only available while tables are in Stopped state):

  • Full consistency option. Data is read from the source at a fixed consistency point (SCN) and becomes visible on the target only after the iteration completes. All migrated tables are exposed atomically and in a fully consistent state at the end of the iteration.
  • Partial consistency option. The most recent data is continuously read from the source and becomes visible on the target immediately during the iteration. Consistency is maintained per table, while changes may be applied asynchronously within the iteration.

The consistency mode can be set globally for the project or individually per table, and is available only while the project or the selected table is in the Stopped state.

Table Status field. The current migration status of the table:

  • Running. The table is actively participating in the current iteration, and migration processing is in progress.

  • Waiting. The table has completed processing for the current iteration and is waiting for other tables to finish before the next iteration begins.

  • Finalizing. The table is completing processing as part of a soft stop and will finish the current iteration before migration is stopped. This status is distinguished via a tooltip.

  • Paused. Migration processing for the table is temporarily paused and will not continue until it is manually resumed.

  • Stopped. Migration processing for the table is stopped, and the table is not participating in migration. A table in this state may skip iterations and rejoin migration when the project is running.

  • Error (Retriable). The table encountered an error that blocks the start of the next iteration. The error must be resolved, or the affected table must be stopped before migration can continue.

  • Error (Aborted). The table encountered an error that caused the current iteration to be aborted for this table. Progress for the current iteration is lost, but the overall migration continues with the next iteration.

In addition to changing the consistency mode, you can access more advanced project-level tuning options.

Look for the Settings icon <> in the top-right corner of the Sidebar menu Migration Project.

Clicking this icon opens the Migration Parameters window – a configurable list of system-level parameters that control the overall behavior of the migration process, such as parallelism, batch sizing, error handling, and performance optimizations.

These settings apply globally to the. They allow fine-grained individual tuning for large-scale or complex migrations.

Review and configure system-level settings. The window displays a table with the following migration parameters (example values shown are defaults or typical starting points):

Migration Parameters Table

ID Parameter Default Value Purpose / Technical Description
0 MIGRATION_THREADS_POOL_SIZE 1 Maximum number of concurrent worker threads the migration engine can use on the PostgreSQL instance. All migration tasks share this thread pool.
1 WAIT_SECONDS_AFTER_ITERATION 3 Fixed delay (seconds) inserted after completion of each migration iteration before the next one can start. Prevents excessive iteration spawning on small/fast tables.
2 USE_MODIFICATION_STATISTICS_MODE ON Enables fast-skip optimization using Oracle’s modification statistics (ALL_TAB_MODIFICATIONS, ALL_TAB_STATISTICS, etc.). Skips tables with no recorded changes since last iteration. Requires appropriate FLASHBACK / SELECT privileges on Oracle system views.
3 VACUUM_TABLE_SIZE_GROWTH_FACTOR ≈2.2 Threshold multiplier: if table size after current iteration ≥ previous size × this factor, IDM triggers aggressive VACUUM FULL to combat table bloat caused by PostgreSQL MVCC dead tuples during heavy UPDATE/DELETE patterns.
4 MAX_CYCLES_IN_ONE_TASK_WORKER_PROCESS 15 Maximum number of batches a single worker process is allowed to process before forced restart (memory release + WAL flush).
5 MAX_ROWS_COUNT_IN_ONE_TASK_WORKER_PROCESS 1,000,000 Maximum number of rows processed by one worker before forced restart (for GC and WAL management).
6 MAX_ROWS_BYTES_IN_ONE_TASK_WORKER_PROCESS 1,000,000,000 (1 GB) Maximum data volume (bytes) processed by one worker before forced restart. Most important limiter for large objects (CLOB/BLOB) and wide rows.
7 MAX_SECONDS_IN_ONE_TASK_WORKER_PROCESS 900 (15 min) Maximum wall-clock time (seconds) a single worker is allowed to run before forced restart.
8 INTERNAL_RETRYABLE_ERROR_ATTEMPTS_COUNT 10 Number of automatic retry attempts inside the same batch for transient/retryable errors (network timeout, momentary locks, etc.) before marking the entire batch as failed. Intra-batch retry is significantly cheaper than full batch restart.
9 SUSPEND_THREAD_WORKER_TIMEOUT_SECONDS 0.01 Time interval (with sub-second precision) between checks for worker suspension requests (low-level threading control).
10 SUSPEND_THREAD_WORKER_SOFT_ATTEMPTS 100 Number of soft suspension attempts before the engine resorts to forceful thread termination.

Initial project state — all tables are in the Stopped status, the consistency mode is set to Partial Consistency, and only the Start button is available.

Consistency mode can be changed globally or per table, but only while all tables (or the selected table) remain stopped.

Migration can be started using Main project control buttons for all tables, or triggered individually for each table via Table Actions buttons in the object tree.

To start project migration, click the Start button. This initiates migration for all tables in the project according to the configured scope and consistency settings.

The following sections describe how to manage migration at both the project and table levels.

Main project control buttons control for managing migration at the project level.

Start project button:

  • Starts migration for all tables in Stopped or Paused table status.
  • After migration starts, the Start button is replaced with Pause button.
  • Migration can also be started individually for specific tables using table actions buttons.

Pause project button:

  • Temporarily pauses migration processing for all active tables.
  • Paused tables block iteration completion, and migration waits until they are resumed before starting the next iteration.

Soft Stop project button:

  • Initiates a controlled soft stop of the migration process.
  • The current and the next iteration are completed before migration is stopped, and you must wait until the process finishes.
  • All active tables enter the Finalizing status and complete their iterations before stopping.
  • This action is available only when no tables are in an Error or Paused table status.

Stop project button: Immediately stops migration processing for all tables, regardless of their current status (Running, Waiting, Paused, or Error). Progress for the current iteration may be lost. After stopping, the Start button becomes available again. A confirmation warning is displayed before executing this action.

Table Actions buttons controls for managing migration at the table level.

Table actions for the selected table: Start, Paused, Stop buttons

Table action availability by table status:

  • Running statusPause, Stop buttons
  • Waiting statusStop button
  • Finalizing statusPause, Stop buttons (no action is required for this flow)
  • Paused statusStart, Stop buttons
  • Stopped statusStart button
  • Error (Retriable) status – Start, Pause, Stop buttons
  • Error (Aborted) status – Start, Stop buttons

Migration runs in the background (via pg_cron) in repeated iterations until manually stopped. Closing the GUI or browser does not stop migration – it continues in its last state (Running or Stopped). You can delete the entire project (including metadata and control schema) from the home page project card

Migration progress and performance in real time can be viewed on the dashboard, which includes:

  • Current Iteration panel
  • Completed Migration panel
  • Migration Dynamics charts

You can also verify migration progress and results directly on the source and target systems using your own database tools.

This allows you to inspect data, validate changes, and troubleshoot issues outside the application.

Current Iteration panel displays the following information:

  • Progress Bar element. Shows the current iteration number, estimated completion time, and migration progress percentage.
  • Upserted field. Number of rows inserted or updated during the current iteration. This includes rows where data on the source was changed compared to the previous iteration, specifically, newly created records or modified existing records.
  • Deleted field. Number of rows deleted in the current iteration. These are rows where data was deleted on the source compared to the previous iteration; the corresponding delete events were captured and applied to the target during the current iteration.
  • Table Status Progress Bar element. Displays the migration progress for the table based on its current status.

Current Iteration panel helps you navigate alternative scenarios as they arise during migration:

  • Stop Error Tables state. Stops migration processing for tables that are in an error state to prevent them from blocking the current or subsequent iterations.
  • Start All Paused Tables state. Resumes migration processing for all tables that are currently paused and allows them to continue participating in the current iteration.

  • License Expiration Update state. Indicates that the licensed data volume limit is approaching and notifies that the remaining migration capacity under the current license key is running low.
  • License Expired Update state. Indicates that the licensed data volume limit has been reached or exceeded and disables migration processing until the license is renewed or updated.

Completed Migration panel displays the following information:

  • Iteration Finished field. Indicates the total number of iterations that have been successfully completed during the migration process.
  • Data Migrated field. The total amount of data processed across all tables in all completed iterations during the migration process.
  • Total Time field. The total elapsed time spent processing all completed iterations of the migration.
  • Total Rows field. The total number of rows processed across all tables in all completed iterations, including upserted and deleted rows.
  • Total Upserted field. The total number of rows migrated across all completed iterations. This includes rows where data on the source was changed compared to the previous iteration, specifically, newly created records and modified existing records.
  • Total Deleted field. The total number of rows where delete events were detected on the source across all completed iterations. These delete events were captured and applied to the target during the migration process.
  • License Info element. Displays information about the current license, including the licensed data volume and its usage during migration.

Migration Dynamics charts display:

Deleted & Upserted Rows chart shows metric values for completed iterations.

  • X-axis: Iteration index.
  • Y-axis: Represents the measured value for deleted and upserted rows across all data tables participating in the iteration.

Values are updated after each iteration is completed.

Iteration Time chart shows metric values for completed iterations.

  • X-axis: Iteration index.
  • Y-axis: Represents the total processing time required to complete each iteration.

Values are updated after each iteration is completed.

Tables Completed chart shows metric values for completed iterations.

  • X-axis: Iteration index.
  • Y-axis: Represents the number of tables that successfully completed processing during each iteration.

Values are updated after each iteration is completed.

Operating System Windows 10, 11
CPU Intel Pentium 4 or higher with SSE3 support
Memory At least 1GB of free memory (4GB recommended)
Free space At least 700 MB of free space