Migrating from Patreon

Moving from Patreon to Benecaster happens in two distinct stages. The first stage — uploading your Patreon patron list — is free and available to all Benecaster accounts, and you can do it before making any migration decision. The second stage — actively moving your subscribers — is what the Migration Wizard handles.

Stage 1: Start Your Scorecard

Upload your Patreon patron export to see your full supporter picture in one place: your Patreon patrons alongside your Benecaster subscribers in a single dashboard view.

Nothing migrates at this stage. Your patrons remain on Patreon. No accounts are created, no emails are sent, no feed access is granted. You’re building a scorecard — a clear picture of who’s on each platform before you decide what to do next.

To upload your patron list:

1. Log in to Patreon and go to Patron Manager → Export
2. Export your patron list as a CSV
3. In your WordPress admin, go to Benecaster → Shows → [Your Show] → Visibility and find the Patreon panel
4. Upload the CSV

Your Patreon patrons appear in the subscriber dashboard labelled Patreon (unlinked). The total count shows your combined Benecaster and Patreon supporter base.

Patreon Data Retention

Benecaster stores your Patreon patron data for 90 days from the date of upload.

• Days 60–89 (amber warning): An amber banner appears below the patron count in the Patreon section: “Your Patreon scorecard data expires in X days — upload a current Patreon export before it expires.”
• Day 90+ (red expired banner): The amber warning is replaced by a red banner: “Your Patreon scorecard has expired — re-upload your current Patreon export to refresh it.”

What happens when data expires: Patron records that haven’t been converted to active Benecaster subscribers are removed from the system. Your Benecaster subscribers are unaffected.

If you decide to migrate after data has expired: Re-upload a fresh Patreon export. The new upload deduplicates automatically — any patron who has already joined Benecaster since your last upload will be recognized and won’t be treated as a migration target.

Why 90 days: Patron data includes names and email addresses. Storing it indefinitely when it may never be used for a migration is unnecessary. The 90-day window is long enough for most podcasters to decide whether to proceed; if you need more time, re-uploading a current export resets the clock and ensures your data reflects your current patron base.

Before You Migrate: Audio Hosting

If your episode audio files are hosted directly on Patreon, you must move them to a podcast hosting provider before migrating subscribers. Patreon audio can show up in your feed under three addresses: patreon.com, patreonusercontent.com (Patreon’s file storage, and the one your feed most likely shows) and stream.mux.com (Patreon video). The wizard’s note names all three. Benecaster does not host audio — it points your RSS feed at audio URLs from your hosting provider.

A subscriber who completes migration but can’t access audio because it’s still on Patreon will have a broken feed from day one.

The wizard raises this the moment you choose Patreon as where you are migrating from — before you export or upload anything — so you can sort out your audio while changing course is still cheap. It asks again on the pre-migration checklist, where confirming your audio is hosted elsewhere is the one item you cannot skip.

See Moving Audio Files Off Patreon for guidance.

Stage 2: Migrate Your Subscribers (Migration Wizard)

When you’re ready to actively move your Patreon subscribers to Benecaster, the Migration Wizard runs the campaign: invitation emails, grace period access, funnel tracking, and re-send capability for non-completers.

The Migration Wizard is included free with Growth, Pro, Multi-Show, and Studio plans. Starter users can purchase it separately as a one-time add-on.

Where to find it: Benecaster → Shows, open the show you are migrating, then Settings → Migration. The wizard belongs to one show at a time, so on a site with several shows you run it from the show your patrons are moving to. The Migration tab appears only on shows the add-on is switched on for. Once the show has run an import, the tab opens on the migration dashboard instead, and the wizard is behind Start another import. After the people are across, the wizard also offers to bring your back catalogue in as drafts; see Migrating Paying Subscribers. If your Benecaster is too old to record a migration, the tab says so and offers no steps at all — nothing has been started or changed. It names the database version it needs and the columns that are missing. Update Benecaster; if you are already on the newest version and still see this, an update did not finish, so contact support.

The first step is a backup of your Benecaster data, not your whole site. Before the wizard writes anything, it saves your shows, tiers, subscribers and their feed tokens — exactly what the import changes — and gives you a link to download the file. Your pages, media and other plugins’ settings are not in it. If you already run UpdraftPlus or BackupBuddy, the step names it and suggests a full site backup as well. You can skip the backup, but only by ticking a box confirming you already have a recent backup of the site. Backups are listed afterwards under Settings → Tools.

