What are the changes?
Billing entity on wallet transactions
With multi-billing-entity billing, a customer’s subscriptions, wallets and invoices are no longer tied to a single billing entity, and different wallets of the same customer can belong to different entities. To keep accounting traceable, wallet transactions now store their ownbilling_entity_id, stamped at creation time. A transaction therefore always reports the entity it was actually created under, even if the wallet is later moved to another entity. Only transactions created after the move carry the new entity.
As a result, existing wallet transactions must be backfilled with the billing entity of their customer. This is done through a rake task that must be triggered manually.
Search terms on invoices
Invoices now carry a denormalizedsearch_terms column, backed by a GIN trigram index. It concatenates the invoice number, the purchase order number and the customer identifiers the invoice list searches on: name, first name, last name, legal name, external ID and email.
Invoices created, finalized or regenerated from now on maintain their search terms automatically, and so do the invoices of a customer whose details change. However, existing invoices must be backfilled. This is done through a rake task that must be triggered manually.
Why are we doing this?
Previously, the billing entity of a wallet transaction could only be inferred from its customer, which had exactly one entity. Now that a wallet can be moved between entities, inferring the entity would retroactively rewrite the history of past transactions. Storing the entity on each transaction keeps historical records accurate and entity-level accounting reliable. Searching the invoice list previously had to join and scan thecustomers table on every keystroke, which gets slower as the invoice table grows. Reading the terms from a single indexed column on invoices keeps the search fast whatever the volume.
What should self-hosted users do?
Cloud users do not need to follow these instructions as the migration will be performed by the Lago Team.
Migration Steps
1. Install Lago v1.52.0
Install the new version. Schema migrations (new tables and columns) will run automatically on startup.2. Backfill wallet transactions
Open a shell on your API server and run the migration task:The backfill task is safe to run multiple times. It only targets wallet transactions without a billing entity, so already-migrated records are left untouched.
3. Backfill invoice search terms
From the same shell, run the second migration task:low_priority queue, so make sure a Sidekiq worker is draining that queue. The job logs Finished backfilling invoices.search_terms once the walk is over.
If the backfill is interrupted, resume it from the last invoice ID it reported instead of starting over:
This task is also safe to run multiple times. It only rewrites the invoices whose search terms have changed, so already-migrated records are left untouched.