SQL Transpiler for Database Migration: Best Tools, Approaches, and Real Projects

Most database migrations stall on procedural code rather than on data. A SQL transpiler is built for that part of the work, since it reads stored procedures, functions, triggers, and views written for one engine and rewrites them for another.

Whether the source is Oracle, DB2, Sybase, Informix, or Teradata, somebody has to transpile that code before PostgreSQL, MySQL, SQL Server, or a managed cloud service will run it.

Moving the data is routine by comparison. Every vendor ships utilities for it, and the volume mostly affects the length of the maintenance window.

The code layer behaves differently. Manual conversion runs at roughly 300 to 400 lines per developer per day, based on Ispirer's project metrics, so 250,000 lines cost around 700 developer-days.

That arithmetic often decides whether the migration is approved at all, which is why the choice of converter matters before the first object is touched.

The rest of this article covers where dialects diverge, how transpiling differs from compiling and from other migration strategies, which products fit which case, and what documented projects run withIspirer SQLWays produced in practice.

Why SQL is hard to transpile between engines

ANSI SQL is a baseline, and every vendor extends it. Two engines can both claim compliance and still return different results for the same query.

Most of the differences belong to a few categories:

• Type semantics. Oracle's DATE carries a time component, NUMBER has no direct PostgreSQL equivalent, and an empty string is treated as NULL. Collations, national character types, and LOB handling add more rules.
• Procedural extensions. PL/SQL, T-SQL, PL/pgSQL, and SQL PL differ in exception handling, cursor behaviour, package structure, autonomous transactions, and output parameters.
• Transaction and error behaviour. T-SQL keeps running after certain runtime errors, while PostgreSQL aborts the transaction. Code that relied on the first behaviour breaks after conversion.
• Built-in functions.NVL, ISNULL, and COALESCE overlap without matching exactly. Date format masks, string position indexing, and implicit casts all follow vendor rules.
• Structural constructs. Row limiting (ROWNUM, TOP, FETCH FIRST, LIMIT), hierarchical queries, sequences, identity columns, computed columns, and temporary table scoping need rewriting rather than renaming.
• Naming rules. PostgreSQL folds unquoted identifiers to lower case, SQL Server depends on collation, and each engine reserves a different set of words.

Task	Oracle	SQL Server	PostgreSQL
Null substitution	NVL(x, 0)	ISNULL(x, 0)	COALESCE(x, 0)
First N rows	ROWNUM <= 10	TOP 10	LIMIT 10
String concat	a || b	a + b	a || b
Current timestamp	SYSDATE	GETDATE()	now()
Hierarchy	CONNECT BY	recursive CTE	recursive CTE
Empty string	treated as NULL	distinct from NULL	distinct from NULL

Code that compiles is not the goal. The converted object has to return the same rows, raise the same errors, and leave the same data behind.

Timing complicates the work. Compatibility gaps rarely show up while a project is being scoped, and they surface during testing, when the schedule is fixed and the source code has kept changing.

What is a SQL transpiler, and what does it do

A SQL transpiler translates source code into target code. It reads SQL and procedural SQL written for one engine and produces SQL for another, in a form that developers can read, review, and maintain.

A production tool works in stages:

1. Parsing of the source dialect into a syntax tree.
2. Semantic analysis against catalog metadata: types, dependencies, object relationships, reserved words.
3. Rule-based transformation of the tree, including constructs that have no equivalent in the target.
4. Code generation in the target dialect, with mapping rules applied to types and identifiers.
5. Reporting on what converted cleanly and what needs a decision from an engineer.

Why it is harder to transpile modules than statements

A single SELECT converts mechanically, since the gap between two dialects comes down to function names and syntax. Stored modules absorb most of the project time.

The standard calls them persistent stored modules, and each vendor built them differently: packages in Oracle, batches and table-valued functions in SQL Server, a separate exception model in each product.

A procedure carries control flow, transaction boundaries, error handling, and calls to other objects, so its conversion has to preserve behaviour and not only syntax.

Converters are applied to:

