Moving a podcast host is not just a matter of uploading the same MP3s somewhere else. The new host needs a complete map of your show: the files, the episode identifiers, the metadata listeners see and the optional assets that make an episode useful.

The safest workflow is to treat migration as an inventory-and-validation project. You first capture the current feed, map every field and asset, then rebuild the destination and test it before directing directories to the new URL.

The short version

Use this sequence:

  1. Freeze a source-of-truth export. Save the existing RSS feed, an episode spreadsheet and copies of the show artwork, episode artwork, transcripts and chapter files.
  2. Map show-level fields. Record the title, description, author, language, categories, explicit-content setting, website link, copyright, artwork and owner contact.
  3. Map every episode. Record the title, description, publication date, GUID, media URL, media type, byte length and duration.
  4. Map optional episode assets. Track episode artwork, transcripts and chapter files separately so a missing file is obvious.
  5. Rebuild and validate the new feed. Check the XML, required tags, unique GUIDs, media URLs and artwork before asking directories to switch.
  6. Keep the old feed alive during the transition. Redirect the old feed URL when your new host supports redirects, and monitor the new feed for a defined period before retiring old copies.

A spreadsheet is enough for a small catalogue. If you have hundreds of episodes, a structured table or database is still useful, but the field model remains the same.

What actually needs to move?

A podcast feed contains two main layers:

  • Show metadata describes the podcast as a series. Examples include the show title, description, author, language, category and artwork.
  • Episode metadata describes each individual episode. Examples include its title, description, publication date, episode GUID, audio enclosure, episode artwork and optional transcript.

Podcast directories use the feed to discover and display the show. The audio file is still hosted separately, and the feed points to it. During a migration, therefore, verify both the metadata and the delivery of every referenced asset.

Apple’s RSS guidance identifies core show tags such as title, description and artwork, along with episode information including title, description, publication date, GUID and media enclosure. The Podcast Standards Project adds guidance for podcast-specific namespaces, including transcripts and chapter links. Your destination host may expose different labels in its dashboard, but it must ultimately produce a podcast-compatible feed.

Copyable podcast RSS migration template

Duplicate one row per episode and one row per show-level item. Keep URLs in full rather than shortening them in the working sheet.

A. Show-level mapping

Source field Your value Destination field or setting Migration note
Show title Keep the public title unless you intentionally reposition the show.
Subtitle Confirm whether the destination exports it.
Show description Preserve useful links and formatting.
Author Distinguish the displayed author from the administrative owner if needed.
Owner name This may not appear publicly.
Owner email Keep this accessible to the owner; do not confuse it with a public contact field.
Website or show link Use a stable public page, not a temporary editing page.
Language Use the language code accepted by the destination platform.
Category and subcategory Check the destination platform’s available category list.
Type Distinguish episodic from serial where the destination supports the choice.
Explicit-content flag Preserve the intended rating and avoid changing it accidentally.
Copyright Preserve the rights statement.
Show artwork Record the original file, URL, dimensions and format.
Original feed URL Keep for redirects, history and validation.
Owner email address Keep this accessible to the owner; do not confuse it with a public contact field.

Do not treat the owner email as disposable metadata. It is administrative information, while the author and website may be displayed publicly.

B. Episode-level mapping

Source field Your value Destination field or setting Migration note
Episode title Compare exactly, including punctuation.
Episode description Preserve links, sponsor disclosures and accessibility information.
Episode number Useful for serial shows; do not confuse it with the GUID.
Season number Add only if meaningful and supported.
Publication date and time Preserve the intended order and include the correct time zone.
Episode GUID Treat this as the episode’s permanent identifier.
Audio URL Check the public URL and byte-range support.
Media type Confirm that it matches the actual file format.
Byte length Compare with the hosted file, not with an old database value.
Duration Confirm against the new file.
Episode artwork Store the source file and public URL separately.
Transcript Record format, language, public URL and whether it is timed or plain text.
Chapters Record the source file, public URL and expected start time.
Explicit-content flag Check episode-level overrides.
Closed captions, if used Keep separate from an audio transcript.

Migration rule: keep the episode GUID stable whenever possible. Apple states that every episode needs a globally unique identifier and that duplicate enclosure URLs are ignored. Changing an identifier can therefore make an existing episode look new to directories. A migration should change delivery locations, not episode identity.

C. Asset inventory

Asset type Show or episode Source filename Public URL Destination location Validated
Show artwork Show
Episode artwork Episode
Audio file Episode
Transcript Episode
Chapter file Episode
Captions Episode

This small asset table catches a common failure mode: the episode appears in the feed, but its transcript or artwork URL returns an error.

Map the episode metadata without changing meaning

Metadata migration is not simply a column-by-column copy. The same information may have different names in different hosts.

