// Database migration services
Database migration to PostgreSQL: from Oracle, SQL Server or MySQL
OSSeva's database migration services move Oracle, SQL Server and MySQL databases to PostgreSQL in four phases (assessment, conversion, a dual run and cutover), then support the PostgreSQL cluster you land on 24/7, on your own servers, VMs, Kubernetes or cloud account. How much work it is depends on your schema size, code volume, the number of applications that connect and the downtime window you can accept, so a written assessment sets the plan and the dates. Enter your work email to start with a 15-minute discovery call.
- Migrations we run
- Oracle, SQL Server and MySQL to PostgreSQL, from one team, then support on the result
- The four phases
- Assessment, conversion, dual run, cutover; then support
- Tools
- Ora2Pg, orafce, pgloader, AWS DMS and DMS Schema Conversion, Babelfish Compass. Mostly open source, so you keep them
- What sets the scope
- Schema size, code volume, number of connecting applications and the downtime window you can accept
- Patch window
- Critical CVEs (CVSS 9.0 or higher) within 48 hours, High within 7 days
- Support hours
- Assure includes 24/7 reactive support; Operate adds managed operations and a 15-minute P1 response
Source and PostgreSQL dates checked on endoflife.date on 20 October 2026. Tool behaviour from the Ora2Pg, orafce, pgloader, Babelfish, mysql_fdw and AWS DMS documentation, fetched on 20 October 2026.
Last reviewed
Trusted globally by enterprises
Migrations we run
Each source has its own page with its own checklist. Start with the one that matches your estate; the plan below is the same for all three.
Oracle Database
Oracle to PostgreSQL migration
Ora2Pg exports the schema and data, and orafce supplies Oracle-compatible functions and packages. PL/SQL is where the effort sits: packages, data types and built-in packages are reviewed by hand and tested.
Oracle 19c: Premier Support to 31 Dec 2029, Extended to 31 Dec 2032. 21c: ends 31 Jul 2027.
Oracle to PostgreSQL migrationMicrosoft SQL Server
Migrate SQL Server to PostgreSQL
pgloader discovers the schema, indexes and keys and loads the data. T-SQL procedures are rewritten in PL/pgSQL against a checklist, and Babelfish is an alternative for some applications.
SQL Server 2016: out of support since 14 Jul 2026, ESUs to 17 Jul 2029. 2017: 12 Oct 2027. 2019: 8 Jan 2030.
Migrate SQL Server to PostgreSQLMySQL
Migrate MySQL to PostgreSQL
pgloader moves the schema and data. Views, triggers, routines and events are rewritten, and types, collations and MySQL-specific SQL follow an incompatibility checklist.
MySQL 5.7 ended 31 Oct 2023, 8.0 on 30 Apr 2026. 8.4 LTS: Premier Support to 30 Apr 2029, ends 30 Apr 2032.
Migrate MySQL to PostgreSQL| Source | What tools convert | What needs a person | Does OSSeva support the source? |
|---|---|---|---|
| Oracle Database | Schema, data, and Oracle-compatible functions through Ora2Pg and orafce | PL/SQL packages and procedures, Oracle-specific features, the applications that call them | No. OSSeva migrates away from Oracle and does not support it |
| SQL Server | Schema discovery, indexes, keys and data through pgloader | T-SQL procedures and triggers, Agent jobs, SSIS packages and reports, linked servers | No. OSSeva migrates away from SQL Server and does not support it |
| MySQL | Schema and data through pgloader, under written casting rules | Views, triggers, stored routines, events and the MySQL-specific SQL in applications | Yes. MySQL 5.7 and 8.0 get patched builds, and 8.4 and 9.7 LTS are supported |
Moving a database off an ageing or proprietary engine is database modernization in its narrowest form, and this page covers the database move itself.
The phased plan for every database migration
The same four phases apply to Oracle, SQL Server and MySQL. Each phase ends with something you can review before the next one starts, and each can end with a decision to stop.
1. Assessment
An inventory of databases, code objects and every client that connects, with a first read from Ora2Pg's assessment report or Babelfish Compass where they apply. For each database the written plan says migrate, defer or stay, and why.
2. Conversion
The schema is converted and the stored code is rewritten in PL/pgSQL by people and reviewed. Data loads are rehearsed with row counts and checksums compared on both sides, and the casting rules are written down for the columns that need them.
3. Dual run
Applications, reports and scheduled jobs run against PostgreSQL alongside the source until the results match. This is where the differences that no tool reports show up.
4. Cutover
A cutover runbook with a final sync, go and no-go checks and a rollback plan, run with your team in the change window. The cluster moves into support the same day.
What drives the scope of a database migration
We do not quote a duration in advance, because a number of weeks that fits one estate misleads for another. These are the factors that set the scope, and what the assessment writes down for each.
| Scope factor | Why it drives the effort | What the assessment records |
|---|---|---|
| Schema size and object count | Every table, index, constraint and sequence is loaded, validated and compared, so more objects mean more rehearsal output to review. | Counts of tables, indexes, constraints, sequences and partitions per database |
| Stored-code volume | PL/SQL, T-SQL and MySQL routines, triggers and views are rewritten by people and tested against the same inputs. Conversion tools produce a first draft at best. | Routines, triggers and views per database, grouped by complexity |
| Engine-specific features | Oracle packages and database links, SQL Server linked servers and Agent jobs, and MySQL events and ON UPDATE columns have no direct equivalent and each needs a decided route. | A feature inventory with the chosen route for each item |
| Connecting applications and clients | Each driver, ORM, report, ETL job and scheduled job must be re-pointed and tested. An application that a vendor certifies only on the source engine usually stays where it is. | A connection inventory with an owner for each client |
| Data volume and change rate | Volume sets how long a load rehearsal runs, and the rate of change decides whether the final sync is a plain load or needs continuous replication. | Database sizes, the largest tables and the write rate |
| Downtime window | A window that fits a final sync allows a simple cutover. A short window means replication into the target and a more careful runbook. | The window each application can accept |
| Test coverage | A regression suite shortens the dual run. Without one, results are compared by hand, and that comparison sets the pace. | What automated tests exist and which reports can be compared |
| Target platform | Self-managed PostgreSQL on servers, VMs or Kubernetes and a hosted target such as Aurora or RDS use different tools for the schema and the data. | The chosen target and who runs it afterwards |
Which database migration tool does which job
There is no single best tool for database conversion. Most are free, and you keep them after the project. The cloud providers' own migration services move data into their platforms; this table covers the tools that also work for PostgreSQL on infrastructure you control.
| Tool | What it does | What it leaves to you |
|---|---|---|
| Ora2Pg | Exports an Oracle schema and data to PostgreSQL, and its README also lists MySQL, MariaDB and SQL Server migration. Includes migration assessment reports. Free software under GPL v3 or later. | Its documented code conversion is PL/SQL to PL/pgSQL, with manual work still to do. Review everything it generates. |
| orafce | A PostgreSQL extension with Oracle-compatible functions such as nvl, decode and listagg, and packages such as DBMS_OUTPUT and UTL_FILE. | Oracle features outside its README, such as DBMS_SCHEDULER and DBMS_LOB, need another route. |
| pgloader | Loads MySQL and SQL Server data into PostgreSQL with automatic schema discovery, indexes and keys, and configurable casting rules. Open source. | Stored procedures and functions. For MySQL its documentation lists views and triggers as not migrated. |
| AWS DMS | Moves data, including ongoing change capture, from MySQL-compatible and other supported sources into PostgreSQL targets. | Schema conversion. Documented limits include sequences not being migrated during ongoing replication. |
| AWS DMS Schema Conversion | Converts Oracle, SQL Server and MySQL schemas to Aurora PostgreSQL or RDS for PostgreSQL, with an assessment report. Generative AI conversion is listed for the Oracle and SQL Server paths, not the MySQL one. | The data: it converts the schema, not the data. Its targets are Aurora and RDS only. |
| Babelfish and Babelfish Compass | Babelfish lets PostgreSQL accept SQL Server clients and much of T-SQL. Compass analyzes T-SQL scripts for compatibility with it. | A subset of T-SQL, and a PostgreSQL build with patches to the community code. AWS offers it managed on Aurora; self-managed Babelfish is not part of OSSeva support. |
From the Ora2Pg and orafce READMEs, the pgloader 3.6.10 documentation, the Babelfish and Babelfish Compass documentation and the AWS DMS user guide, fetched 20 October 2026.
Support after cutover
The new cluster moves into OSSeva support on the day of cutover, wherever it runs: your servers, VMs, Kubernetes or cloud account. The team that moved your data is the team that answers the pager, and Assure includes 24/7 reactive support.
| Tier | What it adds | Response and patch terms |
|---|---|---|
| Patch | Signed PostgreSQL builds with backported security fixes once your major version passes community end of life (17 on 8 November 2029, 18 on 14 November 2030). | Critical CVEs (CVSS 9.0 or higher) patched within 48 hours, High within 7 days. |
| Assure | Everything in Patch, plus major-version migration planning, a performance and vacuum configuration audit, a compliance attestation package and 24/7 reactive support. | 24/7 reactive support. |
| Operate | Everything in Assure, plus managed operations: replication and failover monitoring, Patroni, repmgr and quorum monitoring, vacuum and analyze tuning, point-in-time recovery testing and quarterly capacity reviews. | 15-minute P1 incident response. |
Tier contents from the OSSeva PostgreSQL technology page. Support is priced per cluster; the discovery call gives the quote. PostgreSQL end-of-life dates from endoflife.date, checked 20 October 2026.
When a migration is not the answer
The assessment ends in a verdict per database, and staying is one of the verdicts.
Migrate when
- You own the application code, so the database is a choice
- A support date or licence renewal forces a decision on each database
- You want one engine, one patch cycle and one support contract across the estate
Stay or upgrade when
- A vendor certifies its product only on the current engine
- The goal is a supported version of MySQL: upgrading to 8.4 LTS is often less work
- An in-place upgrade or vendor extended support for Oracle or SQL Server fits the plan; those vendors are the right partners
Other exits
Database moves are the largest part of this service. The messaging, streaming and framework exits have their own pages.
Which service providers offer database migration services?
Three kinds. Cloud providers sell tooling that moves data into their own platforms: AWS Database Migration Service, Google Cloud Database Migration Service and Azure Database Migration Service. Consultancies run end-to-end projects for a stated target. OSSeva runs Oracle, SQL Server and MySQL migrations to community PostgreSQL on infrastructure you control, then supports the cluster 24/7, so the team that moved the data answers the pager afterwards.
What is the best database migration tool?
It depends on the source and the target. Ora2Pg suits Oracle, pgloader suits MySQL and SQL Server data, orafce fills Oracle function gaps, and AWS DMS adds ongoing change capture. DMS Schema Conversion converts schemas for Aurora and RDS targets. No tool converts stored code completely, so the table on this page shows what each one leaves to people.
Who migrates databases to PostgreSQL and supports them afterwards?
OSSeva. A single engagement runs the assessment, conversion, dual run and cutover, and the new PostgreSQL cluster moves into support the same day. Patch delivers signed builds, Assure adds 24/7 reactive support and upgrade planning, and Operate adds managed operations with a 15-minute P1 response.
What does a database migration service include?
Here: a written assessment, schema and code conversion, rehearsed data loads, a parallel run against your applications, a cutover runbook with a rollback plan, and support afterwards. The deliverables per phase are listed above.
What is database modernization?
Moving a database off an ageing or proprietary engine onto a current one. On this page it means moving Oracle, SQL Server or MySQL databases to PostgreSQL, a community-governed engine released under the PostgreSQL License with no per-core fee. Whether it pays depends on your own licences, hardware and staffing, so the database support cost calculator works from the numbers you enter.
What is database conversion?
The part of a migration that changes the database objects: tables, data types, indexes, views, triggers and stored code are translated from one engine's dialect to another's. Tools handle the mechanical part, and people rewrite and test the code that does not translate.
How long does a database migration take?
We do not quote a duration in advance. Schema size, the volume of stored code, the number of applications that connect, the data volume and the downtime window you can accept set the scope, and the written assessment turns them into a plan with dates.
Can you migrate without downtime?
Often with a short, planned cutover window rather than none. The dual run keeps the source live, and where the window must be short, continuous replication keeps the target in step until the switch. Whether that is practical depends on the engine, the write rate and the applications, and the assessment records the window each one can accept.
Does OSSeva support Oracle Database or SQL Server?
No. For those two engines OSSeva is a migration-out service: it assesses, converts and supports the PostgreSQL you land on. OSSeva does support MySQL, with patched builds for 5.7 and 8.0 and support for 8.4 and 9.7 LTS, so MySQL stays covered while you migrate.
Should we migrate at all?
Not always. If an application is certified only on its current engine, it usually stays. For MySQL, upgrading to 8.4 LTS is often less work. For Oracle and SQL Server, an upgrade or extended support from the vendor is a valid answer. The assessment gives a plain verdict per database: migrate, defer or stay.
How is it priced?
The migration is a services engagement and the support afterwards is priced per cluster. A 15-minute discovery call gives you a quote, and the database support cost calculator works from your own figures.
Get a quote
Start a database migration with a written assessment.
Enter your work email, or book a 15-minute discovery call. The written assessment follows, and support is priced per cluster.
Prefer to talk or read more first?