Move from Lago to yRecurring.
Lago stores only provider ids for payment methods, so the cards are already in your Stripe, Adyen or GoCardless account. Invoices export from the app; the rest comes from the API or, self hosted, straight from your database.
See how Lago and yRecurring compare →What is different about leaving Lago
Billable metrics become meters
Count, sum, max and latest aggregations map to yRecurring meters (count, sum, max, last). Unique count and weighted sum have no direct equivalent: send the value your app already counted, active seats at the end of the period for instance, and meter it with last or max.
Charge models become pricing models
Standard, graduated, volume, package and percentage charges have matching models here (per unit, tiered, volume, package, percentage). They are built in the price builder rather than from a file, and its preview shows what a customer would pay before you save.
Reuse your transaction ids
Lago deduplicates events on transaction_id. yRecurring's usage API requires an idempotency key on every event: send the same value, and an event that is retried or sent to both systems during the overlap is counted once in each.
1. Export from Lago
Invoices, then filter, then export (basic is one row per invoice, advanced one row per fee), with a link that is valid for seven days; credit notes the same way; customers, subscriptions and plans through the API list endpoints or your own Postgres.
- Invoices, basic or advanced
- Credit notes
- Customers, subscriptions and plans through the API or the database
As documented by Lago on 24 September 2026: their export guide.
2. Saved cards
Nothing to move. Lago holds the provider's customer and payment method ids, not the cards; connect the same Stripe, Adyen or GoCardless account to yRecurring and import the saved payment methods as token references.
Source: Lago documentation, read 24 September 2026. How yRecurring imports them: migrating saved payment methods.
3. What carries over
| In Lago | In yRecurring | Notes |
|---|---|---|
| Customer: external_id, email, address, tax identification number | Customer Lago customers already carry your external_id; it stays the key. | Lago customers already carry your external_id; it stays the key. |
| Plan: code, interval, amount | Product, kind plan, and its base price The plan code is kept as the external id. | The plan code is kept as the external id. |
| Billable metric | Meter Created in the app, one per metric. | Created in the app, one per metric. |
| Charge on a billable metric | Metered price Built in the price builder on the matching model. | Built in the price builder on the matching model. |
| Add-on | Product, kind one-off Lago add-ons are one-off charges, and so are these. | Lago add-ons are one-off charges, and so are these. |
| Subscription: external_id, plan code, status, billing time | Subscription Calendar or anniversary billing time decides the period dates; import them as they are. | Calendar or anniversary billing time decides the period dates; import them as they are. |
| Invoice and its fees | Invoice Historical, one summary line with the total; the fee rows stay in the advanced export. | Historical, one summary line with the total; the fee rows stay in the advanced export. |
| Credit note | Credit note Historical, against its imported invoice. | Historical, against its imported invoice. |
| Wallet | Prepaid wallet Created per customer; carry the remaining credit over on the switch day. | Created per customer; carry the remaining credit over on the switch day. |
| Provider customer and payment method ids | Saved payment method Token references in the same Stripe, Adyen or GoCardless account. | Token references in the same Stripe, Adyen or GoCardless account. |
Records go in dependency order: customers and catalog, then subscriptions, then invoices and the payments that settle them. Each row keeps your old system's id, so running a file again skips what is already there instead of copying it; customers, products and prices can be set to update instead. What you can import.
What stays in Lago, and what to do instead
Events stay in Lago. yRecurring meters count from the first yRecurring period; the period that is closing is billed by Lago.
Recreate them in yRecurring and apply them to the subscriptions that carry one.
Recreate your rates in yRecurring, stacked by region where you need it, or connect Avalara AvaTax from Grow.
Self hosted, keep the database readable until the last Lago invoice has been paid, then retire the workers and the event pipeline.
4. The cutover, in five steps
- 01Export
Export invoices and credit notes from the app, then pull customers, plans, subscriptions and wallets through the API or your database.
- 02Connect
Start the free trial and connect the same payment account you charge through today.
- 03Dry run
Upload the files. The import maps the columns, cleans the values, and shows every row it would create before it writes one.
- 04Parallel cycle
Run one billing cycle in test mode beside Lago and compare the invoices line by line.
- 05Switch
At a period boundary, turn charging on here, send usage to yRecurring alone, and terminate the Lago subscriptions.
Questions about leaving Lago
See how Lago and yRecurring compare → What you pay today, next to a flat plan: the fee calculator →
Can I keep my usage events flowing during the move?
Yes. Send usage to both systems for the overlap cycle; yRecurring counts a repeated event once, so a replay of the backlog is safe.
We self host. Can we read the database instead of the API?
Yes, and it is often quicker: export the customer, plan, subscription and wallet records to CSV with a query. Keep the external ids Lago stored, so the files join on the same keys your app already uses.
Will my customers get emails during the import?
No. Imported invoices, payments and subscriptions are historical records; the importer never sends a customer email for them. The first message a customer gets from yRecurring is the first invoice or receipt you choose to send.