Modernize Without
the Big Bang
Moving the data is the easy part. Translating and re-proving the business logic is what stalls programmes. Keep the logic in portable rules, leave the data where it is, and run the same rules on old and new until the numbers match.
revenue_rules✓parity_check✓publish✓Proven in production
Lift and Shift.
Then Rewrite It All.
A big-bang migration copies the data, translates years of SQL and pipeline code into a new dialect, and asks the business to trust a cutover date. Prometheux separates the logic from the platform, so you modernize in steps and prove each one.
Connect. Define.
Run. Switch.
Connect Both Worlds
Connect the legacy and the target systems where they are. In-place processing means nothing is copied to get started.
Lift the Logic Out
Bring existing SQL into rules as it is, then refactor into shared definitions. See faster ETL.
Run Side by Side
Run the same rules against old and new and compare the results before anyone depends on the new system.
Switch in Steps
Move data with a short declarative rule, one domain at a time, and repoint. Every rule built on it keeps working. See fast migrations.
Logic That Outlives
the Platform
When the business logic is independent of where the data sits, a platform change becomes a connection change. The rules you prove today keep working on the next system.
Repoint, Don't Rewrite
Point a definition at its new location and everything built on it keeps working.
One Program, Many Sources
Join legacy and modern systems in the same rule and write results to either. See cross-database processing.
Deploy Where You Are
Cloud, private VPC or on-premises, natively on Databricks and alongside Snowflake. See portable cloud.
Proof Before Cutover
Run the same rules on both systems and compare outputs value by value. Where they differ, lineage shows the rules and sources behind each result.
Deliver value before the migration ends. Cut over when the numbers match, not on a date. Never rewrite the same logic twice.
Modernize
One Step at a Time
Move to Databricks Gradually
Analyze, test and transform data before, during or after the move, with the same rules running on both sides.
Prometheux on Databricks →Off the Mainframe
Read COBOL and legacy relational data and write it to modern formats such as Iceberg and Parquet, with the same rules.
Heterogeneous Data, One Model
Query heterogeneous research databases through one shared model instead of consolidating them first, as Dompé describes below.
Merge Data Estates
Map both companies' systems to shared definitions first, report across them on day one, then consolidate at your own pace.
“The ability to query heterogeneous databases through a flexible ontology makes it possible to infer deep knowledge and automate complex tasks, delivering trustworthy insights that far exceed the capabilities of traditional systems.”
Anna FavaFormer Senior Manager, Data & AI · Dompé
“Generative AI without ontologies is an engine without a road. Prometheux builds the road.”
Marco RomeiDeputy CIO · Banca Sella
Questions,
Answered
Do we have to migrate to use Prometheux?
No. Prometheux works across your existing databases, warehouses and platforms without mandatory migrations. When you do want to move data, it makes the move smaller and safer.
Where does the business logic live?
In a portable ontology: readable rules and shared definitions that are connected to your sources but not tied to any one platform's dialect. You keep them in version control and can export them through the API.
How is this different from migration or code translation tools?
Migration services copy data and convert schemas. Translation tools, increasingly AI-driven, rewrite old SQL or ETL jobs into a new dialect that you then validate and maintain. Prometheux keeps the logic out of the platform: you repoint the data and keep the rules, so there is nothing to translate and the same rules check parity. It can sit alongside a service that moves the bulk data.
What about the SQL we already have?
Rules can embed SQL bodies directly, so existing queries come across as they are and can be refactored into shared definitions over time.
Which systems can we run side by side?
Any pair of documented read and write connectors, including relational databases such as Oracle, SQL Server and PostgreSQL, Snowflake, Databricks, BigQuery, Redshift, Iceberg, Parquet and CSV.
Does it replace our orchestrator or ETL stack?
No. Rules can run on a schedule or be triggered from the orchestrator you already use through the REST API or Python SDK.
More Use Cases
Modernize in Steps.
Prove Every One.
Bring the migration that keeps slipping. We'll help you lift the logic out and run old and new side by side.
