The short answer

Before switching podcast hosts, create a portable episode archive and verify that you can reach four things independently of the current host:

  1. The final audio file for every episode
  2. Episode metadata such as titles, descriptions, dates, season and episode numbers, transcripts and explicit-content labels
  3. Show-level assets, especially artwork and show notes
  4. The RSS relationship connecting each episode to its published audio and metadata

A downloadable episode list is not enough if you cannot retrieve the files themselves. Likewise, an RSS feed is not a complete backup. It is a publishing feed, and its usefulness as an archive depends on whether the current host continues serving the linked audio after migration.

The safest process is to work in two phases: export and validate before cutover, then publish and verify after the move.

Understand what an RSS feed does before you migrate

Spotify describes an RSS feed as a file containing the podcast’s information, including titles, descriptions, audio-file links and artwork. If the podcast is hosted with Spotify for Creators, the feed is created when the first episode is published. If another service hosts the show, the creator needs to ask that host for the RSS feed.

This gives you the central distinction:

  • The RSS feed is the map. It tells listening platforms where episodes and show information are located.
  • The audio files are the content. They must remain downloadable and usable after the move.
  • Your export is the portable copy. It lets you recreate the show, recover metadata and upload episodes to another host.

Do not treat the RSS URL as proof that you own an accessible master archive. Save both the feed and the underlying assets.

Pre-cutover checklist

Complete these tasks while the old host is still active.

1. Export every final episode file

Download the published version of each episode, not only the raw multitrack recording. Raw sessions can help you revise an edit, but the published file is the version listeners expect and the one referenced by the feed.

Create one folder per episode and use a consistent naming convention, for example:

podcast-archive/
├── show-artwork/
├── show-metadata/
├── transcripts/
├── rss/
└── episodes/
    ├── 001-the-episode-title.mp3
    ├── 002-another-episode-title.mp3
    └── 003-third-episode-title.mp3

Use filenames that a person can understand without opening the hosting dashboard. Add the season and episode number when the show uses them. Do not rely on the host’s internal download naming system, which may change or be difficult to map back to publication dates.

Then check that each file:

  • Plays from a local device rather than only inside the host’s web player
  • Matches the intended published episode
  • Has a working enclosure URL in the old RSS feed
  • Has a sensible file size
  • Retains a recognizable order when sorted by episode number or publication date

Keep a second copy of the archive outside the current hosting account. A download sitting only in the provider’s dashboard is not an independent backup.

2. Export episode metadata in a usable format

Copy the fields you will need to rebuild the show. Depending on the host, this may be available as a CSV, spreadsheet, text export or a set of episode pages. Preserve the original export alongside any spreadsheet you create.

A useful metadata record contains:

Field Why it matters
Episode number Preserves sequence and prevents duplicate numbering
Season number Separates recurring series
Title Identifies the episode
Publication date and time Helps recreate the release timeline
Description or show notes Preserves the editorial context
Audio file name Connects each episode to its exported media
Enclosure URL Records the old published-file location
File type and duration Helps detect missing or mismatched episodes
Episode artwork, if any Preserves visual identity
Transcript or chapter file Retains navigation and accessibility material
Explicit-content label Preserves the intended classification

If the host does not offer a structured export, copy the information from each episode page into a spreadsheet. This is slower, but it creates a durable record before access changes.

Do not flatten the data too aggressively. A title alone is not enough to reconstruct a feed; an enclosure URL without a local audio file is not enough to recover the episode.

3. Preserve show-level assets and settings

Export or download the assets that define the show, including:

  • Current cover artwork at the highest resolution available
  • Alternate artwork if platforms use different crops
  • Show description and category information
  • Author or owner details
  • Explicit-content setting
  • Language and relevant ownership fields
  • Contributor, producer and publishing-team information
  • Links used in the show profile
  • Monetization or subscription configuration that must be recreated

Keep both the original uploaded artwork and any source file your team created. A small platform thumbnail is not necessarily a suitable replacement for future artwork production.

Also document decisions that cannot be inferred from the files. For example, note whether the show uses a specific naming convention, whether episode numbers appear in titles, and which files contain corrections. Such notes help a small team avoid rebuilding conventions from memory.

4. Save the current RSS feed and inspect its relationships

Save the current public RSS URL as a text file. Then save a copy of the feed itself with a date in the filename, such as:

rss/feed-before-migration-2026-03-20.xml

The date above is an example filename, not a claim about when your migration occurs.

Open the saved feed and check one episode at minimum, preferably several across the catalog:

  • Does the episode title match the metadata export?
  • Does the enclosure point to the intended audio file?
  • Does the enclosure URL still return the audio?
  • Are artwork URLs accessible?
  • Is the publication date present and correct?
  • Are season and episode numbers included where expected?
  • Does the feed contain the complete episode history?
  • Are transcript or chapter relationships present when the show uses them?

The feed is the map you will use to compare the old show with the new one. If the new feed does not reproduce the same episode-title, audio-file and metadata relationships, the migration is not complete.

5. Confirm what the platform can remove—or cannot remove

Spotify warns that it cannot remove a podcast from third-party platforms that scrape its RSS feed. Its documentation notes that a listing may remain in an aggregator’s directory even after the podcast is deleted.

