Somewhere in every organization, there’s a spreadsheet with a tab for stored procedures. It runs to several hundred rows, most of them written years ago by people who have since left, and until recently, nobody had a reason to open it.
What a SQL Server to PostgreSQL migration involves
A SQL Server to PostgreSQL migration moves a database and everything depending on it from Microsoft SQL Server to PostgreSQL. That covers the database schema, the data, the procedural code written in T-SQL, the applications issuing queries, and the integrations feeding and consuming the system.
The good news is that PostgreSQL is already widely used: Stack Overflow's 2024 Developer Survey found that 49% of developers reported using it.
The work divides into five streams:
- Schema and datatype conversion
- Procedural code conversion from Transact-SQL to PL/pgSQL
- Application-layer remediation
- Data migration and cutover
- Validation against the original
Data volume is a poor guide to how long this takes. Loading rows into a target is well understood, so the data itself rarely causes problems. The effort lands in the T-SQL, the application code, and the integrations nobody has looked at in years. A project sized on database size alone will be underestimated, usually by a wide margin.
That kind of support matters when the expertise isn't always available in-house. In fact, Redgate's 2025 State of the Database Landscape reports that 45% of organizations say that data skills gaps are holding their data transformation efforts back.
There is also a choice about which PostgreSQL to move to. Community PostgreSQL, a managed service such as Amazon RDS or Azure Database for PostgreSQL, and a supported enterprise distribution differ in how the platform is operated and who is accountable when something breaks. Fujitsu Enterprise Postgres is 100% compatible with community PostgreSQL, so standard conversion tooling and PostgreSQL ecosystem utilities still apply without a proprietary layer to work around.
Elements that don’t convert automatically
Automated converters handle much of the database schema and data migration, but they can’t reliably translate SQL Server-specific logic or dependencies.
Manual work commonly includes:
- Dynamic SQL
Identify and review statements assembled and executed as strings. - CLR assemblies and extended stored procedures
No equivalent exists. These need a rewrite in PL/pgSQL, an application service, or an extension language. - Procedures relying on SQL Server system objects
Replace or redesign dependencies on sys. catalog views, sp_ procedures, and SQL Server-specific metadata. - Query hints and plan guides
PostgreSQL has no direct equivalent for most hints. Queries relying on them need review. - Lock or isolation assumptions
SQL Server and PostgreSQL implement concurrency differently, so the same logic can behave differently after migration. - Reporting and BI artifacts
Reporting Services definitions, embedded datasets, and T-SQL need separate conversion.
The more SQL Server-specific logic and integrations a workload contains, the more manual effort the migration is likely to require.
Schema and datatype conversion
Most common data types map cleanly between SQL Server and PostgreSQL. Pay particular attention to differences in precision, time zones, identity generation, and storage behavior.
Common datatype mappings
Most common data types map cleanly between SQL Server and PostgreSQL. Pay particular attention to differences in precision, time zones, identity generation, and storage behavior.
| SQL Server | PostgreSQL | What to watch |
| DATETIME, DATETIME2 | TIMESTAMP or TIMESTAMPTZ | TIMESTAMPTZ where the application spans time zones. Choosing TIMESTAMP by default hides a bug until daylight saving time |
| MONEY | NUMERIC(19,4) | Declare precision and scale explicitly rather than relying on a default |
| UNIQUEIDENTIFIER | UUID | Native type, but generation moves from NEWID() to a PostgreSQL function |
| NVARCHAR, NCHAR | TEXT or VARCHAR | PostgreSQL stores UTF-8 natively, so the N-prefixed variants have no equivalent and are not needed |
| BIT | BOOLEAN | Application code comparing against 1 and 0 needs updating |
| IDENTITY columns | GENERATED AS IDENTITY or sequences | Behavior on explicit inserts and on restart differs |
| VARBINARY | BYTEA | Client library handling of binary data usually changes too |
| BIGINT, INT | BIGINT, INTEGER | Direct, one of the few that genuinely is |
| XML, JSON stored as text | XML, JSONB | JSONB is worth adopting deliberately rather than mapping text to text |
Identifier case sensitivity
SQL Server folds identifiers case-insensitively, so CustomerOrders and customerorders reach the same table. PostgreSQL lowercases unquoted identifiers and treats quoted ones as case-sensitive, so "CustomerOrders" and customerorders are two different objects. That can cause applications relying on mixed-case object names to fail after migration.
Make the decision once. Either fold everything to lowercase and update the application, or quote consistently everywhere. Avoid mixing the two approaches.
Partitioned tables, keys, and indexes
Partitioning needs review rather than direct conversion. An index or unique constraint declared on the partitioned table creates a matching index on every partition automatically, and a foreign key can reference a partitioned table.
Unique constraints and primary keys must include every partition key column. A SQL Server primary key that doesn't include the partition key therefore won't convert directly without changing the key or partitioning strategy. The PostgreSQL partitioning documentation sets out the current behavior.
Indexing deserves a second look rather than a direct port. PostgreSQL offers index types with no SQL Server equivalent, and BRIN indexes can replace a large B-tree on naturally ordered data such as time-series tables.
Converting T-SQL to PL/pgSQL
Procedural code is often where the migration schedule is decided. Conversion tooling translates a good share of it, but stored procedures and functions that rely on SQL Server-specific behavior need manual review and testing against real workloads.
Stored procedures and functions
No T-SQL stored procedure syntax maps one-to-one onto PostgreSQL. Procedures, functions, output parameters, and result sets behave differently, so conversion can require changes to both the PL/pgSQL and the calling application.
Porting T-SQL cursors directly into PL/pgSQL can carry their performance problems across, so consider rewriting them as set-based operations.
Error handling and transaction control
T-SQL error handling built on TRY/CATCH, @@ERROR, and RAISERROR maps onto PL/pgSQL exception blocks, but the behavior differs. PostgreSQL rolls back to the enclosing block when an exception is raised, while SQL Server behavior depends on factors including severity and XACT_ABORT.
Nested transactions, savepoint handling, and @@TRANCOUNT logic also have no direct equivalent. Temporary tables behave differently too, with PostgreSQL supporting session- or transaction-scoped temporary tables depending on ON COMMIT behavior.
Constructs with no direct equivalent
Some T-SQL constructs need to be redesigned rather than converted:
- Table-valued parameters have no direct equivalent and are usually replaced with arrays, composite types, or JSONB payloads.
- Triggers require a separate PostgreSQL trigger function rather than inline logic, although CREATE OR REPLACE TRIGGER simplifies maintenance.
- MERGE, available since PostgreSQL 15, provides a direct path for upsert logic that previously required workarounds.
Conversion tooling may flag constructs it cannot translate, but the harder problems are those that produce syntactically valid PL/pgSQL with different behavior. Test converted procedural code against real workloads rather than relying on review by inspection.
The application layer
Application remediation is easy to underestimate: every connection, embedded query, integration, and security dependency needs to work with PostgreSQL before cutover.
Drivers, ORMs, and embedded SQL
SQL Server drivers give way to PostgreSQL equivalents, requiring changes to connection strings, pooling, and timeout settings. ORMs can absorb some of this, but generated SQL and raw queries still need review.
Day-to-day tooling changes too. Teams coming from another RDBMS need to adjust to how PostgreSQL works and is administered, as well as tools such as psql and DBeaver for PostgreSQL management.
Embedded SQL is the harder problem. Pagination using TOP and OFFSET/FETCH, identity retrieval through SCOPE_IDENTITY(), string concatenation with +, date arithmetic using DATEADD and DATEDIFF, and ISNULL all need PostgreSQL equivalents. Finding them can be harder than rewriting them, especially when queries live in configuration files, report definitions, or stored strings.
Authentication and security integration
SQL Server deployments commonly use Windows Authentication and Active Directory groups to control database access. In PostgreSQL, this integration needs redesigning through pg_hba.conf, using options such as SCRAM, LDAP, GSSAPI, or Kerberos, with Windows groups mapped to PostgreSQL roles.
The surrounding controls need equivalents too. Transparent data encryption, column-level protection for sensitive fields, and audit logging that satisfies a regulator should be specified before cutover.
SSIS packages, linked servers, and scheduled jobs
Integrations also need equivalents designed rather than converted. SSIS packages need rebuilding in the chosen ETL or orchestration platform, linked servers need replacing with foreign data wrappers, application-level integration, or a data pipeline, and SQL Agent jobs need a scheduler. Reporting artifacts containing T-SQL also need review. Inventory these dependencies early, because they can easily push back the cutover date.
Data movement and cutover
Moving the data is the manageable part. The approach depends largely on how long the source can be unavailable.
An offline migration loads the target from an export and accepts an outage. CSV and the COPY command work for straightforward transfers, while pgloader handles schema and data migration together. DBConvert and the Ispirer toolkit can also support procedural conversion. All approaches require validation.
Where the outage window is too short, change data capture or logical replication keeps the target current while application testing continues. Logical replication in PostgreSQL supports this natively once the initial load is in place, and pg_createsubscriber reduces setup effort for large datasets. Heterogeneous CDC from SQL Server into PostgreSQL usually means a third-party pipeline, which is another component to test and operate.
The cutover still needs an outage window. Its length depends on the final data sync, repointing applications, and validation before users regain access. Replication can shorten the data sync, but it cannot eliminate the other steps.
Testing and validation
Testing should cover data reconciliation, application and procedural code, performance, and operational readiness. Compare rows and aggregates between source and target, and test performance under production-like loads because PostgreSQL query plans will differ.
A migration validation checklist keeps this from becoming a judgment call on the night. At minimum it should cover:
- Row counts and aggregate checks matched between source and target, with variances explained
- Every converted stored procedure executed against known inputs with outputs compared
- Application test suite passing against the target
- Performance benchmarks captured on both platforms for the queries that matter most
- Backups, restores, monitoring, and failover tested on the target
- Rollback procedure rehearsed and go or no-go criteria agreed before cutover
Expect performance regressions after conversion rather than treating them as evidence of failure. Query plans differ, and the indexing strategy and statistics that worked for SQL Server may need revisiting in PostgreSQL. Plan PostgreSQL performance tuning as part of the stabilization period.
Converting to PostgreSQL without adding a new proprietary layer
Many organizations move off SQL Server because of dependency on a single vendor's platform. Fujitsu Enterprise Postgres maintains 100% compatibility with community PostgreSQL, so organizations can avoid replacing that dependency with another proprietary layer while retaining standard PostgreSQL tooling and skills.
Fujitsu supports that with:
- Migration support
Assess the work upfront, plan the migration, and get professional services support through conversion and implementation. - Operational stability
24/7 global support with defined SLAs provides expert support during migration, stabilization, and ongoing operations. - Security and governance
Transparent data encryption, data masking, and dedicated audit logging help maintain security and compliance requirements as workloads move. - Deployment and lifecycle flexibility
Deploy across on-premises, hybrid, multi-cloud, Kubernetes, and OpenShift, with long version support lifecycles, proactive support engagement, and options for upgrading replication clusters without downtime.
A global capital markets operator took this route, modernizing from Microsoft SQL Server onto Fujitsu Enterprise Postgres running on OpenShift on IBM Z. Workloads were classified and sequenced before any conversion work started, and the platform choice preserved compatibility rather than trading one proprietary dependency for another.
You can try Fujitsu Enterprise Postgres in your own environment with a free trial and run a representative schema against the target before committing.
Frequently asked questions about SQL Server to PostgreSQL migration
How long does a SQL Server to PostgreSQL migration take?
A single application database with limited procedural code can move in weeks, while complex estates can take months. The biggest variables are the amount of T-SQL, stored procedures, application dependencies, and integrations — not simply data volume.
Can T-SQL stored procedures be converted to PostgreSQL automatically?
Partially. Conversion tools handle straightforward procedures well, but dynamic SQL, CLR assemblies, SQL Server-specific dependencies, and transaction behavior often require manual work. Converted code also needs testing to confirm it behaves correctly in PL/pgSQL.
What datatypes do not map directly from SQL Server to PostgreSQL?
Several data types require a decision rather than direct substitution. DATETIME may become TIMESTAMP or TIMESTAMPTZ, MONEY typically maps to NUMERIC, and IDENTITY columns can use PostgreSQL identity columns or sequences. NVARCHAR needs no equivalent because PostgreSQL stores UTF-8 natively, while BIT typically maps to BOOLEAN.
What happens to SSIS packages when you migrate to PostgreSQL?
SSIS packages do not convert. They need rebuilding in another ETL or orchestration platform. Linked servers, SQL Agent jobs, and Reporting Services artifacts may also need replacing or redesigning.
How much downtime does a SQL Server to PostgreSQL cutover require?
It depends on the approach. An offline migration requires downtime for data transfer and validation. Change data capture or logical replication can reduce the final sync, but you still need time to repoint applications and validate the target before reopening the system.
Is SQL Server or PostgreSQL better for enterprise workloads?
Both handle enterprise workloads at scale. SQL Server offers deep integration with the Microsoft ecosystem, while PostgreSQL offers an open source foundation, deployment flexibility, and freedom from per-core licensing costs. The right choice depends on your existing technology, migration requirements, and long-term platform strategy.
What is the biggest challenge in a SQL Server to PostgreSQL migration?
The application layer, consistently. Schema conversion is largely automated and data movement is well understood, but application queries, drivers, integrations, and SQL Server-specific dependencies all need to work correctly with PostgreSQL. This work is easy to underestimate during initial migration planning.
PostgreSQL Insider 
