Migrate from Stripe Billing to Lago

How to migrate from Stripe Billing to Lago without double charging

A team that wants to own its billing logic while keeping Stripe as the payment processor should treat the move as a staged handover of invoice generation, not a payments migration. Stripe keeps card acceptance, tokens and settlement. Lago takes over charge calculation, invoice creation and the decision of when to collect. Lago's FAQ states that businesses using Lago need a separate payment processor: Lago calculates how much to charge and when, then sends that to a gateway, and its README names Stripe as a supported provider. Because Stripe is the same gateway on both sides during the transition, the main risk is two systems both deciding to bill the same customer for the same period. In practice, the work is usually done by an internal platform or finance engineering team, often with an implementation partner for the cutover. Internal staff own the product rules, such as plan prices, proration, tax and credit notes, and they must sign off on how each Stripe Billing object maps to a Lago object. A partner typically helps with the Stripe API export, the replay of historical data and the parallel run. Ask any partner for a written scope that names the Stripe objects in scope, the Lago version you will pin, and the reconciliation report that proves the cutover is clean. Effort depends mostly on how many plans, metered products and custom invoice rules you run, and no fixed figure applies to every team. The safe approach is to pick one cutover date per customer cohort and disable Stripe Billing's subscription invoicing for that cohort before Lago starts issuing invoices for it. Confirm in Stripe which subscriptions will be paused, which will be cancelled without prorated refunds, and which keep their customer IDs for linking. Run Lago in parallel on a copy of recent invoices and compare totals, taxes and due dates before any customer receives a Lago invoice. Plan for a rollback path, since reversing a cutover after charges have been collected is far harder than pausing one.

Which Stripe Billing capabilities map to Lago and which need rework

This table maps the main Stripe Billing capabilities to their closest Lago equivalent and labels each row clean, needs rework or gap. Use it as a checklist for a pilot: any row marked rework or gap needs a test against your own plans, invoices and customers before you switch invoice generation.

Stripe Billing capability	Lago equivalent	Status and what to confirm
Subscriptions, plans and prices	Plans, billable metrics and subscriptions in Lago, with charges attached to plans	Needs rework. Recreate each Stripe price as a Lago plan and confirm how intervals, trials and mid-cycle plan changes behave for your cases.
Metered usage	Billable metrics fed by events sent to Lago's API, aggregated per billing period	Needs rework. Map each Stripe meter to a billable metric and confirm aggregation type, event identifiers and late event handling in a test account.
Coupons and discounts	Coupons and applied coupons in Lago, applied to customers or subscriptions	Needs rework. Recreate active discounts and confirm how percentage, fixed amount and duration limits are applied to existing subscriptions.
Proration on plan changes	Proration behavior configured per plan change in Lago	Needs rework. Compare prorated amounts for upgrades, downgrades and mid-period cancellations against Stripe for the same dates before cutover.
Invoice generation and PDFs	Invoices generated by Lago, with PDF rendering through Gotenberg in the Docker Compose stack	Needs rework. Check invoice numbering, layout, legal entity details and tax lines against your current invoices, and confirm who is the invoice issuer of record.
Dunning and payment retries	Payment collection through Lago's supported gateways, including Stripe, with retry behavior to confirm	Gap to confirm. Lago calculates what to charge and when, then sends it to the gateway. Confirm retry schedules, failure notices and final-attempt handling in your environment.
Tax calculation	Tax rates and tax assignment on plans and invoices in Lago	Gap to confirm. Stripe Tax is a separate product, so confirm whether your tax engine or Stripe Tax stays in the flow and how tax is passed to Lago invoices.
Webhooks and event notifications	Lago webhooks for invoice, subscription and payment events	Needs rework. Rebuild downstream consumers for Lago event names and payloads, and run both webhook streams in parallel during testing.
Customer records and Stripe customer IDs	Lago customers linked to existing Stripe customers through the external customer identifier	Needs rework. Link each Stripe customer to its Lago record before any new invoice runs, to avoid duplicate customers and double charges.

What data and integrations move out of Stripe

Stripe Billing holds subscriptions, invoices and customer records that Lago needs to take over, but card data stays with Stripe. The cards below separate what moves through the API, what links the two systems during cutover, and what the accounting and CRM rebuild requires.

Subscriptions and invoices via the API

Subscriptions, their items, billing periods and invoice history can be read from the Stripe API and used to build a reconciliation dataset. Lago does not import these objects automatically, so you decide which active subscriptions are recreated in Lago and which historical invoices remain only as Stripe records. Check the ownership of proration, trial end dates and tax lines before you map them. Confirm the exact fields you need against your own Stripe API version.

