One-time migration - DBConvert
Transfer selected tables and data, review the generated type mappings, and recreate supported indexes and foreign keys. InterBase stored procedures and triggers (PSQL) remain a separate rewrite task.
InterBase Migration Tools
Move data off Embarcadero InterBase onto SQL Server, PostgreSQL, or MySQL - or load data back in. DBConvert handles InterBase through its Firebird-compatible tools: use DBConvert for a one-time migration or DBSync to keep both databases aligned during a staged cutover.
Choose the right InterBase tool
Start with what must happen after the initial data transfer.
Recurring synchronization - DBSync
Run the initial load, then synchronize inserts, updates, and deletes on a schedule. Use it when InterBase has to stay aligned with the target during a phased cutover.
Several platforms - DBConvert Studio
One application for the same InterBase directions plus other database platforms - useful when a single project spans more than one engine. It does not add InterBase pairs beyond the Firebird-compatible ones.
Download an InterBase pair tool
InterBase uses the Firebird-compatible connection, so the installer name contains firebird. Pick DBConvert or DBSync for the other database in your pair.
Price and licensing
- $179 one-time license for each DBConvert or DBSync pair tool.
- Each pair tool runs both directions - InterBase as source or destination.
- DBConvert migration and DBSync synchronization are licensed separately; Studio uses separate multi-platform pricing.
Trial and runtime
- Free, time-unlimited trial with record and feature limits.
- Windows desktop application.
- Connects to a running InterBase server the Windows machine can reach.
How an InterBase migration works
-
1
Connect both databases
Select InterBase through the Firebird-compatible connection, then configure SQL Server, PostgreSQL, or MySQL as source or destination.
-
2
Review the target structure
Choose tables and fields, then review generated data types, indexes, keys, and table mappings before anything is written.
-
3
Run and validate
Transfer the data, inspect the results, and validate application behavior before the production cutover.
InterBase and Firebird
Firebird was forked from InterBase 6 and kept the same client protocol, so DBConvert handles InterBase through its Firebird-compatible pair tools.
How the connection is set up
- Download names and the InterBase connection use
firebird; configure host, port, the.gdb/.ibdatabase, user, and password. - The database must be served by a running InterBase or compatible Firebird instance the tool can reach.
Which directions are supported
- Packaged as Firebird pairs: SQL Server (including Azure SQL) and PostgreSQL.
- Also MySQL/MariaDB and Access, both directions.
Native backup versus cross-engine migration
InterBase's own tools are built for backup and same-engine restore, not for loading into another SQL dialect.
gbak backup
Produces an InterBase backup file that only restores into InterBase or Firebird. It does not generate a schema another engine can read.
isql scripts
Extracted DDL uses InterBase syntax, domains, and generators that SQL Server or PostgreSQL will not accept without rewriting.
CSV export
Moves rows but drops data types, primary keys, indexes, and foreign keys. You rebuild the schema by hand on the target first.
DBConvert generates a target structure for review, transfers the selected data, and recreates supported indexes and keys in one pass. Validate the mappings and application behavior before cutover.
InterBase Migration Directions
Start with the pair that matches the other database. SQL Server and PostgreSQL are the most requested.
InterBase ↔ SQL Server
Use the SQL Server/Firebird-compatible pair for transfers between InterBase and SQL Server, including Azure SQL. Review the generated mappings before the run:
- InterBase data types are mapped to SQL Server equivalents and remain adjustable per field.
- Identifier quoting and target table definitions are generated for SQL Server.
- Supported indexes and foreign keys are recreated after the structure is reviewed.
Separate rewrite: InterBase stored procedures, triggers, and generators (PSQL) are not auto-translated to T-SQL.
InterBase ↔ PostgreSQL
Use the PostgreSQL/Firebird-compatible pair for transfers between InterBase and PostgreSQL. Treat schema conversion and application SQL as separate review tracks:
- Review numeric, character, date/time, and BLOB mappings against the generated PostgreSQL schema.
- InterBase domains resolve to their base column types on the target.
- Supported indexes and primary/foreign keys are recreated with the transferred tables.
Separate rewrite: PSQL procedures and triggers are not converted to PL/pgSQL automatically.
Other InterBase directions
InterBase ↔ MySQL / MariaDB
Migrate InterBase into MySQL or MariaDB, or load MySQL-family data back into InterBase.
InterBase ↔ Access
Move Microsoft Access tables into InterBase, or pull InterBase data into an Access file.
InterBase specifics to plan for
A few InterBase features don't map one-to-one. Account for them before transfer:
Generators
InterBase uses generators for auto-numbering, usually driven from a trigger. They aren't carried as table data - recreate the equivalent IDENTITY, sequence, or AUTO_INCREMENT on the target.
Domains
Columns built on InterBase domains resolve to their base type on the target. Review the generated types so constraints and defaults are preserved where they matter.
SQL dialect 1 vs 3
Older dialect-1 databases differ in identifier quoting and date/time handling. Check the source dialect, because it changes how values are read.
PSQL and character set
Stored procedures and triggers are written in InterBase PSQL and stay a manual rewrite. Note the database character set so text converts cleanly to the target encoding.