// SQL Server to PostgreSQL migration
Move from SQL Server to PostgreSQL.
Pick the conversion path that fits the application, then keep one team for support.
There are two honest ways off SQL Server. You can convert the schema and T-SQL to native PostgreSQL, or you can keep much of the T-SQL and run it through Babelfish. OSSeva assesses which fits each application, moves the data with tools such as pgloader, runs old and new side by side, and supports the PostgreSQL cluster from the day you cut over. It suits teams whose SQL Server estate sits behind applications they own.
Trusted globally by enterprises




Why SQL Server migrations are harder than they look
Moving the tables is the easy part. The work is in the code and the connections.
T-SQL is not PL/pgSQL
Stored procedures, functions and triggers written in T-SQL need conversion, and differences in temporary tables, identity columns, case sensitivity and error handling show up only when the code runs.
Babelfish is a real option with limits
Babelfish lets PostgreSQL accept SQL Server's wire protocol and T-SQL, so some applications move with fewer code changes. It supports a subset of T-SQL, and the open-source build depends on patches to community PostgreSQL, so it is a different engine to operate from standard PostgreSQL.
Applications and reports connect in many ways
Drivers, connection strings, ORMs, SSIS packages and reporting tools all point at SQL Server. Each one needs a tested path to PostgreSQL before cutover, or the migration stops at the first forgotten job.
What OSSeva delivers
Assess and choose a path
An inventory of databases, T-SQL objects and every client that connects. For each application we recommend native PostgreSQL or Babelfish and say why. Babelfish Compass, the project's assessment tool, helps on the Babelfish side.
Convert schema and T-SQL
pgloader discovers the SQL Server schema, including indexes and primary and foreign keys, and builds it in PostgreSQL. T-SQL procedures and functions are rewritten in PL/pgSQL and reviewed, or tested under Babelfish when that is the chosen path.
Migrate and validate data
Rehearsed loads with pgloader, with row counts and checksums compared on both sides and type casting rules written down for the columns that need them.
Run in parallel
Applications, reports and scheduled jobs run against PostgreSQL alongside SQL Server until the results match.
Cut over
A cutover runbook with a final sync, go and no-go checks and a rollback plan, run with your team in the change window.
Support from day one
Signed PostgreSQL builds, high availability with Patroni or repmgr, and on OSSeva Operate 24/7 monitoring with Critical CVEs (CVSS ≥ 9.0) patched within 48 hours and High within 7 days.
Your options, compared
| Option | What you get | Trade-off |
|---|---|---|
| Stay on SQL Server | No code changes | Licensing and the upgrade cycle stay as they are. |
| Babelfish for Aurora PostgreSQL | T-SQL and SQL Server clients on a managed AWS service, with few code changes for many applications | The database lives on Aurora, and unsupported T-SQL still has to be rewritten. |
| Aurora or RDS for PostgreSQL | A hosted target, with AWS DMS Schema Conversion for the schema and code | The database stays on that provider's service and support calendar. |
| OSSeva migration and support | Native PostgreSQL on your own infrastructure, migrated and then supported by one team | A services engagement followed by a subscription, priced per cluster. Self-managed Babelfish is not part of OSSeva support. |
pgloader behaviour from the pgloader MS SQL reference; Babelfish facts from babelfishpg.org, the babelfish_extensions repository and the Babelfish for Aurora PostgreSQL user guide; AWS DMS Schema Conversion paths from its user guide. All checked on 7 October 2026. OSSeva coverage from the OSSeva PostgreSQL technology page.
Frequently asked questions
Which tool should I use for SQL Server to PostgreSQL migration?
For data and schema, pgloader is free and open source, and it discovers the SQL Server schema including indexes and keys. For T-SQL code, there is no tool that converts everything, so plan for review and rewriting. If you want to keep most of the T-SQL, look at Babelfish. On AWS, DMS Schema Conversion handles SQL Server to Aurora or RDS for PostgreSQL.
Is there a free SQL Server to PostgreSQL migration tool?
Yes. pgloader is open source and loads SQL Server data into PostgreSQL with automatic schema discovery. Babelfish is also open source, under the Apache 2.0 and PostgreSQL licences.
How do I migrate Microsoft SQL Server to PostgreSQL using pgloader?
You point pgloader at the SQL Server source and the PostgreSQL target in a load command, add casting rules for any types that need them, and run it. It creates the tables, loads the data and then builds indexes and primary and foreign keys. Stored procedures are not part of that load, so convert them separately.
What is Babelfish for PostgreSQL?
An open-source project that lets PostgreSQL understand SQL Server's wire protocol and T-SQL, so applications written for SQL Server can connect with fewer changes. Its four extensions depend on patches to community PostgreSQL. AWS offers it as a managed feature of Aurora PostgreSQL.
Can we migrate SQL Server to Aurora PostgreSQL instead?
Yes. Babelfish for Aurora PostgreSQL and DMS Schema Conversion both target AWS's managed service, and that is a good choice if you want to stay on AWS-managed databases. OSSeva's offer is for teams that want PostgreSQL on infrastructure they control.
What are the main challenges?
T-SQL procedures that need rewriting, differences in case sensitivity, identity columns and temporary tables, and the number of clients, reports and jobs that connect to SQL Server directly.
Who is this for?
Teams moving SQL Server databases behind their own applications to PostgreSQL they run themselves, who want the migration and the support afterwards from one team.
Leave SQL Server on a path that fits each application.
Book a discovery call for an assessment plan and a quote. Support is priced per cluster.