Customer records and Stripe customer IDs

Customer name, billing address, tax identifiers and the Stripe customer ID are the keys that tie each Stripe customer to its Lago customer. Store the Stripe ID as the external reference in Lago so webhooks and payment events can be matched during the transition. Duplicate customers across both systems are a common source of double invoices, so run a match report before any subscription is switched. Confirm how Lago handles external IDs in the API version you deploy.

Payment method references stay with the processor

Card numbers and full card data do not move through the Stripe API export that Lago uses, and Lago does not store card details. Stripe keeps the saved payment methods and the customer's default method, and Lago asks the payment gateway to charge them. Plan to keep Stripe as the processor and map each Lago customer to the Stripe payment method ID. Moving cards to another processor is a separate process that requires a PCI DSS Level 1 destination and is not part of this migration.

Accounting connectors to rebuild

The Lago README lists integrations with NetSuite and Xero for accounting. Invoice, customer and tax data flows into the ledger, so mismatched account codes or tax rules will show up as close errors. Rebuild each connector against your chart of accounts, then run a month of parallel postings before retiring the Stripe-to-ledger path. Confirm each connector's supported features and version against your ERP or accounting edition.

CRM connectors to rebuild

The Lago README also lists Salesforce and HubSpot connectors. These carry account status, subscription plan and invoice state into sales and customer success tools that teams use during renewals. Decide which fields are the source of truth for each record before cutover, since two systems writing the same field will drift. Confirm which objects each connector syncs and whether it covers your current custom fields.

Webhooks and event consumers

Downstream systems that react to Stripe invoice and subscription webhooks, such as entitlement services or dunning tools, must be pointed at Lago events or rebuilt. A missed webhook after cutover can leave a customer without access or an invoice unpaid. List every consumer, map its trigger to the Lago equivalent, and test each one against a non-production Lago instance before you disable the Stripe endpoints.

Migration sequence: inventory, pilot, parallel run, cutover and decommission

This sequence moves Stripe Billing subscription and usage logic into Lago one controlled step at a time, while Stripe keeps processing payments and no customer is charged twice.

Inventory plans, meters and open billing state
Your billing or finance engineers export the list of Stripe products, prices, recurring intervals, metered prices, coupons and tax settings, then record every active subscription, its billing anchor date and any scheduled changes. They also list open invoices, unpaid invoices in dunning, credit balances and pending usage records. Each item is mapped to a Lago plan, billable metric or customer, and the inventory is signed off by finance. The output is a written mapping document with one row per plan, meter and subscription, plus a list of edge cases such as mid-cycle upgrades, trials and prorations that need a decision before any build work starts.
Recreate plans and meters in a Lago sandbox
Engineers build the mapped plans, charges and billable metrics in a non-production Lago instance deployed from a pinned release, as the self-hosting documentation recommends. They import a copy of the customer and subscription data through the Stripe API, then compare the generated subscription amounts with the amounts Stripe shows for the same period. Discrepancies are traced to rounding, tax, proration or metric aggregation differences and fixed in the mapping. The step is done when a sample of subscriptions produces identical totals in both systems for a full simulated billing cycle.
Pilot with a small cohort of customers
Operations selects a small group of customers with simple plans and no open disputes, links their existing Stripe customer IDs to Lago customers, and moves only their subscriptions to Lago invoicing. Stripe remains the payment gateway for these customers, so Lago calculates the amount and sends the charge to Stripe. Support teams review the first invoices, customer portal access and receipts with the pilot group. The output is a pilot report that lists every invoice generated, every payment attempt and every correction, along with a go or no-go decision for the next cohort.
Run both systems in parallel and reconcile
For a defined period, Stripe Billing and Lago both compute charges for the same subscriptions and usage, but only one system is allowed to collect money at any time. The Stripe-side invoice generation for each customer is turned off before the matching Lago collection is turned on, so only one invoice is ever sent for a billing period. Finance reconciles the computed amounts, usage totals, tax and credit balances each cycle against the bank and processor records. The step closes when two consecutive reconciliation cycles show no unexplained differences and every variance has a documented cause.
Cut over on a fixed date
The team sets a cutover date in writing and, before that date, disables Stripe Billing subscription creation and automatic invoice finalization for the migrated population. From the cutover date, Lago generates all invoices and sends payment requests to Stripe, and new sign-ups are created only in Lago. Engineers confirm that no Stripe subscription is still active for a migrated customer, that usage ingestion points to Lago only, and that the payment method and mandate tokens still work. The output is a cutover checklist with timestamps, signed by billing and finance owners, and a rollback plan that names the exact configuration switches to reverse.
Decommission webhooks, schedules and old reports
Once Lago has produced stable invoices for at least one full cycle after cutover, the team removes the Stripe webhook endpoints that fed the old billing logic, cancels Stripe subscription schedules and billing automations, and archives the Stripe invoice and subscription history for audit. Internal dashboards, accounting exports and CRM sync jobs are repointed to Lago. Access keys tied to the retired workflows are rotated and revoked. The step is complete when a written decommission record lists each webhook, schedule and integration removed, and confirms that Stripe is used only as the payment processor.

