Data platform · SQL Server to PostgreSQL

SQL Server to PostgreSQL migration, with both databases live until cutover

A SQL Server to PostgreSQL migration is usually started by a licence renewal and finished by engineering: the schema is mapped, T-SQL is rewritten for PL/pgSQL, and the application is tested against a database that behaves differently in small ways. Interkey runs the move from Riyadh, with iblync, its own replication platform, keeping SQL Server and PostgreSQL in step until the checks pass.

Scope your SQL Server to PostgreSQL move How the data types map

SQL Server to PostgreSQL migration at a glance

The main facts of a SQL Server to PostgreSQL migration with Interkey
Question	Short answer
Why teams move	Mostly SQL Server licence cost; sometimes a move to a managed PostgreSQL service or a wish to standardise on one engine
What moves	Schema, data, T-SQL code (procedures, functions, triggers, jobs) and the application queries that depend on them
Where the effort sits	Usually the T-SQL rewrite and the application testing, not the data copy
How the outage is kept short	Initial load, continuous replication with iblync, a parallel run, then a cutover in gated steps
Where it runs	The replication bridge, the target database and the tooling can run on infrastructure inside the Kingdom
How it is priced	Per engagement after an assessment; iblync by quotation, per source system, target system and data volume

For an executive, the decision is simple to state: the licence saving is real, but it is paid for once in engineering work. The assessment compares both, and may conclude that you should stay.

When a SQL Server to PostgreSQL migration makes sense

Most projects we are asked about start in the finance office. SQL Server licences are a recurring cost that grows with cores and instances, while PostgreSQL is open source software with no licence fee.

It is a sound reason to migrate when three things are true:

The licence saving outlasts the project. The rewrite, testing and parallel run are paid once; the saving recurs.
The database is not tied to SQL Server-only features. Heavy use of SQL Server Integration Services packages, SQL Server Agent jobs or linked servers raises the cost, because each needs a new home.
Someone will run PostgreSQL afterwards. Your DBAs, after a handover, or a managed-service team. A database with no owner is not a saving.

If not, tuning and consolidating the SQL Server estate may be the better answer, and we say so in writing. The general method is on our PostgreSQL migration page; this page is about the SQL Server source specifically.

Convert SQL Server to PostgreSQL: how the data types map

Common SQL Server data types and their usual PostgreSQL equivalents
SQL Server	PostgreSQL	What to check
INT, BIGINT, SMALLINT	integer, bigint, smallint	Usually a direct match
TINYINT	smallint	PostgreSQL has no one-byte integer; add a check constraint if the 0 to 255 range matters
BIT	boolean	Code that compares with 1 and 0 must compare with true and false
VARCHAR(n), NVARCHAR(n)	varchar(n) or text	PostgreSQL stores all text in the database encoding, so with UTF-8 the N types need no separate equivalent; check lengths and collation
VARCHAR(MAX), NVARCHAR(MAX)	text	No length limit to carry over
DATETIME, DATETIME2	timestamp	Check precision and any code that relies on DATETIME rounding
DATETIMEOFFSET	timestamptz	PostgreSQL stores the moment in time, not the original offset; keep the offset in a column if you need it
UNIQUEIDENTIFIER	uuid	Default value functions change
VARBINARY(MAX), IMAGE	bytea	Large objects may be better kept outside the database; decide per table
MONEY	numeric(19,4)	Use numeric for exact amounts
IDENTITY columns	GENERATED AS IDENTITY	Reset the next value after the data load
ROWVERSION	No direct equivalent	A design decision: a version column maintained by a trigger, or a change in how the application detects conflicts

Conversion tools can draft this mapping; the right-hand column is what the assessment reviews by hand.

T-SQL to PL/pgSQL: what usually needs rework

The code inside the database is where most of the engineering time goes. These differences come up on almost every SQL Server source:

Everyday syntax. TOP becomes LIMIT, ISNULL becomes COALESCE, GETDATE() becomes now() or CURRENT_TIMESTAMP, and string concatenation with + becomes ||. Easy to miss in dynamic SQL.
Generated keys. SCOPE_IDENTITY() and @@IDENTITY are replaced by INSERT ... RETURNING.
Procedures that return rows. A T-SQL procedure that ends in a SELECT usually becomes a PostgreSQL function that returns a table, and the application calls it differently.
Error handling. TRY ... CATCH becomes a block with an EXCEPTION section. In PL/pgSQL, catching an exception rolls back the changes made since the start of that block, so code ported line by line can lose work it used to keep.
Temporary tables. #temp tables become CREATE TEMP TABLE, with attention to when they are created and dropped.
Case. Many SQL Server databases use a case-insensitive collation, so 'Riyadh' = 'RIYADH' is true. In PostgreSQL text comparison is case-sensitive by default, and unquoted names are folded to lower case. Searches, unique keys and joins on text need review.
Scheduled jobs. SQL Server Agent jobs need a new scheduler, because PostgreSQL itself has no job agent.

None of this is solved by copying data, which is why the assessment reads the code before anyone quotes a duration.