Uploading your export. The upload step repeats how to get the file out of Patreon — Patron Manager → Export; Patreon emails you the CSV — and then reads the file without importing anyone. It shows how many people and columns it found and the first few rows as it read them, and says whether it recognised the file as a Patreon export. If a row has a different number of values from the headings, or the file is longer than one import can take (50,000 rows), it says so. If the file looks more like another platform’s export than Patreon’s, it tells you, but it does not change your choice; you see every column before anything is imported.

See Migration Overview for the full walkthrough.

Keeping a Patron’s Original Join Date

Tenure badges are calculated from when a subscriber’s access started on Benecaster, so a patron of four years would otherwise arrive labelled a New Member.

The Migration Wizard carries each patron’s join date across from your export. Patreon has named that column differently over the years — Join Date, Patron Since and Patronage Since Date — and the wizard recognises all of them, however they are capitalised or spaced. The mapping step shows you which column it matched. If it cannot find one, it stops and asks rather than importing without dates: point it at the right column, or tell it the date is not in your file. It will not carry on until you have answered, because a four-year patron who arrives looking brand new is a mistake only that patron would notice. A migrated patron’s tenure badge and their place on the Supporter Wall then reflect the time they have already backed you.

A few things about the dates themselves:

• The wizard reads dates written as year-month-day (2021-03-04), which is what Patreon exports. It does not guess at a date like 03/04/2021, because that is March in one country and April in another.
• Dates in the future, or before 2004, are not used. Podcasting did not exist before then, so an earlier date is a mistyped year.
• A date the wizard cannot use never stops a patron being imported. They come across with their tenure starting on the day of the import, and the import report lists them as Imported, but the join date could not be read, so you can see exactly who lost their date.
• A patron whose row has no date at all also starts their tenure on the day of the import. Benecaster cannot tell “no date was available” from “joined today”, so check your export has the column before you run the import if tenure matters to you.

Adding a patron by hand works too. On Benecaster → Subscribers → Add subscriber manually there is an optional Supporter since field. The same date limits apply there, except that a refused date stops the form: nothing is created until the date is fixed.

See Subscriber Tenure Badges for how the badge itself works.

Free Members

Patreon lets people join your page without paying. Nothing in the export reliably says which tier was free — a tier called Free Members could be a paid one — so the wizard asks you. Every tier is treated as paid until you tick This tier was free on its card. Check each card before you continue: a free tier left unticked would ask its members to start paying. Once you tick it, you choose where those members land:

• Your followers list (the default). Followers get your public episodes through a feed link of their own, and nothing behind a tier. They appear as followers on the Subscribers screen.
• A free Benecaster tier, if you have one. Choose this if your free tier carries bonus episodes or badges you want your Patreon free members to have. They appear as subscribers on that tier.

A free member is never mapped to a paid tier, so nobody who joined you for free is asked to start paying. Whichever of the two you choose, free members have no grace-period deadline: no link to finish setting up payment, no reminder or final warning, and their feed is never switched off when the grace period ends. That holds even for free members placed on a free Benecaster tier, who show as subscribers — what decides it is that you marked their Patreon tier as free when mapping tiers. They do not use a paid subscriber slot, so a large free list does not push you over your plan’s paid-subscriber limit. Each one does hold a feed link, so each counts toward your plan’s total token cap.

If You Take Payments Through a Membership Plugin

If the show takes payments through MemberPress, WooCommerce Subscriptions, Paid Memberships Pro or Restrict Content Pro, the tier step works off that plugin rather than Benecaster’s own membership:

• The tiers you can map to are the ones linked to your plugin’s levels on the show’s Subscription settings. If one is missing, Missing a tier to map to? takes you there.
• Each paid tier needs a signup page — the page in your membership plugin where people join that level. It is where the link in their emails takes them, already signed in, so the plugin asks for no email or password. The wizard fills in a suggestion from the plugin’s settings; check it opens the right page, and change it if not.
• The page must be on this site. An address anywhere else is refused, because the link cannot reach it. You cannot continue until every paid tier has one.

If the show has no membership system chosen at all, the wizard warns you that nobody can finish the move yet and points you to Settings → Membership. It does not stop you importing, and you have the whole grace period to set one up.

Former Patrons

Patreon’s export includes people who have already left your page, marked Former Patron. The wizard leaves them out by default. It tells you how many it will leave out before you run the import, and you can choose to bring them across as well. Anyone left out is listed in the import report as Had already stopped supporting on your old platform — that is the wizard doing what you asked, not an error.