How Lago runs alongside Stripe during the transition

Lago calculates what to charge and when, then hands the money movement to a payment gateway. In a self-hosted deployment, Lago's Docker Compose setup runs a front end, an API, an API worker, a clock worker, PostgreSQL for application data, Redis as the job queue and Gotenberg for PDF invoice generation. ClickHouse is an optional external store for high-volume events and is disabled by default, so most teams starting this migration will not run it on day one. Your team should decide early whether the clock worker and API worker run on the same hosts as the API or on dedicated workers, since Lago's self-hosting docs point larger deployments toward Helm charts and dedicated workers. Pin the last tagged release in your configuration rather than the latest image tag, and record the version you tested so upgrades go through the same change control as the rest of your billing stack.

During the parallel run, Stripe stays as the gateway that charges cards and holds the payment methods, while Lago becomes the system that decides which invoice is issued. Create the Lago plans, metrics and billing entities against a copy of your Stripe data, compare the invoices Lago generates for a closed period with what Stripe produced, and only then move a customer cohort across. The critical control is on the Stripe side: for every customer you move, stop Stripe from generating subscription invoices for the periods Lago now owns, by cancelling or pausing the Stripe subscription at a defined period boundary, and confirm that no invoice finalization job in Stripe still targets that customer. Two invoices for one period usually come from a Stripe subscription that was never closed, so make that check part of the cutover runbook and keep a list of every subscription ID that has been retired.

What drives the cost and duration of this migration

This table lists the factors that raise or lower the cost and length of moving billing from Stripe Billing to Lago while Stripe keeps processing payments. Read each row as a question to answer in your own environment before requesting a written quote, because the largest drivers are usually data volume, custom integrations and the length of the parallel run.

Driver	Why it changes cost or effort	How to keep it down
Number of plans, meters and prices	Each Stripe product, price and usage meter must be recreated in Lago with matching charge logic, so catalog complexity scales the mapping and test work.	Retire unused prices before migrating and consolidate near-identical plans into shared definitions.
Active subscriptions and customers	Every live subscription needs a linked Stripe customer, a billing anchor date and a verified next invoice, so migration effort grows with the subscriber count.	Migrate by cohort, for example by billing cycle, and reconcile counts and balances per batch.
Usage event volume	High event volumes raise the load on the metering pipeline and may lead you to evaluate optional ClickHouse storage, which Lago disables by default.	Confirm the expected event rate with your architect early and size the pipeline from measured traffic, not estimates.
Custom integrations	Webhooks, ERP sync, revenue reporting and CRM connections built against Stripe Billing objects must be rewritten or re-pointed to Lago's API and integrations.	Inventory every consumer of Stripe Billing webhooks and invoices, then remove or merge duplicate integrations first.
Invoice and tax complexity	Tax rules, credit notes, proration, multi-currency and PDF templates each need to be reproduced and checked against historical invoices.	Document current tax settings and sample real invoices for each scenario, then agree which rules Lago must match exactly.
Parallel run length	Running Stripe Billing and Lago side by side to compare invoices adds operating time and reconciliation work until the cutover is signed off.	Define exit criteria for the parallel run in writing, including invoice match rules and a single owner for sign-off.
Infrastructure sizing	Lago needs PostgreSQL, Redis, workers and Gotenberg for PDFs, and production sizing depends on availability targets, backups and environments.	Start from the Docker Compose layout for non-production and move to Helm charts and dedicated workers only where load requires it.
Enterprise edition need	Lago's FAQ says the open-source edition covers fundamental billing features while Enterprise plans add premium features, so the required feature set determines the license cost.	List required features against the open-source edition first, then ask Lago which premium features your scope depends on.

How the migration changes by company size and starting point

