How to switch podcast hosts without losing subscribers
Open a source-aware analysis with this article as the primary source.
Add us to your Preferred Sources.
To switch podcast hosts, copy your complete catalog to the new host, compare the new RSS feed with the old one, redirect the old feed, and verify that listening apps now read the new URL. Do not cancel the old account until the redirect and a newly published episode both work.
The move is mostly an RSS operation. Your subscribers follow a feed rather than an account at your hosting company. If that feed points to the same show and episodes at a new address, their podcast apps can continue fetching it without asking listeners to subscribe again.
The risky version is a rushed move that combines a host change, rebrand, artwork replacement, episode cleanup, and analytics change in one afternoon. Keep the show stable while you move it. You can tidy it later.
Before you switch podcast hosts
Collect the parts that let you compare the old setup with the new one. You need access to both hosting accounts, the current public RSS feed URL, your show artwork, the original audio files if available, and login access to the platform dashboards where you claimed the show.
Download any reports you want to keep. Hosting analytics are account data, not part of the public RSS feed, so a feed redirect does not carry a dashboard history into the new account. Record the cutover date now. That line will explain the break in future monthly reports.
Make a small inventory before touching either feed:
| Item | What to record | Why it matters |
|---|---|---|
| Old RSS URL | Full public URL | This is the address that must redirect |
| New RSS URL | Full public URL | This is the destination you will validate |
| Episode count | Published and trailer episodes | A mismatch exposes a partial import |
| Recent GUIDs | GUIDs for several recent episodes | Stable GUIDs help apps recognize existing episodes |
| Artwork | File and visible version | A surprise image change can signal a bad import |
| Platform access | Apple, Spotify, and other claimed dashboards | Some services let you confirm or update the feed |
| Baseline | Latest downloads and publishing status | This gives you something to compare after cutover |
Apple's podcast RSS feed requirements say every episode must have a GUID that never changes. They also require a unique enclosure with URL, length, and media type. Those details are worth checking because an import that creates new GUIDs can make an existing episode look new to a listening app.
If RSS terminology is still fuzzy, read what an RSS feed is before moving anything. Leave the XML editing to the hosts and make sure you know which feed is old and which is new.
1. Open the new host without closing the old one
Create the new hosting account and use its import or transfer tool. It will normally ask for your current RSS feed URL and copy the show metadata, artwork, episode records, and audio files it can reach.
Do this while the old feed is still public. The importer cannot copy files it cannot fetch. If your old account has unpublished drafts, private episodes, dynamic ad settings, transcripts, or platform-specific video, review them separately because they may not live in the public feed.
Host choice comes before migration mechanics. Storage, team access, private feeds, dynamic ad controls, support, and analytics vary. Our podcast hosting company comparison gives you a short list if you have not picked the destination yet.
2. Compare the old and new RSS feeds
Open both feed URLs in a browser or feed validator. The XML will look ugly, but the checks are straightforward.
Confirm that the show title, author, description, categories, language, explicit-content setting, and artwork match. Then inspect the newest episode, an older episode, and any trailer. Compare each episode's title, publication date, GUID, description, duration, and enclosure.
Apple requires RSS 2.0, a publicly addressable feed, HTTP HEAD and byte-range support for media, and permanent episode GUIDs. Your new host should handle the server details. Your job is to catch differences introduced during import.
Do not use this move to delete old episodes or rewrite every title. If an app shows duplicated or missing episodes after cutover, you want one likely cause, not five.
3. Check the public show before redirecting
The new host may provide a preview page or an unpublished feed before you point the old feed at it. Use that window.
Play the newest, oldest, and longest episodes from the new location. Check artwork on mobile and desktop. Open show notes with links. Confirm that episode files start, seek, and resume. If your show publishes transcripts or chapters through RSS, inspect those too.
For a network, repeat the check on every show rather than assuming one successful import proves the rest. What networks check before a host migration covers shared permissions, video support, and other multi-show complications.
4. Set the redirect at the old host
Once the new feed is complete, use the old host's redirect or forwarding control. The wording varies, but you are looking for a permanent feed redirect to the new RSS URL. Paste the destination carefully and save it once.
Test the old URL after the change. It should lead to the new feed, not to a marketing page, account login, or missing-page message. Check the redirect from a private browser window so a signed-in session does not hide a problem.
Some hosts also add a feed-level notice for podcast apps. Use the host's documented migration flow rather than editing the feed yourself. The redirect is the main handoff because directories and podcast apps may still request the address they already know.
Do not submit the new feed as a brand-new show. That can create a duplicate listing with no subscriber history. You are moving one existing show, not launching a second one.
5. Confirm or update the feed in platform dashboards
Spotify documents a manual feed update for externally hosted shows. In Spotify for Creators, open the podcast, go to Settings, review the current RSS feed and hosting partner, click Update, enter the new feed, confirm the host, and submit.
Other platforms expose different controls or rely on the redirect. Log in to every dashboard where you claimed the show and check the feed it recognizes. Do not paste a new URL into a field unless the platform says that field changes the current show's feed.
Build a short verification list around the apps that account for your actual listeners. Apple Podcasts and Spotify belong on nearly every list. Add the next few apps from your current analytics instead of checking dozens with no audience.
6. Publish one controlled test episode
After the redirect is live and the directories show the right feed, publish your next normal episode from the new host. Avoid making it a special release with an unusual schedule or format. A routine episode is easier to compare.
Check that it appears once, with the correct title, artwork, duration, show notes, and audio. Play it in the major apps. Then check the new host to confirm requests are arriving.
A test episode gives you evidence that the entire path works: the new host generated the item, the feed exposed it, directories fetched it, apps displayed it, and the media file played.
7. Keep both accounts during the verification window
Leave the old account in place while you watch distribution and document any missing assets. The right waiting period depends on the old host's redirect policy, billing terms, and the platforms you monitor. There is no useful universal countdown.
Cancel only after all of these are true:
- The old RSS URL redirects to the new RSS URL.
- The new feed passes the platform checks you use.
- Existing episodes still appear and play.
- A new episode has distributed once without duplication.
- Your main platform dashboards recognize the new feed or host.
- The new analytics dashboard shows incoming activity.
- You exported old analytics and billing records.
Before cancellation, ask the old host whether the redirect remains active after the paid account closes and for how long. Save the answer with your migration notes.
What moves and what stays behind
| Usually moves through the feed | Usually needs separate handling |
|---|---|
| Published episode titles and descriptions | Historical analytics dashboards |
| Publication dates | Team members and permissions |
| Episode GUIDs, if the importer preserves them | Draft and scheduled episodes |
| Public artwork and show metadata | Dynamic ad campaigns |
| Public audio files, if copied successfully | Private feeds and subscriber access |
| Public transcripts or chapters included in RSS | Billing records and integrations |
Treat anything outside the public feed as a separate workstream. That includes web pages hosted by the old provider, embedded players, SmartLinks, ad pixels, API connections, and email capture forms.
If you use a third-party analytics prefix, confirm that the new host supports it before moving. Podder works with supported hosts including Buzzsprout, Transistor, Megaphone, Simplecast, Captivate, Podbean, Spreaker, Castos, Art19, OmnyStudio, Blubrry, SoundCloud, and PodOps. Some hosts do not allow third-party prefixes, so this belongs in host selection, not in the final hour of migration.
Common switching mistakes
Changing or closing something before the new feed and redirect have been tested can break the switch.
Closing the old account first
The old feed is the handoff point. Closing it before importing, redirecting, and testing removes the easiest route for apps and the new host to find the show.
Changing GUIDs
A GUID identifies an episode inside the feed. Apple's requirements are blunt: it never changes. If an import generates different GUIDs for old episodes, stop and ask the new host to fix the import before redirecting.
Combining the move with a rebrand
A new title, categories, artwork, and episode archive can be valid changes. Making them during a host switch makes every mismatch harder to trace. Move first, rebrand second.
Comparing analytics across the cutover as one series
Different systems may filter and label requests differently. The IAB Tech Lab podcast measurement guidelines exist to make download, audience, and ad-delivery metrics more consistent, but a host change can still create a visible break. Keep the old export, name both sources, and mark the date.
Forgetting embeds and links
Your feed may move cleanly while the player on your website still points to the old host. Search your site, newsletter templates, link-in-bio page, sponsor deck, and automations for old-host URLs.
How you know the podcast host switch worked
A successful move is boring. Existing subscribers see one show. Old episodes still play. The next episode arrives once. The old RSS URL reaches the new feed, and the new host receives activity.
Check those conditions from outside both hosting accounts. A green badge inside the new dashboard is useful, but the listener's path is the real test.
Once the new host is stable, start tracking your show with Podder. Install the analytics prefix fresh on a supported host, record the install date, and treat the new dashboard as a new measurement series rather than pretending the old history transferred.
FAQ
Will I lose podcast subscribers when I switch hosts?
A correct permanent redirect from the old RSS feed to the new one should send podcast apps to the new feed, so listeners remain subscribed. Test the redirect and check the major listening apps before closing the old account.
Do podcast analytics move to the new host?
Usually not. The new host starts measuring requests it receives after the switch. Export any reports you need from the old host before closing the account, and mark the cutover date in future reports.
How long should I keep the old podcast host active?
Keep it active until the redirect works, the new feed validates, recent episodes play in the major apps, and a new episode has distributed correctly. Confirm the old host's own retention policy before cancelling.
Should I submit the new RSS feed as a new podcast?
No. A second submission can create a duplicate show. Redirect the existing feed and update the feed URL inside platform dashboards where that option is available.
Can I change my show name during the move?
You can, but separating the hosting move from a rebrand makes problems easier to diagnose. Move the same show first, confirm distribution, then change its title or artwork.
See who's actually listening.
Podder gives you audience demographics, per-episode analytics, and chart tracking. The Chartable alternative that goes deeper.
Start free