Since Lemon Squeezy said its future is being built through Stripe Managed Payments, a lot of founders have started planning a move - to Stripe, to Stripe Managed Payments, or to another merchant of record such as Paddle, Polar.sh or Creem.io. Moving the subscriptions is the part everyone plans for. Keeping your revenue history intact is the part that usually gets missed.
Your MRR trend, churn history and customer records live inside the platform that billed them. Switch without a plan, and you end up with "MRR before" in Lemon Squeezy and "MRR after" somewhere else, with a cliff in the middle that never really happened. This guide shows how to avoid that.
Before You Start: Decide Where You're Going
Each destination changes what you need to plan for:
- Stripe Managed Payments - Lemon Squeezy has said the goal is an easy path for its users. If you're waiting for that, keep an eye on Lemon Squeezy's announcements before building your own migration.
- Stripe Billing + Stripe Tax - lowest fees, but you become the seller and take on tax registration and filing. See Lemon Squeezy vs Stripe.
- Paddle, Polar.sh or Creem.io - other merchants of record, so tax stays handled for you. See Lemon Squeezy alternatives and Polar vs Stripe.
Also list the Lemon Squeezy features you rely on that the new platform may not have - license keys, file delivery, the storefront, or the affiliate program - and decide what replaces each one.
Why Lemon Squeezy Migrations Break MRR Reporting
Two systems, two half-histories. Lemon Squeezy holds everything up to the switch. The new provider starts at zero. Neither dashboard shows the business as a whole.
Moved customers look like churn, then like new revenue. When a subscriber's Lemon Squeezy subscription ends and a new one starts elsewhere, Lemon Squeezy reports a churned customer and the new provider reports a new one. Looked at separately, churn spikes and so does new MRR, and neither number means what it says.
Customers usually re-enter payment details. Moving between merchants of record often means customers check out again on the new platform. Some won't. That real migration churn is exactly what you need to measure, and it's invisible if the two sides aren't in one view.
Different definitions on each side. Lemon Squeezy records a first payment as both an order and an invoice, mixes one-time sales with subscriptions, and has fee surcharges. The new provider has its own quirks. Exports from each, added in a spreadsheet, won't line up.
The API key clock. Lemon Squeezy API keys expire after a year. If anything you use to read your Lemon Squeezy history depends on a key, note when it expires so your history doesn't stop syncing halfway through the move.
The Plan
1. Connect Lemon Squeezy and the new provider to one dashboard - before you move anyone
Connect your analytics to Lemon Squeezy now, while all your customers are still on it, so your history is in place. Then connect the new provider as soon as the account exists. From that point, one dashboard shows the whole business, old platform and new.
2. Write down your baseline
Before the first customer moves, record your MRR, active subscribers, churn rate and ARPU for the last full month. That baseline is what you'll compare against when you ask "did the migration cost us anything?"
3. Send new customers to the new provider first
Point new checkouts at the new platform and leave existing subscribers on Lemon Squeezy for now. New revenue lands on the new provider, and you can check that its numbers look right with low stakes.
4. Move existing subscribers in batches
Invite subscribers to move at their next renewal, plan by plan or in small groups. Batches let you see how many actually move and fix problems before they hit everyone. Give customers a reason to move - a clear email, the same price, ideally the same renewal date - since anyone who has to check out again might not.
5. Watch MRR by source, not just in total
During the move, the useful number isn't total MRR, it's MRR split by provider. Lemon Squeezy MRR should fall and the new provider's should rise by about the same amount. If Lemon Squeezy drops faster than the new provider grows, that gap is your migration churn.
6. Reconcile before you report
Before you share combined numbers with a cofounder, investor or board, check them against each platform's own dashboard for the same month. This catches currency differences, timing issues and anyone counted twice.
7. Keep Lemon Squeezy connected afterwards
Even once every subscriber has moved, Lemon Squeezy is where your pre-migration history comes from. Leave it connected, and keep its API key current, so the old months stay in the same MRR line as the new ones.
What the Dashboard Should Look Like at Each Stage
| Stage | What's happening | What you should see |
|---|---|---|
| Before | Everyone on Lemon Squeezy | Full history, one source |
| New customers moved | New checkouts on the new provider | New MRR on the new provider, existing MRR on Lemon Squeezy, one combined total |
| Subscribers moving | Batches moving at renewal | Lemon Squeezy MRR falling, new provider rising, any gap is migration churn |
| After | Everyone on the new provider | One continuous MRR line across both, no cliff at the cutover |
How Chartsy Handles a Lemon Squeezy Migration
Chartsy is the revenue and growth dashboard built for SaaS founders. It connects Lemon Squeezy, Stripe, Paddle, Polar.sh, Creem.io and Freemius, so whichever way you're moving, both sides sit in one view.
- Lemon Squeezy connects with one API key, every store on the account, each as its own source. First payments are counted once, one-time sales stay out of MRR, and net revenue includes Lemon Squeezy's fee and surcharges.
- The new provider connects in a couple of minutes, and its history syncs automatically.
- All Accounts adds them up into one MRR line, converted to one currency, while you can still filter to a single source to see how the move is going.
- The MRR breakdown shows new, expansion, contraction, churned and reactivated MRR, so you can tell real churn from customers who simply moved.
- A custom dashboard for the migration can put combined MRR, MRR per provider and churn per provider on one screen until the move is done.
If you also track your website with Chartsy, attribution keeps working across the switch: set your site's revenue account to the new provider when new checkouts move, and you'll still see which channels bring paying customers.
Connect Lemon Squeezy before you migrate →
Frequently Asked Questions
Will moving off Lemon Squeezy break my MRR history? Not if you connect Lemon Squeezy and the new provider to one analytics tool before you start. Without that, your history ends up split across two dashboards with a false cliff at the cutover.
Can I move Lemon Squeezy subscribers to Stripe automatically? Lemon Squeezy has said it wants to give users an easy path to Stripe Managed Payments, but hasn't published migration steps or a deadline. Until it does, plan for customers to check out again on the new platform.
How do I measure how many customers I lost in the migration? Compare Lemon Squeezy's falling MRR with the new provider's rising MRR during the move. If Lemon Squeezy drops faster than the new provider grows, the difference is migration churn.
Should I keep Lemon Squeezy connected after the migration? Yes. It's where your pre-migration MRR, churn and customer history comes from. Keep it connected and its API key current so those months stay in your MRR line.
Does this work if I'm moving to Paddle, Polar.sh or Creem.io instead of Stripe? Yes. The steps are the same for any destination. Chartsy connects all of them, so you can keep the old and new provider in one view.
Related reading: Lemon Squeezy vs Stripe in 2026 · Best Lemon Squeezy Analytics Tools in 2026 · How to Switch Payment Processors Without Losing Revenue History · How to Combine Revenue From Multiple Payment Providers

Written by
Chartsy TeamAnalytics team at Chartsy
The Chartsy Team writes guides, product updates, and resources to help SaaS and eCommerce founders make sense of their metrics, without SQL or spreadsheets.
Chartsy