A team with a handful of flat-price plans and few or no meters usually has the smallest migration. The main work is recreating plans, prices and trial rules in Lago, linking existing Stripe customers and confirming that renewals fall on the same dates after cutover. Because the catalog is small, the team can often run a short reconciliation of a sample of active subscriptions before moving everything.

Catalog scope: Recreate each plan and add-on once, then compare amounts, currencies and billing intervals against the Stripe price objects.
Customer linking: Map each active Stripe customer to a Lago customer by a stable external ID so invoices and payment methods stay attached.
Renewal timing: Choose a cutover that does not fall on a billing run for a large share of accounts, and confirm the next invoice date for each subscription.
Parallel checks: Compare one billing cycle in both systems in a test environment before Lago issues live invoices.
Operating load: A small deployment still needs the Lago API, workers, PostgreSQL, Redis and PDF generation running with backups and upgrades.

Before picking a date, confirm with finance which invoice numbering and tax settings must carry over and whether a single cycle of duplicate reporting is acceptable.

What usually goes wrong and how to prevent it

Most failed billing migrations fail at the seams: two systems issuing invoices at once, events lost during the switch, and data that looks current but is not. The cards below cover the failure points that matter most when Stripe stays as the payment processor and Lago takes over invoice generation.

Double charges from overlapping invoices

If Stripe Billing and Lago both generate invoices for the same customer during the overlap window, the customer can be charged twice for one period. Choose a single cutover date per subscription, disable automatic invoice finalization in Stripe for migrated subscriptions before Lago's first billing run, and confirm which system owns each open invoice. Reconcile every charge against a single invoice ID before going live.

Proration and meter rounding mismatches

Lago and Stripe may round usage quantities and prorate partial periods differently, so the first Lago invoice can disagree with what the customer saw in Stripe. Run both systems side by side on a sample of historic usage and compare totals line by line. Document the rounding rule and the proration method for each plan before cutover, and agree on how any difference is credited.

Lost webhook events during cutover

Stripe webhooks for invoice, subscription and payment events may fail or arrive out of order while endpoints change. A missed event can leave Lago and Stripe with different subscription states. Pause or replay webhook deliveries deliberately, keep the Stripe event log as the reference, and check that each event type is handled by Lago before the old endpoint is removed.

Customers without a linked payment method

Lago sends charge requests to a payment gateway, so any customer without a stored, valid payment method in Stripe will fail collection on the first Lago invoice. Before cutover, export a list of active subscriptions that lack a default payment method or have a card set to expire, and contact those customers. Decide in advance whether failed collections move to dunning, pause or cancellation.

Stale ClickHouse or event data

If ClickHouse is enabled for high-volume events, a lagging pipeline or a backfill that stopped partway can make usage totals wrong without any visible error. ClickHouse is disabled by default, so confirm whether your deployment uses it. Compare event counts per customer per day between the source system and Lago for the last full billing period, and alert on gaps before the first run.

Unpinned container upgrades

Pulling the latest image tag can change billing behavior between a test run and a production run. Lago recommends pinning the last tagged release rather than the latest image, so pin the exact version you validated and record it in your change record. Upgrade only in a staging environment that replays a full billing cycle, and treat each release note as a potential change to invoice output.

Questions teams ask before moving billing from Stripe to Lago

How much effort and cost does a move from Stripe Billing to Lago involve?

The effort depends mainly on how many plans, metrics, add-ons and custom invoice rules you run, how many active subscriptions must carry over, and how clean your Stripe data is. Costs fall into three groups: the one-time work of mapping and migrating billing logic, the infrastructure and operations you run for Lago, and the ongoing engineering time for upgrades and incident response. Lago's open-source edition is free to use under AGPLv3, but Enterprise features and any services partner are separate costs. Ask any provider for a fixed-scope quote that lists each deliverable, the Stripe objects in scope, and the environments included.

How long does it take to move subscriptions and usage billing to Lago?

The timeline depends on scope, so no fixed duration applies to every team. The main drivers are the number of plans and meters to recreate, whether usage history must be backfilled, how many customers need their Stripe links verified, and how long you need to run both systems in parallel before cutover. Teams with a small catalog and a short parallel run move faster than teams with complex metered pricing and multiple currencies. Ask for a written timeline tied to named milestones, including a parallel-run period and a cutover checkpoint.

What does our team need to provide before the work starts?

Expect to provide access to a Stripe account with the right API permissions, a complete list of active plans, prices, coupons and metered products, and a sample of recent invoices so the output can be compared. You will also need a target cloud or data center environment for Lago, with PostgreSQL, Redis and the optional storage choices decided in advance, plus named owners for finance, billing operations and on-call support. Your accounting or ERP integration contacts should be available for invoice and ledger testing.