Use a three-part decision for every field:

  1. Portable: Keep it because it describes the podcast or episode, regardless of host. Titles, descriptions, dates, identifiers, media information and rights information belong here.
  2. Destination-specific: Let the new host manage its own options. Examples include internal categories, editor workspaces, storage folders and platform-specific statistics.
  3. Conditional: Transfer only when it is still meaningful and the destination supports it. Episode artwork, transcripts and chapters usually belong here.

This avoids forcing every source field into the new platform. The goal is a clean public feed, not a literal clone of the old dashboard.

Preserve the episode GUID

Treat each GUID as a permanent episode ID. Put it in a protected column and check every imported row against the old feed. If the destination generates a new GUID automatically, verify whether it can accept the old value before publishing.

Do not create a new GUID merely because the media URL or file name changed. The GUID represents the episode identity; the enclosure URL identifies where its audio can currently be fetched.

Preserve dates and episode order

Copy the original publication date and time, including the correct offset. Apple’s technical guidance calls for RSS 2.0-compliant dates and gives an example with a day-of-week, day, month, year, 24-hour time and time-zone offset.

For a serial show, an incorrect date or type can make the available order feel wrong even though the feed technically loads. Compare the new feed’s date sequence with the old one before migration.

Handle artwork, transcripts and chapters as separate assets

Show and episode artwork

Keep the original artwork file and its live URL in the inventory. When replacing artwork, Apple recommends changing the file name and URL at the same time, making sure the extension matches the actual file and verifying that the server supports HEAD requests, including Last Modified information.

Apple’s artwork requirements specify square JPEG or PNG artwork within the documented size range. Those requirements can change, so use the current destination-platform and directory requirements at migration time rather than treating any one host’s export as universal.

Do not rely on an image copied into a social post, private drive or temporary project folder. The feed needs a stable public URL that a podcast application can request without a login.

Transcripts

A transcript is not automatically the same thing as a closed-caption file. Record:

  • Whether it is plain text, timed text, WebVTT, SRT or another format;
  • Whether it is human-edited or machine-generated;
  • Whether it includes speaker names;
  • The public URL or destination upload location;
  • Whether the language matches the episode.

The Podcast Standards Project describes podcast transcript elements, including the transcript URL, type and language. Check the current specification and the destination host’s export behavior before assuming every transcript feature will survive the move.

Chapters

Treat chapters as both a structured file and a discoverability feature. Preserve the episode audio reference, start time and chapter title data. If the source only provides a manually formatted list, record that limitation instead of inventing timestamps.

If your existing chapter workflow still needs work, our guide to creating accurate, portable podcast chapters covers the distinction between manual, transcript-based and AI-assisted chapter production.

The migration workflow, step by step

1. Capture the existing feed before changing anything

Download or save the current RSS feed and record its URL. Export the episode list if the old host offers an export. If it does not, parse the saved feed into a spreadsheet, but keep the original XML as the authoritative backup.

For every item, save:

  • Title and description;
  • Publication date;
  • GUID;
  • Enclosure URL, type and length;
  • Episode artwork URL;
  • Transcript URL;
  • Chapter reference.

2. Audit missing assets before the move

Open every artwork, transcript, chapter and audio URL in a private browser session that is not signed in. A file visible to you in your host dashboard may still fail when an external directory requests it.

Mark each result:

  • Working;
  • Redirected;
  • Missing;
  • Access blocked;
  • Wrong file type;
  • Not exported by the destination.

Fix broken source links if practical. Do not import a known failure into the new catalogue.

3. Import a small test batch

Start with a few representative episodes rather than the entire back catalogue:

  • A standard solo episode;
  • An interview;
  • An episode with chapter markers;
  • An episode with a transcript;
  • An episode with custom artwork;
  • The oldest episode, if you want to test back-catalogue order.

The test batch should expose the different metadata paths you need to check without making a full migration harder to undo.

4. Rebuild the destination feed

Upload or link the audio and assets, enter the mapped show metadata, and apply the episode fields from the template. Confirm that the destination exports the fields rather than merely displaying them in its editor.

For each episode, check:

  • The title is exact.
  • The description is intact.
  • The date and offset survived.
  • The GUID is unchanged.
  • The audio URL is public and reachable.
  • The media type matches the file.
  • The byte length matches the hosted file.
  • The duration is correct.
  • Artwork, transcript and chapter references are present where intended.

5. Validate the new feed

Run the new RSS URL through a feed validator before updating directories. Cast Feed Validator is identified by the research dossier as a practical option, but it is only one check; it does not prove that every external asset is permanent.

Also check the feed manually:

  • Does the XML parse without errors?
  • Are required show tags present?
  • Does every episode have a unique GUID?
  • Do enclosure URL, type and length describe the actual audio?
  • Are dates in the expected format?
  • Is the feed URL public and not password-protected?
  • Can the hosting server handle HEAD requests and byte-range requests?
  • Do artwork URLs match their actual file types?
  • Do transcripts and chapters resolve without sign-in?

