Conversion Studio

Design the target before you copy a single row

Conversion Studio is the workflow for moving between engines Oracle to PostgreSQL, SQL Server to PostgreSQL, MongoDB to MySQL, a relational source into Snowflake. The product is the model review, not a black-box copy job.

Oracle to PostgreSQL SQL Server to PostgreSQL

Workflow

Analyse, draft, override, run

Source analysis

Discover entities and relationships, count records, and lift the source into a model the draft is built from. Nothing is proposed for the target until the source has been read and understood.

Draft target and mapping

Generate a target schema for the destination engine. Review it as a model, a field-mapping table, an ER diagram, and the DDL that would run. Nested MongoDB documents can become parent and child tables, or selected fields can stay as JSON.

Overrides stay in the plan

Rename fields, change logical types, ignore columns, force JSON fallback, split nested objects. Re-preview until the generated schema is the one you will live with after cutover.

Run with validation

One-time full load, or CDC on engines that have it. Live progress, written and rejected counts, rejected samples, run history, and per-entity validation after execution.

Sources and targets

Relational, document and warehouse engines, each drafted with the types and the shape that the target actually uses. Tell us your pair and we will draft it with you.

Cutover

A one-time full load, or a snapshot followed by change passes where the source exposes a change stream and your DBA has it enabled. Warehouses are loaded, not tailed.

Strongest type mapping

The tested declared-type matrix covers MySQL, MariaDB, PostgreSQL, and SQL Server. Oracle and Snowflake use engine-specific mapping that you should review more carefully.

Licensing

Same-engine and cross-engine conversion are licensed separately. Family pairs such as MySQL to MariaDB count as cross-engine.

Not converted

The parts a migration still owns

Procedural code

PL/SQL packages, T-SQL procedures, and engine-specific triggers are not translated automatically. Migratrix moves structure and data; application SQL still has to be rewritten.

Permanent replication

CDC here shortens a cutover window. If you need an ongoing streaming pipeline between systems, use a dedicated CDC platform.

Some shapes do not carry over

Where the target engine has no equivalent for part of your schema no foreign keys, no enforced constraints, no indexes, a different data model entirely the draft shows you that before anything runs. The supported databases page lists what each engine rules out.

The rail

Analyze, Draft, Run, Validate

Those four words are the section titles in the product. Draft is where you spend the time: target model, objects, field overrides, ER diagram, and schema preview. Review and Plan exist as names in the code and are not shown as tabs.

Control	What it does
Live mode	One-time full load, or Change Data Capture labelled in the UI as zero-downtime. CDC defaults: snapshot first, slot name `migratrix_cdc`, change batch 500, poll every 1,000 ms, at most three change passes. Teardown-on-complete is off unless you turn it on.
Run mode	Schema and data as a full run, schema only as step 1 of 2, or data only as step 2 of 2. Apply-schema-before-run defaults to on.
Field overrides	Ignore, force JSON, rename, or set a target logical type. Structural choices for nested data: default, flatten, child table, or JSON.
Written / rejected	Live counters during the writing phase, then per-entity Read / Written / Rejected on Validate, with expandable rejected samples and a reason code.
Enum detection	Considers a column an enum candidate up to 20 distinct values during analysis. Raise that only if your lookups are wider.
Licensing	Same-engine conversion opens the workflow. Cross-engine conversion, where the target is a different engine from the source, is a Scale capability.

Engine matrix Oracle to PostgreSQL SQL Server to PostgreSQL MongoDB to MySQL Code impact after the move