• migrate a full database layer, schema and logic together;
• replatform to a cloud service running a different engine;
• support one product on several database backends;
• port analytical queries between query engines;
• convert SQL embedded in application code, scripts, and test harnesses;
• reduce dependency on a single vendor's dialect.

A SQL transpiler will not choose a physical design, tune indexes for the new planner, or decide which legacy logic should be retired instead of carried over.

Transpile definition: what is transpile, and how it differs from compile

To define transpile precisely: it is translation between two languages at the same level of abstraction, with readable source code as the result. The transpile meaning does not change with the language, and in a database project the two languages are a source dialect and a target dialect.

Compile vs transpile in a database context

Compiler	Transpiler
Input and output	High-level source into machine or byte code	Source into source at the same level
Output readability	Not meant for humans	Reviewed and maintained by developers
Purpose	Execution	Portability
SQL example	The engine turning a query into an execution plan	Converting T-SQL into PL/pgSQL

Inside a database, the transpile vs compile difference is concrete. Compilation there refers to the optimiser building an execution plan, while transpiling happens earlier and produces text that a developer can open and edit.

What else can move SQL off a legacy engine

Transpiling is one option among several, and each of them gives up something different.

Approach	How it works	Strengths	Limits
Manual rewrite	Engineers port objects by hand	Full control, room to refactor	Slow, expensive, inconsistent across a large group of developers
Transpiler	Rule-driven conversion of schema and logic	Repeatable, auditable, scales with codebase size	Edge cases still need engineering judgement
Compatibility layer	The target engine emulates the source dialect (Babelfish, Orafce, EDB Postgres Advanced Server)	Little or no code change	The dialect dependency stays, coverage has gaps
Logic moved to the application	Procedures rewritten in Java, C#, or an ORM	The database becomes replaceable	Large redesign, new performance profile
Federation or virtualisation	One layer queries several sources	Postpones the migration	Adds a component instead of removing one
LLM-based conversion	A model rewrites code from prompts	Flexible on unusual constructs	Non-deterministic, hard to audit at scale

Determinism deserves attention when these options are compared. A migration product returns the same output for the same input on every run, so a defect found in one converted procedure gets fixed once at the rule level.

A model still has a place afterwards, in verification, refactoring suggestions, and documentation of the converted code.

Which tools transpile code, and where SQLWays fits

How converters differ from one another

Products that convert SQL are not interchangeable, and the differences show up in the first week of a project.

The first difference is scope. Query-level libraries take one statement at a time and rewrite it for another dialect, which covers the needs of an application or a data pipeline.

Full migration products work on the whole database layer: schema, procedures, triggers, packages, plus the data and its loading into the target.

The second difference is how the product runs. A library is called from code, a command-line converter fits into a build or a batch job, and a graphical interface suits work that goes object by object with review along the way.

The third difference is what drives the conversion. Grammar-based engines apply rules to a parsed tree and return the same answer every time, which matters when one construct repeats across a thousand procedures.

Model-based converters read code more loosely and cope with unusual constructs at the cost of predictability, while mixed setups use rules for volume and a model for review.

Tool	Type	Coverage	Notes
Ispirer SQLWays	Commercial toolkit	Full database layer, 240+ directions	Rule-based core with customisation and AI verification
SQLGlot	Python library	Queries across 30+ dialects	Parser, transpiler, and optimiser, used inside data pipelines and query engines
Apache Calcite	Java framework	Query planning and dialect-aware SQL generation	A base for query engines rather than a migration product
jOOQ	Java library	Query translation at runtime and through a translator	Oriented toward application code
Ora2Pg	Open-source utility	Oracle to PostgreSQL	One direction, widely used, manual work on complex PL/SQL
AWS DMS Schema Conversion	Cloud service	Schema and code toward AWS targets	Runs in AWS and converts toward AWS databases
Babelfish	Compatibility layer	T-SQL on Aurora PostgreSQL	Emulation rather than conversion

Ispirer SQLWays: what it converts and how

Ispirer Toolkit covers database migration and application conversion, andSQLWays is the product inside it that handles the database layer.

It converts schema and business logic and then moves the data, covering tables, constraints, indexes, views, stored procedures, functions, triggers, packages, user-defined types, macros, synonyms, sequences, defaults, and user accounts.

