Migrate Firefly from Docker to Kubernetes

[cristiangrossano]

Good morning everyone,
In order to level up my skills at work, I'm migrating my homelab from Docker to Kubernetes. After deploying Firefly with the Helm chart, it came time to migrate my transactions.

In Docker I have a MariaDB, and in Kubernetes there's a Postgres DB.
After exporting all my transactions with the built-in option in my old installation, I'm trying to import them into the new instance with the Firefly Importer, but I'm struggling with field assignment.

In the end I would like to have all the settings, accounts, budgets and rules from the old installation inside the new Kubernetes deployment.

Has anyone gone through a similar migration before? Any tips on how to properly map the fields during import would be greatly appreciated!

[goutamadwant]

I would avoid using the transaction CSV as the migration mechanism for this. It can recreate transaction data through the Data Importer, but it is not a lossless backup/restore format for an installation and will not faithfully reconstruct settings, object IDs, relationships, rules, budgets, recurring transactions, and every piece of metadata.

The safest migration is to separate the infrastructure move from the database-engine change:

1. Deploy Firefly III in Kubernetes with MariaDB/MySQL first, ideally using the same Firefly III version as the Docker installation.
2. Stop writes to the old instance and take a verified MariaDB dump.
3. Restore that dump into the Kubernetes MariaDB.
4. Carry over the same APP_KEY and the relevant Firefly environment configuration/secrets.
5. Start Firefly III, allow its normal migrations to run, then validate user access, account balances, transaction counts, budgets, rules, recurring transactions, and attachments.
6. Upgrade the application only after that migration is proven.

Firefly's firefly-iii:export-data command can export separate CSV files for accounts, budgets, categories, tags, recurring transactions, rules, subscriptions, piggy banks, and transactions. Those are useful as audit/reference exports, but the Data Importer is not the inverse of that command.

If PostgreSQL is mandatory, treat MariaDB-to-PostgreSQL as a second, rehearsed database-conversion project rather than an Importer field-mapping task. A tool such as pgloader may help, but test it against a disposable copy and validate foreign keys, row counts, decimal values, timestamps, JSON/text fields, sequences, and application behavior before switching. Keep the original dump until the new instance has been exercised and backed up.

This approach also makes rollback straightforward: the old Docker database remains untouched while the Kubernetes copy is validated.

References: Firefly III CSV importer workflow and the repository's firefly-iii:export-data command.