// 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.

SQL ServerPostgreSQL 17PostgreSQL 18pgloaderBabelfish

Trusted globally by enterprises

Henry ScheinEnbridgeGojekMicrosoft

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

1

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.

InventoryPath per appWritten plan
2

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.

pgloaderPL/pgSQLBabelfish
3

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.

Data loadCasting rulesValidation
4

Run in parallel

Applications, reports and scheduled jobs run against PostgreSQL alongside SQL Server until the results match.

Side by sideReportsJobs
5

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.

RunbookRollback planChange window
6

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.

OSSeva AssureOSSeva OperateDay one

Your options, compared

OptionWhat you getTrade-off
Stay on SQL ServerNo code changesLicensing and the upgrade cycle stay as they are.
Babelfish for Aurora PostgreSQLT-SQL and SQL Server clients on a managed AWS service, with few code changes for many applicationsThe database lives on Aurora, and unsupported T-SQL still has to be rewritten.
Aurora or RDS for PostgreSQLA hosted target, with AWS DMS Schema Conversion for the schema and codeThe database stays on that provider's service and support calendar.
OSSeva migration and supportNative PostgreSQL on your own infrastructure, migrated and then supported by one teamA 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.