Migration · From Oracle
From Oracle, PL/SQL and all
Packages, procedures, triggers, materialized views and scheduler jobs — not just tables. Forge moves an Oracle estate to PostgreSQL, AlloyDB, BigQuery or Cloudera, and proves each object by running both sides.
Measured
34 / 34
objects migrated
Our Oracle test estate to AlloyDB with automatic waves: tables, a package, procedures, functions, views, a trigger, materialized views and scheduler jobs.
47 / 47
validations passed
Row counts, aggregates, date profiles and parity of views and functions — every one green.
What Forge migrates
The whole schema, not only its tables
- Tables and sequences
- Structure, types and defaults, then the data.
- Packages and procedures
- A package becomes its routines on the target; each is deployed and, if refused, repaired from the error.
- Triggers
- Rebuilt as triggers on PostgreSQL, firing on the same events with the same rules.
- Materialized views
- On PostgreSQL with a refresh job; on BigQuery in the form BigQuery accepts, refreshed on Oracle's own schedule.
- Scheduler jobs
- Become Lakeflow jobs with their calendar — switched off until you cut over.
- Old Oracle versions
- Read through the Spark cluster you already have, without installing an Oracle client.
Where Forge stops and asks
- A schedule a cron expression cannot state — “last working day of the month” — is left for you instead of approximated.
- A materialized view refreshed on every commit has no direct equivalent and waits for a decision.
See it on your own data
We'll set up Qry against a dataset you choose and walk you through it — one hour, no slides.