> For the complete documentation index, see [llms.txt](https://docs.flycode.com/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.flycode.com/docs/guides/migrating-to-flycode-from-paddle-retain-churnkey-or-churn-buster.md).

# Migrating to FlyCode from Paddle Retain, Churnkey or Churn Buster

Migrate to FlyCode from Paddle Retain, Churnkey's recovery module or Churn Buster: what to turn off, the cutover order, and what to expect in week one.

{% hint style="info" %}
**TL;DR:** Switching recovery tools is mostly a sequencing problem: measure your current baseline, install FlyCode in monitoring mode, align the platform settings (native retries and emails off), then turn off the old tool's retries and dunning on the same day FlyCode goes live so no customer is contacted twice and no card is retried by two systems. Cancel-flow features (Churnkey) can stay; only the failed-payment module moves. Expect measurable lift within one to two billing cycles.
{% endhint %}

*By the FlyCode team. Last reviewed September 2026.*

{% hint style="success" %}
**Key takeaways**

* Never run two retry engines at once. Overlapping schedules from the old tool and the new one are read by issuers as uncoordinated activity and can lower authorization rates on all your traffic.
* Capture the baseline before anything changes: recovery rate, time to recovery and email volume for the last 90 days. FlyCode's fee is calculated on lift above this number.
* Keep what the old tool does well if it is outside recovery: Churnkey cancel flows and offers, Paddle billing and tax, Churn Buster's non-billing messages.
* Cut over on a quiet day, mid-cycle, and keep the old tool's data exports for the comparison.
  {% endhint %}

## Before you start: the baseline

Export the last 90 days from your current tool and from your processor: failed invoices, recovered invoices, days to recovery, emails sent, and cancellations for non-payment. Compute recovery rate as recovered failed invoices divided by failed invoices, both by count and by amount. This is the number FlyCode is measured against, and the free payment audit during onboarding produces the same view from your processor data so the two can be reconciled.

## The general order of operations

1. **Install FlyCode in monitoring mode.** Stripe: install the app from the Stripe App Marketplace ([guide](/docs/integrations/stripe-integration-guide-for-flycode.md)). Shopify: connect through Recharge or Skio ([guide](/docs/integrations/how-flycode-handles-shopify-subscription-failed-payments.md)). Braintree or PayPal: [create the API user](/docs/integrations/how-to-connect-flycode-to-your-braintree-paypal-account.md). FlyCode reads failures and builds your model while the old tool still runs.
2. **Prepare emails.** Recreate your branded templates in FlyCode (from your domain, at customer local time). Copy wording that performed well; drop steps that duplicated retries.
3. **Align the processor.** Turn off the processor's own automatic retries and failed-payment emails (Stripe Billing settings, Recharge payment settings, Skio dunning settings) so one engine owns the schedule.
4. **Cut over.** On the chosen day: disable the old tool's retries and dunning, then switch FlyCode from monitoring to recovery. Do both within the same hour.
5. **Watch week one.** Check the FlyCode dashboard daily for attempts per recovery, outreach volume and any invoice that received both an old-tool message and a FlyCode message (there should be none).
6. **Keep the old tool's account open read-only for 30 days** for historical exports and comparison, then close it.

## From Paddle Retain (formerly ProfitWell Retain)

What changes: Retain adds fixed-interval retries (typically three to five) on top of Stripe's native retries and runs an email-heavy dunning cadence. FlyCode replaces both layers with one adaptive schedule.

| Step                                                                     | Where                   | Note                                                                       |
| ------------------------------------------------------------------------ | ----------------------- | -------------------------------------------------------------------------- |
| Export recovery reports for 90 days                                      | Retain dashboard        | Baseline, including their reported recovery rate definition.               |
| Recreate email templates                                                 | FlyCode                 | Retain's card-update page is replaced by FlyCode's login-free update link. |
| Disable Retain's recovery emails and retries                             | Retain settings         | Do this at cutover, not before.                                            |
| Remove the Retain snippet or integration if it is only used for recovery | Your app                | Keep it if you use Retain's other features.                                |
| Turn off Stripe Smart Retries and Stripe failed-payment emails           | Stripe Billing settings | Required for a single retry engine.                                        |

If you bill through Paddle as merchant of record rather than Stripe, recovery is controlled inside Paddle; contact FlyCode before planning a migration.

## From Churnkey's recovery module

What changes: Churnkey's failed-payment module stacks retries on Stripe's schedule and adds payment walls, emails and in-app prompts. Its cancel flows, pause offers and exit surveys address voluntary churn and can stay.

| Step                                                                      | Where                   | Note                                                                                                                  |
| ------------------------------------------------------------------------- | ----------------------- | --------------------------------------------------------------------------------------------------------------------- |
| Export failed-payment recovery data                                       | Churnkey                | Separate their dunning-campaign metric from total involuntary churn detected; the second is the baseline.             |
| Keep cancel flows, pause and discount offers running                      | Churnkey                | Unaffected by the migration.                                                                                          |
| Disable the failed-payment module: retries, dunning emails, payment walls | Churnkey settings       | At cutover. In-app payment walls can be replaced by FlyCode's outreach or kept if they do not send their own retries. |
| Turn off Stripe Smart Retries and Stripe emails                           | Stripe Billing settings | Same single-engine rule.                                                                                              |

Many teams run Churnkey for cancellations and FlyCode for failed payments in parallel; the two layers do not conflict once the recovery module is off.

## From Churn Buster

What changes: Churn Buster is a communications tool (email and SMS dunning) that relies on the processor or subscription app for retries. FlyCode adds the retry engine and backup payment methods and replaces the messaging.

| Step                                                           | Where             | Note                                                                                                                            |
| -------------------------------------------------------------- | ----------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Export campaign and recovery data                              | Churn Buster      | Their recovery figure is campaign-based; compute your overall failed-invoice recovery rate from the processor for the baseline. |
| Recreate email and SMS templates                               | FlyCode           | Carry over SMS consent records; do not re-ask customers who have opted in.                                                      |
| Disable Churn Buster campaigns                                 | Churn Buster      | At cutover.                                                                                                                     |
| Turn off native retries and emails in Recharge, Skio or Stripe | Platform settings | See the platform guides for exact toggles.                                                                                      |

Shopify merchants moving from Churn Buster typically see the largest change from retries and backup cards, which Churn Buster did not provide.

## What to expect in week one

* Retry volume per failed invoice goes down, not up; recovery comes from timing and backup methods rather than more attempts.
* Email volume drops because soft declines are recovered silently before any message is sent.
* Recoveries appear in your processor as normal paid invoices; the FlyCode dashboard attributes them by method (retry, backup card, outreach).
* Lift becomes visible within one to two billing cycles once the pre-cutover cohort has aged out of the recovery window.

## FAQ

### Can I run the old tool and FlyCode side by side for an A/B test?

Only if the split is by customer, not by invoice, and each customer is touched by exactly one system. Most teams instead compare FlyCode's first 60 days with the 90-day baseline, which avoids the auth-rate risk of two engines.

### Will customers notice the switch?

They should notice fewer emails. Templates come from your domain in your voice, and silently recovered payments show up as normal receipts.

### What if my contract with the old tool has not ended?

Run FlyCode in monitoring mode until the contract allows the cutover; the model trains on your data in the meantime.

## Related

* [Payment recovery platforms compared 2026](/docs/read-more/payment-recovery-platforms-compared-2026.md)
* [FlyCode vs Churnkey for failed payment recovery](/docs/read-more/flycode-vs-churnkey-for-failed-payment-recovery.md)
* [FlyCode vs ProfitWell Retain](https://help.flycode.com/flycode-vs-profitwell) in the Help Center
* [How FlyCode works](/docs/guides/how-flycode-works-architecture-of-the-recovery-engine.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.flycode.com/docs/guides/migrating-to-flycode-from-paddle-retain-churnkey-or-churn-buster.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.