Migration to PostgreSQL
We move your Oracle and Microsoft SQL Server databases to PostgreSQL safely and leave the licensing costs behind -- from the initial assessment through cutover and post-migration tuning.
Why Migrate with Gündüz Bilişim?
A database migration is never just moving tables: data types, stored procedures, triggers, SQL dialect differences and application behavior all have to be handled together. As a team working with PostgreSQL since 1998 and contributing to the PostgreSQL project itself, we know both sides in depth -- and we deliver your migration without surprises.
Oracle to PostgreSQL Migration
From Oracle-specific data types to PL/SQL packages, CONNECT BY queries, sequences and partitioning, we convert everything to its native PostgreSQL equivalent. We use tools such as ora2pg, oracle_fdw and orafce as the project requires, and rewrite code by hand wherever automatic conversion falls short.
Schema Conversion
Tables, constraints, indexes, sequences and partitions, with correct mapping of types such as NUMBER, DATE, VARCHAR2 and CLOB.
PL/SQL → PL/pgSQL
Converting packages, procedures, functions and triggers, including PostgreSQL equivalents for autonomous transactions and BULK COLLECT.
SQL Dialect Differences
Adapting Oracle-specific syntax such as CONNECT BY, ROWNUM, DUAL, (+) outer joins, NVL, DECODE and MERGE.
Data Transfer
Moving large data volumes in parallel, verified and repeatable, with ora2pg and oracle_fdw.
Application Compatibility
Identifying SQL and driver changes on the application side and adapting ORM and connection settings to PostgreSQL.
Validation & Testing
Row-count and checksum comparisons plus functional and performance tests that prove the data arrived intact.
SQL Server to PostgreSQL Migration
When moving from Microsoft SQL Server to PostgreSQL, we carry over T-SQL code, data types, collation and case-sensitivity behavior, and SQL Server Agent jobs in full. We speed things up with tools such as pgloader, tds_fdw and, where it fits, Babelfish -- while aiming for native PostgreSQL code as the long-term solution.
Schema Conversion
Correct mapping of IDENTITY, NVARCHAR, DATETIME2, UNIQUEIDENTIFIER, BIT, MONEY and the rest of the schema to PostgreSQL.
T-SQL → PL/pgSQL
Converting stored procedures, functions, triggers and views, including equivalents for temp tables, TRY/CATCH and OUTPUT.
Query & Collation Differences
Adapting syntax such as TOP, ISNULL and CROSS APPLY while preserving case-sensitivity and locale-specific sorting behavior.
Data Transfer
Fast, verified and repeatable data transfer with pgloader and tds_fdw.
Jobs & Integrations
Moving SQL Server Agent jobs, SSIS packages and linked-server scenarios to pg_cron and their equivalents in the PostgreSQL ecosystem.
Validation & Testing
Data consistency comparisons, functional tests and performance tests under real workloads.
Our Migration Process
We run every project in steps that make risks visible up front and take the surprises out of cutover.
Assessment & Inventory
Inventory of database objects, code complexity and application dependencies, with an effort and risk report.
Architecture Design
Designing the target PostgreSQL architecture, including version, hardware, high availability, backup and monitoring.
Conversion
Converting schema, code and queries, with every piece of automated tool output reviewed by hand.
Testing & Rehearsal
Moving the data, validating consistency, and rehearsing the cutover in advance.
Cutover
Going live in a minimal-downtime window with a rollback plan ready.
Post-Migration Support
Performance tuning, monitoring and team training so the new system runs smoothly.
Frequently Asked Questions
How long does an Oracle to PostgreSQL migration take?
It depends on database size, the amount of PL/SQL code, and how tightly the application is coupled to the database. During the initial assessment we build the inventory and give you a clear effort and timeline estimate.
How much downtime will the migration cause?
We minimize downtime by moving the data ahead of time, synchronizing the differences, and rehearsing the cutover in advance. Every cutover comes with a rollback plan.
Can our PL/SQL and T-SQL code be converted automatically?
A large part of the code can be converted automatically with tools such as ora2pg, but manual review and fixes are always needed. Our experienced PostgreSQL specialists do this line by line and verify it with tests.
Will performance drop after the migration?
Not in a migration done right. After cutover we tune queries, indexes and configuration for your real workload so the new system runs as fast as -- or faster than -- the old one.
Our team doesn't know PostgreSQL yet. Is that a problem?
No. We include our PostgreSQL training in migration projects so your team can run the new system on its own.