Can our own engineers do this migration in-house?

Yes, a capable in-house team can do the migration, provided it has engineers who understand the Stripe API, Lago's data model, and your revenue recognition rules. The work is less about writing an import script and more about reconciling edge cases such as prorations, trials, tax, credits and failed payments. Teams often underestimate the parallel-run period and the operational load of owning Lago after cutover. Decide early whether your team will own the migration end to end or will use an outside partner for part of it, and document that decision in the project plan.

Does card data move from Stripe to Lago during the migration?

No, card data does not move through the Stripe API path used for subscriptions and invoices. Lago calculates what to charge and when, then sends the charge to a payment gateway, so the card details stay with Stripe as the processor. Customers keep their saved payment methods in Stripe, and Lago references the existing Stripe customers. If you later want to move stored cards to a different processor, that is a separate export project governed by the PCI DSS requirements of the receiving provider, so confirm that path with the processor before you plan it.

Does Stripe stay as the payment processor after the move?

Yes, in the setup this page describes, Stripe remains the payment processor while Lago takes over subscription logic, metering, pricing and invoice generation. Lago's documentation states that businesses need a separate payment processor, and it names Stripe, Adyen and GoCardless among supported providers. This means you stop paying Stripe Billing's fee on billing volume but continue paying Stripe's processing fees. Confirm the exact fee structure and any Stripe contract terms that apply to your account with Stripe before cutover.

How do we avoid double charges during the switch?

Double charges are avoided by assigning a single owner to invoice generation for each customer at any moment, and by turning off Stripe's automatic invoicing for those subscriptions before Lago begins issuing them. The checklist should cover billing anchor dates, the first Lago invoice period, and a reconciliation of open invoices and pending payments. Run both systems against a test set of customers, compare generated charges line by line, and keep a rollback plan. Ask any provider to show how cutover is sequenced and verified in your environment.

Where to confirm Lago behavior before you commit

Before you commit to a migration plan, confirm how Lago behaves against the exact version you intend to run. Start with the getlago/lago repository on GitHub, where the README describes the platform's scope, its AGPLv3 license for the core platform, and the separate MIT licensed agent SDKs and MCP server. Your legal team should read the license against how you plan to use and modify the code, and the repository is also where you find the integrations Lago lists, including the payment gateways it names. Treat the README as orientation, not as a guarantee of what a given build does with your subscriptions and invoices.

The Lago General FAQ is the right place to confirm commercial questions that affect your design, such as the difference between the forever-free open-source edition and the Enterprise plans, and the fact that Lago calculates charges and sends them to a separate payment gateway. Ask your Lago contact or check the docs to confirm which premium features you need, because a missing feature found during cutover is far more expensive than one found during a proof of concept. The Docker self-hosting guide shows the services you will operate, including the API, workers, PostgreSQL, Redis and Gotenberg, and it recommends pinning the last tagged version rather than the latest image tag. Use it to size the pieces your team must monitor and back up.

Finally, use the releases page to choose your pinned tag and read its notes before you deploy. Release notes can change how plans, meters, invoice generation or webhooks behave, so verify each behavior you depend on in a staging environment built from that same tag. Repeat the check when you upgrade. Record the tag, the date you tested it and the test cases you ran, because that record becomes part of your change evidence for the cutover.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, customizes, integrates, hardens, backs up, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Stripe Billing to Lago, the work is agreed in a written, fixed scope before it starts, with Stripe kept as the payment processor.

How we scope

Written scope lists which Stripe subscriptions, invoices and customers move into Lago and which stay in Stripe.
Scope defines the Lago deployment target, the PostgreSQL and Redis footprint, and where PDF generation runs.
Scope sets the cutover order, rollback conditions and the sign-off criteria for invoice generation.

How we build

Recreate plans, metered charges and billable metrics in Lago, then test them against sample Stripe subscriptions.
Link existing Stripe customers to Lago customers and verify identifiers match before any invoice is generated.
Run parallel invoice comparisons and confirm Stripe charges are created only once during the switchover window.

How we hand over

Documentation covers the pinned Lago version, configuration, upgrade steps and the reconciliation runbook.
Handover includes the migration test results and a record of every mapped plan, meter and customer.
Operators are trained on invoice review, webhook monitoring and how to roll back a faulty cutover.

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Retainers can cover tracking Lago tagged releases and testing each upgrade before it reaches production.
Ask your DeployOpen contact to confirm response terms and retainer scope in the written quote.