A SQL Server to PostgreSQL migration tool for the data: where iblync fits

iblync is Interkey's own data migration and replication platform, and SQL Server and PostgreSQL are both on its published connector list. Here it moves the data and keeps the two databases in step while the rest of the work is proved.

Initial load. The existing data is copied to PostgreSQL once, throttled so the load does not compete with production on SQL Server.
Continuous replication. Every change made on SQL Server after the load is applied to PostgreSQL. If PostgreSQL is unavailable, changes queue instead of failing and are processed when it recovers.
Two-way where needed. iblync supports bi-directional synchronisation, so during the parallel run some services can write to PostgreSQL while others still write to SQL Server.
Proof. iblync's own site states that validation uses checksums and row counts. The pass conditions for your data are agreed before cutover.

Where it does not fit: iblync does not rewrite T-SQL or change your application. That is engineering work, which we carry with your teams. The pattern of a parallel run and a planned final switch is explained on the zero downtime migration page, and the platform itself on the iblync page.

Typical starting points we see

A licence renewal with a date on it. The aim is to move the largest or most expensive instances first and retire them before the next renewal, with the rest following.
A new application built on PostgreSQL that still needs SQL Server data. iblync keeps the two in step while the old system is retired service by service.
A move to a managed PostgreSQL service on a cloud platform or on infrastructure inside the Kingdom, with the data residency decision made first.

How a SQL Server to PostgreSQL project runs

Assessment.

Instances, schema, T-SQL code, Agent jobs, integration packages, application queries, data volume, change rate, downtime window and residency. The output is a decision with a costed comparison that includes staying on SQL Server.
Schema and code.

The schema is mapped, the T-SQL is rewritten for PL/pgSQL, and both are tested against production-shaped data.
Application changes.

Drivers, connection settings, queries and error handling are changed and tested per service, with your application teams.
Load and replicate.

iblync loads the data and keeps PostgreSQL in step with SQL Server.
Parallel run.

Both databases live; reads move first, service by service, in steps that can be reversed.
Gated cutover.

Final sync, validation, a named go or no-go, then writes move. The cutover and the rollback are rehearsed before the real night.
Stabilise and hand over.

Tuning, backup-restore proof and failover drills, then handover to your DBAs or operation by Interkey.

What Interkey delivers in Saudi Arabia

One team for the assessment, conversion, replication and cutover, with support from Riyadh in Arabic and English. The replication bridge, the target database and the tooling can run on infrastructure inside the Kingdom, which matters when the data is personal or regulated; where the data may sit is settled in the assessment, before any copy is made.

Before you start, our migration decision checklist walks through the questions that decide whether the move is worth it. After go-live, schema changes on PostgreSQL can be versioned and released through a pipeline by our database DevOps practice.

Relatedmigration decision checklist

What drives the cost

Quotes are per engagement, after the assessment. The drivers are the amount and style of T-SQL, the number of applications and services whose queries change, SQL Server features that need a new home (Agent jobs, integration packages, linked servers), data volume and change rate, the downtime window the business will grant, the deployment model, and who runs PostgreSQL afterwards. iblync itself is priced by quotation, per source system, target system and data volume.

Questions buyers ask

Will moving to PostgreSQL remove our SQL Server licence cost?

For the databases you move and retire, yes: PostgreSQL has no licence fee. The cost moves to the migration itself, to support and to the people who run PostgreSQL. The assessment sets the saving against those costs over the same period.

How long does a SQL Server to PostgreSQL migration usually take?

It depends mostly on the amount of T-SQL code and the number of applications that change, then on data volume and the downtime window. We give a range after the assessment, with what moves it named.

Can iblync convert our T-SQL stored procedures automatically?

No. iblync moves the data and keeps SQL Server and PostgreSQL in step. Conversion tools can draft the schema and some code, and our engineers rewrite and test the rest for PL/pgSQL.

Can SQL Server and PostgreSQL run side by side before we switch?

Yes, that is the plan. iblync replicates changes continuously, two-way where some services already write to PostgreSQL, so reads and then writes move only when the agreed checks pass.

Does the data stay inside Saudi Arabia while it is being replicated?

It can. The replication bridge, the target database and the tooling can run on infrastructure inside the Kingdom. Where the data may sit is agreed in the assessment, before the first copy.

Who supports the new PostgreSQL databases after go-live?

Your DBAs after a handover, or Interkey from Riyadh under a written managed-services scope. Backup-restore proof and failover drills come before handover.

Next step

Scope your SQL Server to PostgreSQL move

Tell us the SQL Server versions and number of instances, the rough data volume, how much T-SQL code they hold, and the downtime window the business will accept.

First name Last name

Company Email Company

Phone number (optional) What are you working on? (optional)

Required field

By sending this form, you agree to our Privacy Notice.

Published by Interkey. Last updated 2026-11-10. Interkey is registered in Riyadh, Saudi Arabia under commercial registration 1010156897.

Assessment.

Schema and code.

Application changes.

Load and replicate.

Parallel run.

Gated cutover.

Stabilise and hand over.

Scope your SQL Server to PostgreSQL move