Features that matter specifically for SQL translation:

• Range of supported sources. Along with current engines, the product handles legacy systems that most cloud services skip, among them Informix, Sybase ASE and ASA, DB2 z/OS and AS/400, Progress, Teradata, and Firebird.
• Conversion core. The engine analyses data types, object relationships, reserved words, and constructs that have no equivalent in the target, instead of matching patterns in text.
• Mapping controls. Global and local data type mapping, object name mapping, reserved-word conflict resolution, configurable delimiters, and dependency-aware import ordering let a project decision be set once and applied everywhere.
• Customisable conversion rules. For unusual codebases, Ispirer adjusts or adds rules inside the product. The company reports automation above 95% where this is done, and the AWS review describes the same effect from its customisation licence.
• AI-assisted verification. The assistant checks converted objects against the source and helps with error handling, refactoring, and documentation. It runs on a local model or an external provider, so code does not leave the customer's network on regulated projects.
• Data movement. SQLWays connects to sources over ODBC and loads targets through native utilities at around 60 GB per hour.Ispirer Data Migrator reaches about 250 GB per hour using foreign data wrappers and parallel threads.
• Deployment and security. The product runs on Windows, Linux, or Unix regardless of where the databases sit, works on premises and from the command line, uses read-only privileges on the source, and does not send processed code anywhere. Ispirer maintains an ISO/IEC 27001:2022 information security management system.
• Neighbouring products.InsightWays produces a free complexity assessment before the project starts, andCodeWays converts SQL that lives in application code rather than in the database.

Reported productivity increases from 300–400 lines of code per developer per day with manual conversion to 3,000–5,000 lines with the Ispirer Toolkit.

Six migrations and their numbers

Customer	Direction	Scope	Result
DemandTec	DB2 LUW 11.05 to PostgreSQL 16 on Azure	~1,100 objects, ~250K lines, ~60 SQLJ procedures	2,800 to 3,000 lines per developer per day, about 7 times manual speed, defect rate under 10%
Magnit	Oracle and SQL Server to PostgreSQL	1.36M lines, 8 TB	Migration time reduced by 50%
Cardinal Health	SQL Server to PostgreSQL	700+ tables, 650+ stored procedures	Development time cut by 60 to 70%
Worldline	Oracle 19c to PostgreSQL	~1.5M lines, 8 TB	99% of database objects converted
Ndex Systems	Sybase to MySQL	4,000+ procedures, 200+ tables	95% automatic conversion
Fashion retailer	SQL Server to PostgreSQL on AWS	8 TB	40% cost reduction, 60% peak performance gain, 5 months

TheDemandTec case study documents the split between automated conversion and manual work.

Ispirer's engineers added over 30 improvements to the conversion pipeline for DB2 patterns such as computed columns, dynamic SQL, and sequences with negative values. The 60 SQLJ procedures with embedded Java had no automation path and were converted to PL/pgSQL by hand.

Seven questions worth asking a vendor

1. Does the product support your exact source and target pair, including the specific versions?
2. Does it convert procedural code, or only schema and queries?
3. Can conversion rules be extended for your codebase, and by whom?
4. Is the output readable code that your developers will own afterwards?
5. Does the report map unconverted constructs to the objects they sit in?
6. Where does your code go during conversion, and does that satisfy your compliance requirements?
7. Is there an assessment step that gives a defensible estimate before the project starts?

What to decide before the first object is converted

Dialect translation is the part of a database migration that scales badly by hand and well through automation. A SQL transpiler does not remove engineering judgement, and no product converts embedded Java procedures or undocumented business rules without someone reading them first.

A converter handles the repetitive majority of the code and exposes the rest while the schedule can still absorb it. For query portability inside applications and data pipelines, libraries such as SQLGlot, Calcite, and jOOQ are usually enough.

For moving a full database layer off a legacy engine, a complete toolkit fits better.Ispirer SQLWays covers the widest set of source systems among the commercial options, with rule customisation for code that generic converters do not handle.

An assessment comes first regardless of the product. Object counts, code volume, and the list of constructs with no target equivalent are what a realistic estimate needs.