About Ispirer Systems
Ispirer Home Page Ispirer Data Migrator Database Migration
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):
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:
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:
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:
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:
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:
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:
Click Next button to continue. Upon successful field entry and Database Connection Verification, the Select Objects page will open.
If a connection error occurs:
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:
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:
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):
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:
Table Validation Statuses:
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:
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 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):
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:
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:
Pause project button:
Soft Stop project button:
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:
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:
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:
Current Iteration panel helps you navigate alternative scenarios as they arise during migration:
Completed Migration panel displays the following information:
Migration Dynamics charts display:
Deleted & Upserted Rows chart shows metric values for completed iterations.
Values are updated after each iteration is completed.
Iteration Time chart shows metric values for completed iterations.
Values are updated after each iteration is completed.
Tables Completed chart shows metric values for completed iterations.
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 |