Hard sources — not covered by free tools
Also parsed — certify what free tools miss
Runtimes
After migration
Not covered by Lakebridge, Cortex conversion, or BigQuery Migration Service. Targets delivered: Databricks, Snowflake, BigQuery.
Parser-driven modernization of ODI repository XML and Smart Export bundles — mappings, packages, load plans, and knowledge modules. Full lineage, automated conversion, validated parity.
ODI mapping parsed into interactive lineage graph
One source, every target. Deterministic parsers read the estate and emit native code for the platform you pick — not ODI mappings lifted into a hosted ODI.
Oracle ODI estate → MigryX parser → native platforms
Deterministic parseAI where it helpsThe parser is deterministic: the same input produces the same output on every run. Every output is validated against the original, row by row, before go-live.
A mapping shows intent, but the SQL that runs is generated by its IKM, LKM and CKM at execution time. Reading the mappings alone tells you what was meant, not what happened, which is why ODI estates are hard to inventory honestly.
Contexts, data servers, physical and logical schemas, and agents form an environment layer that lives outside the mappings. It has to be reproduced or replaced before a single converted job can run.
ODI development requires the Studio client and a master/work repository pair. Teams that inherited an ODI estate often have nobody who can safely change a KM, so the estate freezes and workarounds accumulate around it.
An incremental-update integration knowledge module with flow control. The mapping never states the staging table, the update key comparison, or the reject handling — the KM generates all of it. MigryX resolves the KM to the SQL it would have produced.
-- Mapping: LOAD_CUSTOMER_DIM
-- IKM: Oracle Incremental Update
-- LKM: SQL to Oracle
-- CKM: Oracle (flow control enabled)
Source datastores : CRM_CUSTOMER, CRM_ADDRESS
Join : CUSTOMER.ADDR_ID = ADDRESS.ADDR_ID
Filter : CUSTOMER.STATUS <> 'PURGED'
Target datastore : CUSTOMER_DIM
Update Key : CUST_NK
Mappings : FULL_NAME = FIRST_NM || ' ' || LAST_NM
CITY = ADDRESS.CITY
-- KM behaviour, not visible in the mapping:
-- 1. load into I$_CUSTOMER_DIM staging
-- 2. flow control writes violations to E$_CUSTOMER_DIM
-- 3. update matched rows, insert unmatched by CUST_NK
-- IKM Incremental Update → MERGE
CREATE OR REPLACE TEMPORARY TABLE i_customer_dim AS
SELECT c.cust_nk,
c.first_nm || ' ' || c.last_nm AS full_name,
a.city AS city
FROM crm_customer c
JOIN crm_address a ON c.addr_id = a.addr_id
WHERE c.status <> 'PURGED';
-- CKM flow control → explicit reject capture
INSERT INTO e_customer_dim
SELECT * FROM i_customer_dim WHERE cust_nk IS NULL;
MERGE INTO customer_dim t
USING (SELECT * FROM i_customer_dim
WHERE cust_nk IS NOT NULL) s
ON t.cust_nk = s.cust_nk
WHEN MATCHED THEN UPDATE
SET t.full_name = s.full_name, t.city = s.city
WHEN NOT MATCHED THEN INSERT
(cust_nk, full_name, city)
VALUES (s.cust_nk, s.full_name, s.city);
The I$ staging step, the E$ reject table from flow control, and the update-key comparison all become explicit SQL. What the KM used to generate at runtime is now readable code you can review and version.
Every ODI artifact in the export maps to a defined target equivalent, recorded in the lineage report.
| ODI Component | Target Equivalent | Notes |
|---|---|---|
| Mapping / reusable mapping | Transformation pipeline | Datasets, joins, filters and expressions |
| IKM (integration) | MERGE or insert/append | Incremental update resolved to an update key |
| LKM (load) | Staged extract and load | Loading strategy mapped to target staging |
| CKM (check) | Constraint checks and reject table | E$ error flow becomes explicit capture |
| Package | Ordered driver with step logic | Step sequence, ok/ko branches preserved |
| Load plan | Orchestrated DAG | Serial and parallel steps, restart points |
| Scenario | Versioned executable job | Generated scenario resolved to its source |
| Variable / sequence | Parameters and generated keys | Refresh queries and scope preserved |
| Procedure / SQL override | Parameterized SQL step | Multi-technology commands separated |
| Model and datastore | Target schema definition | Datatypes and constraints carried over |
| Topology / context | Environment config and secrets | Logical to physical resolution per context |
| Agent invocation | Scheduler entry | StartScen calls mapped to the orchestrator |
MigryX Data Matching compares ODI mapping output against the new pipeline output, row by row and column by column, with configurable tolerance rules and mismatch drill-down.
See how Data Matching works →A Smart Export from ODI Studio, or an XML export of the projects and models in scope. Smart Export is preferred because it follows dependencies and brings the related models, KMs and topology references with the mappings.
Custom KMs are parsed as first-class inputs rather than assumed to match the shipped versions. Because the KM determines the SQL that actually ran, a modified KM changes the generated output, and it is reported with the mappings that use it so the difference is visible before conversion.
Step order, ok/ko branching and restart points are carried into the target orchestrator. Where ODI relied on agent-level behaviour that has no direct equivalent, that step is flagged for review rather than silently approximated.
Yes. Export and convert one project or a set of mappings, validate to parity, and repeat. This matters in ODI estates because the topology layer can be reproduced once and reused across subsequent waves.