Bringing them across anyway. The final step, before anything runs, says how many people in your file had already stopped supporting you and offers one box: Bring them across too. It is unticked. Tick it and they are treated like everyone else — they get access, they get the migration emails, and they count toward your plan’s subscriber limit. Left unticked, they cost you nothing: they are not counted in the plan-limit check. Your choice is saved with the import, so running the same file again treats them the same way.

A patron whose last payment was declined is still migrated. A failed charge on Patreon is not a reason to leave somebody behind. If the wizard doesn’t recognise the status written in a row, it imports that patron, and if your export has no status column at all, it imports everyone. Either way it would rather bring someone across than risk leaving out a current supporter. Someone who left and comes across by mistake can be removed; a current supporter left behind is simply gone.

Grace Period and Migration Emails

Everyone you bring across gets access straight away. The grace period — 30, 60 or 90 days, 30 by default — is how long that access lasts while they set up payment with you.

Send the migration email sequence is on by default, and it is the choice that decides how people find their new feed:

• On: each person gets a welcome email from you explaining the move, with their new feed link and their deadline, then a reminder and a final warning if they have not set up payment. Benecaster’s standard “your private podcast feed is ready” email is held back, so your welcome is the first thing they receive. The welcome is signed with your first name, which the wizard asks for and needs before you can carry on.
• Off: Benecaster’s standard “your private podcast feed is ready” email goes out instead, and it becomes each person’s only way to find their feed link. It does not mention you, the move or the deadline, and nobody is told they need to set up payment.

The reminder goes 7 days before the deadline on a 30-day grace period and 14 days before on 60 or 90 days; the final warning goes 3 days before. You can change both. Anyone who was on a free tier is not on a deadline and is never asked to pay.

How long sending will take. With the sequence on, the wizard tells you how many people the welcome email goes to and roughly when the last one should leave — or, for a very large list, that it will take more than a number of days, with no date. Benecaster sends gradually so a new sending domain builds a reputation instead of looking like a burst of spam, so this is a best case: it assumes your site gets enough visits to keep the queue moving. You can ask for a Gentle (about half as fast) or Slowest (about a quarter as fast) pace instead of Standard. Every pace is a way to send more slowly; nothing on this screen can make sending faster, and the wizard never asks you for a sending rate.

If no transactional email service is handling your site’s mail, the wizard says that connecting one is the single change that makes a real difference — to how long sending takes and to whether your email arrives at all — and points you to Settings → Email for the recommendation. It does not promise a new finish date, because it cannot know one until the service is connected.

Your Plan’s Subscriber Limit

Migrated patrons count against your plan’s paying-subscriber limit from the moment they are imported, not when they set up payment — they hold active access to a paid tier straight away. So before anything is written, the wizard checks whether the import fits. If it would take you over the limit, it refuses and imports nobody. Upgrade your plan, or leave some tiers unmapped, and run it again.

It stops rather than warns because the alternative cannot be undone: past the limit, the extra people would be served your public episodes while their welcome email told them their access was live. Free members are not counted, wherever you put them. If the wizard cannot read your plan’s limit — for example on an older Benecaster — it says it could not check, rather than implying there is room, and lets you continue.

Running the Import

The last step sums up what is about to happen — how many people, across how many tiers — and says plainly that nothing has been written yet: this is the step that writes. Click Bring them across and it shows a real count as it goes (156 of 312 complete). Leave the tab open while it runs.

When it finishes, it tells you how many people are now on your show and keeps two things apart:

• Rows that produced nobody — for example an invalid email address, or someone already migrated, which is normal on a re-import.
• People who were imported with something worth knowing — for example a join date that could not be read. They are imported; nobody was lost.

A table lists each of those rows and what happened to it.

If the import stops partway, anyone already brought across stays imported and will not be touched again. Run it a second time and it picks up only the people still missing.

Explicit-Content Field

Patreon exports carry no explicit-content field, so there is nothing for Benecaster to import. Every imported episode is left on Inherit from show, which means each one takes whatever your show’s Explicit setting says.

Benecaster deliberately does not guess here. Marking imported episodes “clean” because the source was silent would be inventing a fact, and on a show you had marked explicit it would quietly override every episode in your back catalogue the wrong way.

So check the show-level Explicit value before you publish. Set it in Shows → Settings → Feeds — it is the value your whole imported catalogue will report to Apple Podcasts and every other directory. If most of your show is explicit and a handful of episodes are not, set the show to Yes and mark those few episodes No individually afterwards.

See Show Settings and Creating Episodes.