01
Estate Assessment
Databases, objects, sizes, T-SQL features in use, and the applications, reports and drivers that connect, classified low, medium or high effort.
SQL Server to PostgreSQL Migration
SQL Server to PostgreSQL Migration: Decide Babelfish or Native Conversion First
Last reviewed by Tyler Eastridge
AceMQ plans and runs SQL Server to PostgreSQL migrations with partner SQL Server and PostgreSQL specialists. The first decision is whether your applications keep speaking T-SQL through Babelfish or move to native PostgreSQL, and we make it from your applications, drivers and distributed transactions, not from a tool demo. Then we deal with what lives outside the engine, such as Agent jobs, SSIS packages and linked servers, move the data, and cut over with a written rollback.
- SQL Server 2016 extended support ended, per Microsoft
- 14 Jul 2026
- SQL Server 2019 extended support ends, per Microsoft
- 8 Jan 2030
- hour to a reply on a quote request
- 1
Is This You?
You probably need this if…
- 01
SQL Server 2016 is past extended support and the choice is paid Extended Security Updates, an upgrade or a change of engine
- 02
Dozens of applications and vendor packages speak T-SQL, and nobody will approve rewriting them all before a deadline
- 03
Business logic lives in stored procedures, and the real schedule lives in SQL Server Agent jobs and SSIS packages
- 04
Linked servers join the database to others, so it cannot move without them
- 05
Reporting and applications connect over drivers nobody has inventoried
- 06
A tool vendor promised a one-click conversion, and you want an independent view first
- 07
The change board wants a rollback story before it approves a cutover date
Outcomes
Where you are now, and where you end up
Concrete state changes, not deliverable counts. This is what actually differs about your SQL Server estate when the engagement closes.
Before
"Use Babelfish" or "convert it all" is decided in a meeting, on instinct.
After
A decision table per application: which can run on Babelfish, which must be converted, and which depend on features the Babelfish documentation lists as unsupported.
Before
The database is the plan, and everything outside it surfaces in the last month.
After
An inventory of Agent jobs, SSIS packages, linked servers, reports and drivers, each with an owner and a named replacement before the build starts.
Before
A conversion tool reports a score and the team reads it as a promise.
After
Converted code reviewed and tested by engineers, with every unsupported construct listed against a design for replacing it.
Before
Cutover is a weekend and a prayer.
After
A rehearsed cutover with the SQL Server source kept as the fallback until sign-off, and the checkpoints written down in advance.
Scope
What's covered
- 02
Babelfish or Native Decision
A per-application recommendation on running T-SQL through Babelfish, converting to native PostgreSQL, or Babelfish first and native later, with the dates the plan has to meet.
- 03
Proof of Value
One representative database converted, loaded and tested end to end before you commit to a program.
- 04
T-SQL Conversion Review
Procedures, functions and triggers converted with tooling, then reviewed and tested, with every unsupported statement listed and redesigned.
- 05
Jobs, SSIS and Linked Servers
SQL Server Agent jobs, SSIS packages, Database Mail and linked servers inventoried and each given a replacement, because none of them is a table to copy.
- 06
Data Movement
A one-time load, or full load plus change data capture where SQL Server must keep serving until cutover, chosen against your downtime budget and rehearsed.
- 07
Validation
Row counts, checksums and application checks on both sides, before and after cutover.
- 08
High Availability and Backup Design
A PostgreSQL primary and standby design with restore tests, sized to your recovery targets.
- 09
Handover and Run
Runbooks for your DBAs, and an optional move to 24/7 PostgreSQL support or managed service afterwards.
The Engagement
How it actually runs
Every phase has a defined duration and a concrete artifact handed over at the end of it. You always know what stage you're in and what you've received.
- Phase 1Scoped per estate
Assess
Inventory databases, applications, drivers, jobs, packages and links. Run assessment tooling and read the output ourselves, because a compatibility score is a starting point and not an estimate.
You receive
- Inventory of databases, applications and what sits outside the engine
- Effort class per database
- Babelfish or native recommendation per application
- Phase 2Scoped per database
Prove on one database
Convert and load one representative database, point its real applications at it, and record every statement or feature that needed work.
You receive
- Converted schema and code for one database
- Application test results
- Estimate for the rest of the estate based on that result
- Phase 3Scoped per program
Design
Target PostgreSQL version and layout, the Babelfish or native approach, replacements for jobs and linked servers, data-movement method, cutover order and rollback.
You receive
- Target design and version choice
- Replacement design for jobs, packages and links
- Cutover and rollback plan with go or no-go checkpoints
- Phase 4Per database, in waves
Convert and rehearse
Convert, load and validate each database on a copy of production, timed, until the cutover fits the window. Nothing reaches production before it has been rehearsed.
You receive
- Reviewed conversion per database
- Measured load and cutover times
- Validation reports
- Phase 5Planned change window
Cut over and hand over
AceMQ and your team run the production cutover with the agreed checkpoints, then hand over runbooks and monitoring, with 24/7 support available afterwards.
You receive
- Validated PostgreSQL production
- Runbooks and monitoring
- Optional move to 24/7 support or managed service
Babelfish or native PostgreSQL: the questions that decide it
Babelfish is an open source project (Apache 2.0 and PostgreSQL licences) that lets PostgreSQL understand queries from applications written for SQL Server, over the SQL Server wire protocol, TDS, with a T-SQL dialect. Amazon's documentation for its Aurora PostgreSQL offering says applications can work with few code changes and without changing database drivers, and also that Babelfish runs T-SQL with some differences. "Few" and "some" are the words to plan around. We settle the choice by asking questions about each application.
| Question | Why it matters | What the documentation says |
|---|---|---|
| Does the application use distributed transactions (MSDTC or XA)? | Distributed transactions across SQL Server and other resources do not carry over. | AWS lists no MSDTC or XA support in client drivers for Babelfish on Aurora. |
| Which database driver connects? | A driver on the unsupported list means a driver change, which defeats the point of a compatibility layer. | AWS lists the jTDS driver as not supported, and Babelfish speaks TDS 7.1 through 7.4. |
| Which PostgreSQL extensions does the design need? | Some extensions cannot be used alongside Babelfish. | AWS lists bloom, btree_gin, btree_gist, citext, cube, hstore, hypopg, pglogical, ltree, pgcrypto and apg_plan_mgmt as not supported with Babelfish on Aurora. |
| Where does the database run? | Self-managed Babelfish ties the PostgreSQL version to the versions the project supports. | The project page lists PostgreSQL 17 support (release 5.1.0) as its newest item, after PostgreSQL 16 (4.0.0). Aurora has its own list of limits. |
| Is the T-SQL standard or full of vendor-specific features? | The more procedural T-SQL, the more the unlisted differences matter. | AWS states differences exist and keeps the list on a separate compatibility page. We run your own code against it instead of trusting a summary. |
| Will the application be changed anyway? | If a rewrite is already planned, a compatibility layer may be a detour. | Not a documentation question, and it can outweigh every other row. |
Babelfish first, native later
Where a deadline arrives before the applications can change, moving onto Babelfish and converting applications one at a time is a legitimate plan. It leaves two states to test and support, so the plan has to say when Babelfish goes and who owns that date.
What lives outside the engine: Agent jobs, SSIS and linked servers
The items that are not tables are the easiest to miss. SQL Server Agent jobs, SSIS packages, Database Mail and linked servers do not move when the schema does, and none of them appears in a row count. We build the inventory in assessment and give each item a named owner and replacement design before conversion starts.
| Item | What tools do | What we plan |
|---|---|---|
| SQL Server Agent jobs and Database Mail | AWS SCT's extension pack emulates SQL Server Agent and Database Mail in converted PostgreSQL code. | Decide per job whether the emulation is acceptable or the schedule moves to a scheduler you already run. |
| SSIS packages | Not database objects, so schema converters do not carry them. Microsoft's SSMA targets SQL Server, not PostgreSQL, so it is not the route here. | Inventory each package, then re-point, rebuild or retire it. These are integration jobs, not database objects. |
| Linked servers | They are connections to other systems, not schema objects, so there is nothing to convert. | Replace each with a foreign data wrapper, replication or an application call, chosen per link, and put the order of cutover in the plan. |
| Reports and BI connections | Out of scope for database conversion tools. | List every connection string and driver, and test the report queries on the converted schema. |
| Identity columns, collations and time zones | Engine-specific behaviour that a converter does not decide for you. | Decide mapping in design, check unique keys and login lookups, and compare time zone handling in validation. |
Conversion tools cover real ground. AWS SCT converts SQL Server sources to PostgreSQL and rewrites GOTO, emulates MERGE, supports the inserted and deleted trigger tables and emulates user-defined table types with temporary tables. It also lists constructs it cannot handle, and its page says foreign keys that reference partitioned tables are not supported. PostgreSQL's own reference lists MERGE for version 15 and later, so the version you pick as target changes what the converter has to emulate. pgloader and the EDB Migration Toolkit both read SQL Server directly as a source.
Moving the data and keeping SQL Server as the fallback
A one-time load suits a rehearsed maintenance window. Where SQL Server must keep serving until cutover, AWS DMS supports ongoing replication after the initial load, and the design states the source-side prerequisites, the lag to watch and how the target is validated while data is still moving. Before either, we measure load time on production-sized data in rehearsal, because downtime equals that number.
Rollback is designed with the cutover. The default is to keep the SQL Server source untouched until sign-off. Where that is not enough, we state what replication back would need and which writes made on PostgreSQL would be lost in each case.
Rule we hold
Never combine a platform migration with a version upgrade in one production window. Moving engines, raising the PostgreSQL major version and changing applications are separate changes, each with its own fallback.
The Microsoft dates that frame the decision
Microsoft's lifecycle pages for SQL Server follow the Fixed Lifecycle Policy. These are the dates most estates are working against, read on 4 November 2026.
| Release | Mainstream support ended | Extended support ends | Note |
|---|---|---|---|
| SQL Server 2016 | 13 July 2021 | 14 July 2026 (ended) | Extended Security Updates year 1 runs to July 2027; Microsoft lists years 2 and 3 to July 2028 and July 2029. |
| SQL Server 2017 | 11 October 2022 | 12 October 2027 | Next to leave extended support after 2016. |
| SQL Server 2019 | 28 February 2025 | 8 January 2030 | Big Data Clusters were retired on 28 February 2025. |
| SQL Server 2022 | Ends 11 January 2028 | 11 January 2033 | Lifecycle start 16 November 2022. |
| SQL Server 2025 | Ends 6 January 2031 | 6 January 2036 | Lifecycle start 18 November 2025. |
AceMQ does not sell or advise on Microsoft licences or Extended Security Updates. The dates are Microsoft's, and an upgrade is a legitimate alternative to a migration. Whether to stay on SQL Server is a recommendation we make after the assessment, not before.
Who this is not for
- Teams expecting a drop-in replacement — Babelfish is described by Amazon as needing few code changes with some differences, not none. The proof of value shows how many for your applications.
- Application rewrites — We convert the database and its procedural code. Your developers change application code, and we tell them which statements and settings to change.
- Reporting and BI rebuilds — We test report queries on the converted schema. Rebuilding report tools or dashboards belongs to your BI team.
- Estates that should stay on SQL Server — Where an upgrade is cheaper and the reasons to leave are weak, we say so. An upgrade to a supported release is a legitimate answer.
- Licence negotiation — AceMQ is an independent provider: it is not a Microsoft reseller and gives no advice on what you owe under your agreement.
Typical engagements
How these engagements run
Typical engagement scenarios: what the work covers and what it delivers. They describe the service, not past results.
Real-Time Manufacturing Data Ingestion Modernization
Global Automotive Manufacturer
Replacing fragile SQL-trigger-based ingestion with a reliable event-driven architecture for plant-floor data movement and low-latency operations.
RabbitMQMQTT
KafkaSQL Server
Kubernetes
SQL Server to PostgreSQL: Babelfish Assessment and Migration Path
SaaS Platform Team
A typical engagement for a team on SQL Server 2016 whose applications are written in T-SQL: assess Babelfish compatibility, choose between a bridge and full conversion, and plan the cutover.
PostgreSQLSQL ServerBabelfishAWS DMS
Pentaho Lineage and Documentation Recovery Assessment
Utility Holding Company
Reconstructing lineage and documentation for an undocumented estate of legacy Kettle transformations before anyone attempts to change or replace them.
PentahoPostgreSQLSQL Server
dbtPentaho Job Failure and Data Integrity Support
Logistics and Distribution Company
Ongoing support for a Pentaho Data Integration estate that must keep running reliably while a longer-term replacement is planned.
PentahoSQL ServerPostgreSQL
Docker
Debezium MySQL Binlog Retention and Schema History Support
Online Travel Platform
Ongoing support for a MySQL change data capture pipeline that needed a full re-snapshot after a planned outage outlasted binlog retention and a trimmed schema history topic.
Debezium
MySQLSQL ServerOracle DatabaseKafka
Amazon RDSSQL Server Always On Availability Group Failover Review
Regional Logistics Operator
A typical engagement: reviewing an Always On availability group that spans two sites, so the first real failover is not the first test of its replica modes, quorum and lag tracking.
SQL ServerWindows Server Failover ClusteringAlways On Availability GroupsSQL Server 2016 Upgrade and Extended Security Updates Planning
Manufacturing Group
A typical engagement: inventory a mixed SQL Server 2016 estate after extended support ended, then decide per instance between upgrading, Extended Security Updates and Azure SQL Managed Instance.
SQL ServerAzure ArcQuery StoreManaged SQL Server in the Customer's Own Cloud Account
SaaS Platform Team
A typical engagement: AceMQ takes over operations of a SaaS platform's SQL Server estate in the customer's own AWS account, with the data and the licences staying with the customer.
SQL ServerAmazon EC2Always On Availability Groups
FAQ
Questions about SQL Server to PostgreSQL migration
Can AceMQ migrate SQL Server to PostgreSQL?
Yes, as a planned program delivered by AceMQ engineers with partner SQL Server and PostgreSQL specialists. It starts with an assessment and a proof of value on one database, then waves of conversion, rehearsal and cutover. We give timelines and prices only after the assessment, because they depend on how much T-SQL, how many jobs and links and how much data the estate holds.
Should we use Babelfish?
It depends on the applications. Babelfish lets PostgreSQL accept SQL Server clients over TDS and understand T-SQL, but AWS documents differences, no MSDTC or XA support in client drivers on Aurora, and a list of unsupported extensions. We decide per application, and sometimes Babelfish first and native conversion later is the right plan.
Is SSMA the right tool for this?
No. Microsoft's SQL Server Migration Assistant targets SQL Server and Azure SQL, not PostgreSQL. For PostgreSQL targets the usual tools are AWS SCT or DMS Schema Conversion, pgloader and the EDB Migration Toolkit for reading SQL Server, and AWS DMS for ongoing replication. Engineers still review the output.
What about Agent jobs, SSIS packages and linked servers?
They are inventoried in the assessment, and each gets a named replacement before conversion starts. Some are emulated in converted code, some move to a scheduler you already run, and some are retired. None of them is a table to copy, which is why they are the usual cause of schedule slips.
SQL Server 2016 is out of extended support. Must we migrate?
No. Microsoft lists Extended Security Updates for SQL Server 2016, and upgrading to a supported release is a legitimate option. We compare the upgrade, paid updates and a move to PostgreSQL against your applications and dates, and recommend one. AceMQ does not advise on Microsoft licensing.
Let's talk
Scope a SQL Server to PostgreSQL Migration
Tell us how many SQL Server databases you run, their versions and sizes, what connects to them and how much downtime you can accept. We reply within 1 hour and follow with a written assessment plan.
Get in Touch
Talk to a SQL Server Expert
Send us a message and we'll follow up within 1 hour — or book a free 30-min consultation directly.
305-204-2607info@acemq.com66 W. Flagler St. 9th Floor
Miami, FL 33130
Miami, FL 33130
Prefer to talk now? Call us directly or use the consultation tab to find a time that works.