The most predictable relational conversion we ship
SQL Server and PostgreSQL both sit in the test-covered type-mapping matrix. Conversion Studio still makes you review the target model, field mapping, and DDL before a row moves. CDC is available on this path, so the cutover window can be a snapshot plus change passes rather than a long full load.
Four stages, each reviewable
Nothing touches PostgreSQL until you have approved the model it will create.
Analyse the SQL Server source
Read tables, types, identity columns, and relationships into a canonical model, with row counts so the load plan is sized against real data rather than a guess.
Draft the PostgreSQL target
Generate a proposed PostgreSQL schema from the declared-type matrix. Review it as a target model, a field mapping table, an ER diagram, and the DDL that would run.
Override what is wrong
Rename fields, change logical types, ignore columns, or force JSON. Re-preview until the generated schema is the one you will operate after cutover.
Run with CDC or a full load
Execute with live progress, written and rejected counts, and per-entity validation. CDC defaults to snapshot first, then change passes, labelled in the product as zero-downtime.
What is automated, and what is not
| Aspect | Status on this path |
|---|---|
| Source schema discovery | Automated. SQL Server has a dedicated schema reader, displayed as MSSQL in the product catalogue. |
| Target schema generation | Automated. PostgreSQL has a dedicated draft generator and schema script generator. |
| Type mapping | Automated on the test-covered matrix that also covers MySQL and MariaDB. Review still recommended for edge types. |
| Change data capture | Available. Snapshot first, then change passes. Product defaults include slot name migratrix_cdc, change batch 500, poll every 1,000 ms, and at most three change passes. |
| Identity columns | Read from SQL Server and generated on PostgreSQL. Data comparison excludes identity columns by default so generated keys do not look like drift. |
| T-SQL procedures, functions, triggers | Not converted automatically. Migratrix moves structure and data. Application SQL still has to be rewritten. |
| Application query changes | Not automated, but risk assessment can index repositories and show which code touches the objects you are changing. |
Migration is the beginning, not the end
Schema and data comparison require the same engine on both sides. After the move, compare PostgreSQL to PostgreSQL. Do not expect a SQL Server versus PostgreSQL structural diff.
The PostgreSQL estate inherits promotion flows, approval gates, rollback generation, and the audit trail. The migration does not hand you a database with no change process around it.
Scheduled drift monitoring snapshots the new schema against a baseline. That matters most in the months after a migration, when everyone is still adjusting things.