Apple’s current feed requirements and the Podcast Standards Project are the most relevant references for required fields and podcast-specific elements. Use them alongside the destination host’s documentation.

6. Point directories to the new feed

Submit or update the new feed URL in every directory you use. Do not assume changing the host automatically updates Apple, Spotify or other listening applications.

Where the old host allows it, create a permanent redirect from the old feed URL to the new one. This helps listeners, directories and saved links that still use the former address. Keep the old feed online during the transition rather than replacing it with a blank page.

7. Validate distribution after the switch

After updating the directories, wait for their normal refresh cycle and check a sample episode in each major listening app. Confirm that the episode appears in the intended order and that audio playback works.

Check the following separately:

  • The show listing;
  • The show artwork;
  • A recent episode;
  • An older migrated episode;
  • An episode with a transcript;
  • An episode with chapters;
  • Episode artwork, if used;
  • A downloadable or direct media URL.

For a broader pre-publish routine, use the podcast episode publishing checklist after the migration. It helps you inspect metadata, accessibility assets and RSS separately before deciding that an episode is ready.

RSS feed field checklist for sign-off

Use this final checklist for the destination feed:

Show level

  • Title, description, author and website are present.
  • Language, category and explicit-content settings are correct.
  • Show artwork is public, square and served from a stable URL.
  • Copyright and owner details are correct.
  • The old feed redirects to the new feed, if supported.

Episode level

  • Every episode has a unique, stable GUID.
  • Titles, descriptions, dates and times match the source.
  • Every audio enclosure has a working URL, type and byte length.
  • Episode artwork, transcripts and chapters resolve where included.
  • Serial or episodic ordering is unchanged.
  • Direct audio playback works outside the host dashboard.

Distribution

  • The new feed passes a validator.
  • The new URL has been submitted to relevant directories.
  • Sample episodes appear and play in major listening apps.
  • The old feed remains available during the transition.

Common migration mistakes

Creating new GUIDs for existing episodes

This can make the destination feed look like a different publication. Preserve the original GUID wherever the host allows it.

Importing the whole catalogue before testing

A small test batch catches artwork, transcript, chapter and date problems while they are still easy to correct.

Treating the destination dashboard as proof of the feed

Some hosts show metadata in an editor without exporting every field to RSS. Inspect the actual feed.

Descriptions often contain sponsor links, disclosure text, show notes and resources. Compare them with the source rather than recreating them from memory.

Leaving private or temporary asset URLs behind

A local file, permission-restricted cloud link or expiring project URL may work for the team but fail for listeners and directories.

Changing the feed URL without preserving the old route

If a redirect is available, use it. Otherwise, keep the old feed available for an appropriate transition period and update directories directly.

Retiring the old audio too soon

The new feed should point to files hosted by the destination service, but keep redundant copies temporarily until distribution has been checked. Do not leave two public hosts serving contradictory metadata indefinitely.

A practical ownership rule for independent podcasters

Your migration sheet is part of your podcast’s operational records. Keep the latest export, asset inventory, field map and validation record with the show’s source files. If you later move again—or need to replace a damaged asset—you will not have to reconstruct the catalogue from memory.

The destination host owns the infrastructure that serves your new feed and audio. Your own records preserve the ability to recover, move or rebuild. For a solo creator, that combination is a practical ownership model: use the host for distribution, but keep a portable catalogue and validated backups.

Frequently asked questions

Should every podcast host preserve RSS fields exactly?

No. The feed should preserve the meaning of portable fields and the identity of existing episodes. Destination-specific controls can differ. The important checks are that required fields are exported, episode GUIDs remain stable and every public asset resolves.

Can I migrate without redownloading the audio files?

The answer depends on the hosts. Some import tools transfer files; others accept enclosure URLs or require a manual upload. Do not assume the audio has moved simply because the episodes appear in the new dashboard. Test the public URLs and byte-range delivery in the new feed.

What is the safest order for transferring assets?

Start with the show artwork and a small representative episode batch. Add episode artwork, transcripts and chapters, validate the feed, then transfer the remaining catalogue. This reduces the number of changes you need to troubleshoot at once.

Is the RSS XML template necessary if the new host creates the feed automatically?

You still need the mapping sheet. The destination may generate XML for you, but you must confirm that it exports the required metadata and preserves the episode identifiers, dates and asset references that matter to your show.

Final takeaway

A successful podcast migration changes where the feed and assets are served without accidentally changing what your show is. The downloadable value of this process is the mapping sheet and checklist: they expose missing fields, unstable identifiers and broken asset URLs before listeners encounter them.

Start by freezing the current feed, preserving GUIDs and creating a complete show-level, episode-level and asset inventory. Then rebuild, validate and test the destination before you switch the directories.

Sources