Paddle → Polar
Move products, prices, customers, payment methods, subscriptions, invoices, tax settings, webhooks, entitlements, and financial evidence from Paddle into Polar with an explicit exception ledger and evidence-based cutover.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
Paddle
- Merchant-of-record billing removes much of the global tax and compliance burden
- Checkout, subscriptions, tax, and customer records are consolidated
- Approval, platform rules, payout timing, and checkout control reduce flexibility
- Billing state and compliance responsibilities make switching unusually sensitive
Polar
- Developer-focused products, benefits, subscriptions, and merchant-of-record billing fit software creators
- Checkout, subscriptions, tax, and customer records are consolidated
- Its younger ecosystem and narrower commerce scope may not cover complex businesses
- Billing state and compliance responsibilities make switching unusually sensitive
Polar: Developer-focused products, benefits, subscriptions, and merchant-of-record billing fit software creators. This removes a major source-side concern: Approval, platform rules, payout timing, and checkout control reduce flexibility.
What you lose: Merchant-of-record billing removes much of the global tax and compliance burden. What you inherit: Its younger ecosystem and narrower commerce scope may not cover complex businesses.
Know the shape of the move.
This timeline assumes
- Up to 500,000 customers, 100,000 subscriptions, and five years of billing evidence
- Both providers approve the customer and payment-method transfer path in writing.
- Finance and legal owners approve the merchant, tax, invoice, and customer-notice change.
- The application can process both providers idempotently during a controlled transition.
- The migration team records evidence for every blocking verification check.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Products, prices, customers, subscriptions, invoices, and selected billing state | partial | critical | Core products, prices, customers, subscriptions, invoices, and selected billing state can move, but Paddle and Polar use different models, limits, identifiers, and import behavior. | Pilot every feature class, preserve source IDs, and reconcile accepted, transformed, rejected, and excluded items. |
| Payment-method portability, tax, retries, entitlements, webhooks, and financial history | manual | critical | Paddle-specific runtime configuration and historical evidence do not become native Polar behavior through the core data transfer. | Inventory every active dependency, approve its destination disposition, and test the replacement before source writes stop. |
| Products, prices, and plans | partial | critical | Catalog objects can map while IDs, tax behavior, currencies, intervals, and grandfathered pricing differ. | Create and sign a price map before customer migration. |
| Customers and billing profiles | partial | critical | Core identities can move while addresses, tax IDs, metadata, balances, and duplicates require review. | Preserve source IDs and reconcile one destination customer per approved identity. |
| Payment methods | partial | critical | Card or wallet portability requires a PCI-compliant provider-to-provider transfer and some methods cannot move. | Obtain written scope from both providers and define reauthorization cohorts. |
| Active subscriptions | partial | critical | Status, next billing date, items, quantities, trials, cancellation, and discounts need exact import behavior. | Pilot every lifecycle state and reconcile the first renewal. |
| Invoices, charges, refunds, and disputes | partial | critical | Historical financial objects may remain read-only in the source. | Archive signed ledgers and define which destination records are reference-only. |
| Coupons, credits, and balances | partial | high | Redemption state, customer credits, and proration semantics differ. | Reconcile monetary liabilities before cutover. |
| Tax, merchant-of-record, and invoices | manual | critical | The legal seller, invoice issuer, tax collection, and filing responsibility can change. | Get finance and legal approval for the cutover date and customer notice. |
| Dunning, retries, and failed payments | manual | critical | Recovery schedules and past-due states do not continue automatically. | Let source dunning settle or map every exception explicitly. |
| Checkout, portal, and customer communications | manual | critical | Hosted URLs, authentication, receipts, and lifecycle email templates change. | Test every customer-facing billing path. |
| Webhooks and application state | manual | critical | Event names, ordering, retries, IDs, and signatures differ. | Build idempotent dual-provider handling and reconcile events. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| Paddle product and price | Polar product and price | transform | Preserve source IDs and grandfathered price intent. |
| Customer | Destination customer | transform | Map identity, address, tax, metadata, and balance. |
| Payment method | Destination payment method or reauthorization | manual | Requires provider-approved PCI transfer. |
| Subscription | Destination subscription | transform | Map status, period, items, quantity, trial, and cancellation. |
| Invoice or charge | Destination reference record or archive | transform | Do not make history chargeable. |
| Coupon, credit, or balance | Destination discount or liability | transform | Reconcile monetary exposure. |
| Dunning state | Destination recovery state | manual | Avoid moving ambiguous in-flight retries. |
| Webhook event | Destination event and application transition | transform | Build idempotent handlers. |
| Checkout or portal URL | Destination checkout or portal | manual | Replace every customer-facing link. |
Make the move recoverable.
Create the source-of-truth backup
Preserve Paddle data, configuration, and operating evidence before any destination write.
- Export Paddle products, prices, customers, subscriptions, invoices, charges, refunds, disputes, discounts, events, and reports.
- Inventory payment methods, lifecycle states, retries, webhooks, tax, checkout, portal, and application IDs.
- Record signed counts, MRR, balances, renewal schedules, monetary totals, and exception cohorts.
- Hash exports and secure provider correspondence.
Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.
Catalog and subscriber state map
Preserve pricing, renewal, tax, and application entitlement intent.
- Inventory source values and exceptions.
- Define explicit destination mappings.
- Reject unmapped critical records.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Dual-provider event harness
Prove checkout, webhooks, renewal, recovery, refunds, and reconciliation.
- Normalize encoding, dates, identifiers, and blanks.
- Run a representative pilot.
- Reconcile accepted, rejected, and transformed rows.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
Payment methods do not arrive for every cohort
Unsupported methods or provider mismatches leave subscriptions unable to renew.
- Consequence
- Customers churn or require emergency reauthorization.
- Mitigation
- Obtain transfer scope and segment unsupported methods before cutover.
Stop if: Any cohort lacks a renewal path and communication.
Both providers renew subscriptions
Source cancellation and destination activation are not atomic.
- Consequence
- Customers are charged twice.
- Mitigation
- Use an agreed import date and reconcile every source and destination state.
Stop if: Any test or live customer has two billable subscriptions.
Application entitlements drift from billing
Imported or new event semantics are processed incorrectly.
- Consequence
- Customers gain or lose access improperly.
- Mitigation
- Use idempotent handlers and compare billing state to application state.
Stop if: Any critical entitlement invariant fails.
Do the work in this order.
- Days 1–3 · inventory
Inventory and decisions
6–12 hours active2–3 days elapsedOwner review waiting- Inventory Paddle data, features, users, domains, and integrations.
- Approve scope, owners, mappings, and exclusions.
Depends on: Paddle and Polar administrator access
Stop / go checkpointExport?
Go when: Every critical item has an owner and disposition.
Stop when: Consent, billing, access, or system ownership is unclear.
- Days 3–5 · backup
Backup and reconcile
5–10 hours active1–3 days elapsedExport processing waiting- Create immutable exports and configuration evidence.
- Reconcile counts, totals, and hashes.
Depends on: Approved inventory
Stop / go checkpointTransform?
Go when: Source totals and export manifests agree.
Stop when: Any critical dataset or configuration is absent.
- Days 5–12 · pilot
Map and pilot
10–35 hours active3–8 days elapsedDestination processing and review waiting- Configure Polar and transform representative data.
- Run a pilot containing normal records and every critical edge case.
Depends on: Verified backup
Stop / go checkpointScale?
Go when: Pilot mappings, behavior, access, and evidence pass.
Stop when: Any critical check fails or produces unexplained variance.
- Days 10–20 · cutover
Final delta and switch
5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting- Freeze production writes in Paddle.
- Apply the final delta, switch ownership, and run blocking checks.
Depends on: Passed pilot and approved rollback
Stop / go checkpointOpen production?
Go when: Counts reconcile and one destination system owns production.
Stop when: A source writer remains active or a blocking check fails.
- Days 12–40 · observe
Observe and close
3–18 hours active3–10 days elapsedOperating-cycle evidence waiting- Monitor one complete operating cycle.
- Sign the verification report and close rollback only after stability.
Depends on: Verified cutover
Stop / go checkpointClose rollback?
Go when: No trigger occurs during the agreed observation period.
Stop when: Data, access, delivery, routing, or business results regress.
Cut over with a way back.
Cutover
Make Polar the only production system without losing the final Paddle delta.
- Freeze production writes and scheduled actions in Paddle.
- Export, transform, and reconcile the final delta.
- Apply the approved delta to Polar.
- Switch domains, forms, integrations, sending, or sync ownership as applicable.
- Run every blocking verification check and keep the source intact.
Proof to capture: Polar owns production, totals reconcile, and every blocking check has durable evidence.
Rollback
Return production ownership to Paddle without losing destination-era changes.
- Stop new writes and scheduled actions in Polar.
- Restore the prior Paddle routing, forms, integrations, sending, or sync ownership.
- Export the Polar post-cutover delta.
- Review and apply safe destination-era changes to Paddle.
- Run the same blocking checks against the restored source.
Proof to capture: Paddle again owns production with current data and no duplicate destination action.
- Unexplained critical count or value variance
- Missing or exposed critical data
- Duplicate production action
- Failed access, routing, delivery, or integration check
- A critical feature has no safe destination replacement
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Product and price mapping | Compare currency, interval, tax behavior, and grandfathered cohorts. | Every billable price has one approved destination. | Price map. | |
V-02Blocking | Identity reconciliation | Compare source, transfer, rejected, and destination customers. | Every customer is accounted for without unexplained duplicates. | Customer ledger. | |
V-03Blocking | Payment-method coverage | Reconcile transferred and reauthorization cohorts by method. | Every renewable customer has a valid path. | Method report. | |
V-04Blocking | Lifecycle state parity | Compare status, items, quantity, period, trial, cancellation, discount, and next charge. | Every subscription state matches the signed map. | Subscription ledger. | |
V-05Blocking | Monetary totals and liabilities | Reconcile MRR, credits, balances, refunds, disputes, and renewal schedule. | All signed totals match or have approved explanations. | Finance sign-off. | |
V-06Blocking | Webhook and entitlement behavior | Replay success, renewal, failure, recovery, change, refund, and cancellation. | One idempotent application transition per event. | Webhook evidence. | |
V-07Blocking | Checkout, portal, invoice, and email | Exercise every customer-facing billing path. | Access, amounts, tax, and communication are correct. | Journey matrix. | |
V-08Blocking | Single billing authority | Inspect provider states, schedules, checkouts, and application routing. | Polar alone owns approved new charges and renewals. | Cutover checklist. |
Remove the scaffolding safely.
Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.
- Create final Paddle exports and archive verification evidence.
- Revoke temporary credentials, API keys, webhooks, and elevated roles.
- Remove obsolete embeds, forms, jobs, integrations, and DNS records.
- Keep the source intact through the approved retention window.
- Cancel paid plans only after billing, legal, and recovery review.
- Schedule the next Polar backup, access, and migration-playbook review.
Built to be reviewed.
Tested 2026-07-19. Next scheduled review: 2026-10-19.
- Paddle: official migration documentationAccessed 2026-07-19
- Polar: official migration documentationAccessed 2026-07-19