That is an important distinction for migration planning:

  • Switching the feed URL: listener applications and aggregators may continue using the old feed or old enclosure URLs.
  • Changing the podcast: the show may need to be treated as a new show or a changed RSS destination, depending on the platform’s rules.
  • Closing the old account: do not assume that deletion removes every existing directory listing or cached episode reference.

Spotify’s guidance for a new RSS feed or hosting provider says that a 301 redirect from the old feed to the new one should be used when the host supports it. If it does not, the listing may need to be updated so listeners can continue receiving new episodes. Check the old host’s capabilities before signing up; do not assume every host can create a feed-level redirect.

A practical sequence is:

  1. Export and back up the old catalog.
  2. Create the new show with matching ownership details.
  3. Migrate and publish the episodes you need.
  4. Compare the old and new RSS relationships.
  5. Redirect the old feed to the new feed if supported.
  6. Update directory submissions where required.
  7. Keep the old feed and files available during the transition period.
  8. Retire the old setup only after the new feed is stable.

Do not close the old host immediately after the first successful upload. The first episode may work while later episodes, artwork or redirects still fail.

Post-move verification

Treat the move as complete only after testing the feed, not merely the dashboard.

Check the new feed itself

Open the new RSS feed in a browser and confirm that it contains:

  • The correct show title and description
  • All expected episodes in the correct sequence
  • Working audio enclosures
  • Correct artwork
  • Publication dates
  • Season and episode numbers where applicable
  • Transcript or chapter links where applicable
  • The intended ownership email or verification field

An owner email may be part of the feed for verification purposes. Spotify notes that some listening platforms use that address to verify ownership when a creator submits or claims the show. It also warns that the email is publicly visible to anyone with the feed link, so treat feed publication as a disclosure decision rather than an automatic housekeeping step.

Test from outside the new host

Use a podcast app that is not the new host’s web player. Test on at least one device you control, subscribe using the new RSS URL, and confirm that:

  • The show appears correctly
  • New episodes appear
  • Older episodes play
  • Artwork looks correct
  • Dates and episode numbers are correct
  • Audio metadata behaves as expected
  • A transcript or chapter link opens if one is advertised

If the creator’s phone already knows the old show, test a fresh subscription as well. Otherwise, an old subscription may conceal a broken feed transition.

Compare old and new episode records

Create a reconciliation sheet:

Old RSS item | New RSS item | Audio opens | Metadata matches | Artwork matches | Notes

Investigate every mismatch. A common but subtle error is an episode with the correct title attached to the wrong audio enclosure or the wrong episode number.

Watch the old feed separately

Keep checking the old RSS URL after the switch. Confirm that it redirects to the new feed, when redirection is available and expected. If it does not, check whether the old host still serves the previous feed and whether directories need a submission update.

Do not treat a successful redirect as proof that every directory has updated. Feed readers and aggregators can update on different schedules. Continue monitoring listener-facing platforms after the cutover.

A copyable migration ownership record

Use this as the header for a migration log:

Podcast:
Old host:
Old public RSS URL:
New host:
New public RSS URL:
Date exports verified:
Date episodes uploaded:
Date redirect tested:
Date external app test completed:

Audio archive location:
Metadata export location:
Artwork archive location:
Transcript archive location:
Old-feed monitoring end date:
Owner/contact for directory support:
Open issues:

This record separates four different claims:

  • Possessed: the files are downloaded and readable
  • Prepared: the metadata and assets are organized
  • Published: the new RSS feed contains them
  • Verified: listeners and directories can retrieve them

A podcast migration is safe only when all four are true.

Common migration mistakes

A dashboard link can expire or disappear when the account closes. Download the actual files and test them outside the platform.

Forgetting episode-specific artwork

Show artwork is not a substitute for an episode-specific image. Export both when the show uses episode artwork.

Rebuilding metadata by memory

Use the old feed, episode pages and structured export as the record. Memory introduces missing dates and inconsistent episode numbers.

Changing the feed before testing the new one

Publish and test the new feed first. Redirecting too early can send listeners toward an incomplete catalog.

Deleting the old host too soon

Keep the old service active while you test external apps, directory listings and redirects. When the old provider cannot preserve access, preserve a local archive regardless.

Assuming the feed owns the audio

An enclosure URL is a relationship to media hosted somewhere. The strongest ownership position is a local or independent copy of each final audio file plus the metadata needed to rebuild the relationships.

Frequently asked questions

Does an RSS feed contain the podcast audio files?

Not necessarily. An RSS feed contains links and metadata that point to episode media. The feed may identify the audio enclosure without giving you a separate permanent master archive, so export the files as well.

Can I migrate a podcast by changing the RSS URL alone?

Only if the new setup already contains the episodes and their metadata and the listening destinations will follow the new URL. A reliable migration normally combines a new feed with an old-to-new redirect or directory update where supported.

What should I keep if disk space is limited?

Prioritize the final published audio for every episode, a complete metadata export, the current artwork and the saved RSS feed. Raw recordings and multitrack sessions are useful but do not replace the published episode files.

How do I know the migration is complete?

The new feed contains the expected episodes, their audio enclosures open, artwork and metadata match the old catalog, a third-party listening app works, and the old feed either redirects appropriately or has been handled according to the provider’s current guidance.

The core principle is simple: export the files, preserve the metadata, understand the RSS relationships, and verify from a listener’s perspective. The hosting platform supplies the distribution layer, but your portable podcast archive should remain usable even if that layer changes.

Sources