Moving off SQL Server without rewriting the application

Most SQL Server estates do not move because someone found a better database. They move because the renewal quote arrived.

Then the migration plan lands, and the plan is the problem. Rewrite the stored procedures, rebuild the application, and freeze the roadmap for a year. That is the project that gets approved late and finished never.

Babelfish removes part of that problem. Only part. Knowing which part is the difference between an eighteen-month rewrite and a controlled move.

What the compatibility layer actually does

Babelfish speaks TDS, the protocol SQL Server clients use natively. It parses the incoming T-SQL, translates what it supports into PostgreSQL, and returns results in the shape the client expects. Applications that connect with the standard Microsoft JDBC drivers often need no change at all.

The client believes it is talking to SQL Server. PostgreSQL does the work.

What that buys you

CYBERTEC's published figures put typical MS SQL estate reduction on this path at 40 to 70 percent.

The licence saving is not the interesting part. The staging is. You leave the applications alone, move the databases that translate cleanly, and postpone the hard ones. Development teams keep shipping while the estate shrinks.

Where it stops

Babelfish is not a reimplementation of SQL Server, and it is not 100 percent compatible. Anything that depends on SQL Server-only behaviour tends to fall outside the translation. The heavier your use of stored procedures and platform-specific features, the less of the work disappears.

A rough way to triage a database before you commit:

That last row is the one that quietly disappears from planning decks.

The half of the work people forget

Moving data is half the job. The other half is everything the database was doing for security and uptime.

CYBERTEC PGEE, the enterprise PostgreSQL edition built by CYBERTEC, adds transparent data encryption at rest, masking and obfuscation for data leaving production, extended auditing, and time-based permission controls for maintenance windows. High availability runs on Patroni with etcd, and CYBERTEC contributes to that project and supports it commercially. PGEE installs on RHEL, Ubuntu, Debian and Windows, and Kubernetes deployment is supported.

One practical note: the Windows route works but is complex, and Linux stays the recommended platform for production.

How the work gets scoped

Worlber runs these migrations as structured engagements rather than one large cutover. Scoping comes first, where the databases, the schemas and their dependency on SQL Server behaviour get counted. Pre-assessment separates the quick wins from the hard cases. A detailed assessment produces the plan. Execution follows, with dry runs before anything touches production. Aftercare covers tuning and whatever surfaces in the first weeks under real load.

Worlber provides CYBERTEC's enterprise PostgreSQL products and services as a partner offering, and runs migration engagements on that tooling. At the Enterprise tier, the work can include AI-assisted explanation and pre-translation of stored procedures, parallel data transfer, and close-to-zero downtime options.

On the cost number

CYBERTEC's published figure is up to 60 percent savings against MS SQL Server. Treat a figure like that as a question to test against your own estate, not as a promise. The saving depends on core counts, edition, the support contract, and how much of the workload actually moves.

The question worth asking first

Not "can we leave SQL Server". That one has been settled commercially for many workloads. The useful question is narrower: which databases in your estate can move without an application rewrite, and what does the rest cost to do properly.

Find out which of your databases can move without a rewrite

Worlber will review a sample of your SQL Server databases and tell you which ones suit the Babelfish path and which need a full migration. No obligation.

Talk to Worlber