Migration with Forge
Migrate the code, not just the tables
Forge moves Oracle, Teradata, SQL Server and SAS estates to BigQuery, Cloudera, PostgreSQL, AlloyDB or Oracle — procedures, views, functions, triggers and scheduler jobs included — and proves each object by running both sides and comparing the results.
From
- Oracle
- Teradata
- SQL Server
- SAS
To
- BigQuery
- Cloudera (Iceberg, Impala, PySpark)
- PostgreSQL / AlloyDB
- Oracle
An Oracle procedure translated to BigQuery: the first deploy is refused because BigQuery has no SELECT … INTO, Forge repairs it from the error and deploys it in 1.1 seconds.
How a migration runs
- 01
Assess
A report from the source catalog and each object's own code: what migrates on its own, what needs a decision, what is not migrated and why, data volumes and load paths. No model call, no hour estimate.
- 02
Plan
Waves built from the dependency graph, so every object lands after what it uses. Large tables load in their own waves through Lakeflow.
- 03
Translate and deploy
Each object is translated for the target and deployed; when the target refuses it, Forge reads the error and repairs it, a bounded number of times. Low-confidence results wait for a person.
- 04
Prove
Row counts, aggregates and row fingerprints for tables. Views and functions run on both engines and their results are compared. Procedures run on the target and the tables they write are compared with the source.
- 05
Cut over
Scheduler jobs arrive as Lakeflow jobs in draft — activating them is the cutover, so nothing loads twice. Export the result as a dbt project if that is where it will live.
Measured
47 / 47
Our Oracle test estate migrated to AlloyDB with auto-waves: 34 of 34 objects migrated — tables, a package, procedures, functions, views, a trigger, materialized views and scheduler jobs — and 47 of 47 validations passed.
Where Forge stops and asks
Some things cannot be translated without a decision, and Forge holds them instead of guessing:
- a schedule cron cannot express, such as “last working day of the month”
- a row-by-row loop on BigQuery, where each iteration is a job — Forge proposes a set-based rewrite and you choose
- a materialized view refreshed on every commit
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.