Automate Migration from Firebird 3.0 to Firebird 5.0

[zedalaye]

Hello,

I remember we already talked about this some time ago.

For now, I deploy Firebird 3.0 with my application. I want to upgrade to Firebird 5.0 and provide my users with a simple more or less automatic upgrade path.

I made sure my database is compatible with Firebird 5.0

My ideal plan would be:

• Package a Firebird 5.0 instance with Engine12.dll and according firebird.conf
• Provide a tool that run the backup/restore cycle (this tool is already bundled with the application to create nightly backups)

But this supposes that Firebird 5.0 (using Services Manager ?) can backup a Firebird 3.0 database using Engine12.dll and as far as I remember, this will not work unless something changed in recent Firebird 5.0.

The other, heavier plan, is:

• During app new installations : deploy Firebird 5.0
• During app updates, detect which version of Firebird is currently in use and update accordingly. If Firebird 3.0 is installed, deploy Firebird 5.0 but don't install the service.
• Provide a tool to run the migration : backup using Firebird 3.0, unregister/uninstall Firebird 3.0, register/install Firebird 5.0 and restore the databases using Firebird 5.0

What do you think about this plan, seems usable ? Have you already found a way to ease upgrade from Firebird < 5.0 to Firebird 5.0 ?

Thank you,

--
Pierre Y.

[zedalaye]

The previous discussion was here : https://groups.google.com/u/1/g/firebird-support/c/7Z2GkfoJ0Hc/m/CzA1Pv5FBwAJ

[NorpaNet]

Hi Pierre, 1) Close all instances of Firebird 2) run gbak version 3 in embedded mode for the backup 3) run gbak version 5 in embedded mode for restoration Norbert De : Pierre Yager ***@***.***> Envoyé : jeudi 19 juin 2025 18:40 À : FirebirdSQL/firebird ***@***.***> Cc : Subscribed ***@***.***> Objet : [FirebirdSQL/firebird] Automate Migration from Firebird 3.0 to Firebird 5.0 (Discussion #8617) Hello, I remember we already talked about this some time ago. For now, I deploy Firebird 3.0 with my application. I want to upgrade to Firebird 5.0 and provide my users with a simple more or less automatic upgrade path. I made sure my database is compatible with Firebird 5.0 My ideal plan would be: * Package a Firebird 5.0 instance with Engine12.dll and according firebird.conf * Provide a tool that run the backup/restore cycle (this tool is already bundled with the application to create nightly backups) But this supposes that Firebird 5.0 (using Services Manager ?) can backup a Firebird 3.0 database using Engine12.dll and as far as I remember, this will not work unless something changed in recent Firebird 5.0. The other, heavier plan, is: * During app new installations : deploy Firebird 5.0 * During app updates, detect which version of Firebird is currently in use and update accordingly. If Firebird 3.0 is installed, deploy Firebird 5.0 but don't install the service. * Provide a tool to run the migration : backup using Firebird 3.0, unregister/uninstall Firebird 3.0, register/install Firebird 5.0 and restore the databases using Firebird 5.0 What do you think about this plan, seems usable ? Have you already found a way to ease upgrade from Firebird < 5.0 to Firebird 5.0 ? Thank you,

…

-- Pierre Y. — Reply to this email directly, view it on GitHub <#8617> , or unsubscribe <https://github.com/notifications/unsubscribe-auth/BJEAUKWJL6EJGDEHN4F72YD3ELKUFAVCNFSM6AAAAAB7WHUZTGVHI2DSMVQWIX3LMV43ERDJONRXK43TNFXW4OZYGQ3TEOJYGY> . You are receiving this because you are subscribed to this thread. <https://github.com/notifications/beacon/BJEAUKXLY3WJTJDDQAQ43U33ELKUFA5CNFSM6AAAAAB7WHUZTGWGG33NNVSW45C7OR4XAZNKIRUXGY3VONZWS33OVJRW63LNMVXHIX3JMTHABAKJTI.gif> Message ID: ***@***.***>

[mrotteveel]

1. Close all instances of Firebird

You don't need to close all instances of Firebird, you just need to close all connections to the database you want to backup.

[PedroCostinha]

Hi Pierre!

I agree with the suggestion to use Firebird 3's gbak for the backup and Firebird 5's gbak for the restore.

For an automated application upgrade, I would add a few safeguards:

1. Detect the current Firebird version and confirm the application is running against the expected database.
2. Stop new application connections and ensure the database is no longer being modified.
3. Create a full backup using the Firebird 3 tools.
4. Restore with Firebird 5 into a new database file, never directly over the existing Firebird 3 database.
5. Validate the restored database before switching the application: key table counts, important queries, stored procedures, triggers, character sets, and application-level smoke tests.
6. Preserve the original Firebird 3 database and configuration until the upgrade has been accepted.
7. Switch the application's database connection only after the validation succeeds.

I would also separate the migration operation from the application update itself, so a failed restore does not leave the application pointing to a partially migrated database.

If the Firebird 5 validation fails, the rollback should reconnect to the untouched Firebird 3 database using the original Firebird 3 runtime. A restore is not an in-place reversible upgrade.

This would make the process safer for unattended installations, especially where the application and Firebird are deployed together.