The short version

You can switch podcast hosts without asking listeners to resubscribe. The usual mechanism is a permanent HTTP redirect from your old RSS feed to the new feed. When the redirect is configured correctly, podcast apps and directories that follow it can retrieve new episodes from the new host automatically.

The migration is not just an import. It is a coordinated change involving the feed, episode identifiers, directory records, analytics, monetization settings and continued access to the old hosting account. Work through the process in sequence, keep both services available while you verify the change, and do not assume that a redirect or confirmation email proves every directory has completed the update.

This guide covers the decisions to make before moving, a practical cutover checklist and the risks to monitor afterward.

Before you move: make three decisions

1. Is the problem with the host or with your workflow?

Before changing hosts, write down the specific problems you need to solve:

  • Storage limits or per-episode upload caps
  • Pricing that no longer fits your download levels
  • Missing video podcasting support
  • Analytics that do not provide the reporting you need
  • A difficult workflow for producing more than one show
  • Features or controls that would make the publishing process easier

If several of these are material problems, a migration may be worthwhile. If the issue is narrow, compare the cost and disruption of a full move with the possibility of fixing the workflow through existing controls or an add-on.

Do not migrate solely because a dashboard looks different. Historical reporting, episode identifiers and directory relationships can be harder to preserve than the visible show metadata.

2. What must the new host preserve?

Your show’s identity includes more than its title and cover art. Check that the new host can preserve:

  • Show title, author, description and category
  • Cover artwork in the required dimensions
  • Episode titles, descriptions and publish dates
  • Audio files and any associated chapter or video files
  • Season and episode numbers
  • Episode GUIDs, the identifiers podcast systems use to recognize episodes
  • Monetization or dynamic ad settings

GUIDs deserve particular attention. If an import generates new identifiers, listening apps may treat existing episodes as new content. Check the new host’s GUID-handling process before importing, then compare the imported feed with the old feed before changing the redirect.

Preserve a copy of the old feed and a list of its episode GUIDs. That gives you a reference if the imported feed differs.

3. How long can you keep the old service available?

The redirect is set on the old feed endpoint. Keeping the old account, plan and feed active preserves the infrastructure needed to serve that redirect and helps you diagnose problems if the migration is incomplete.

Use an overlap period based on your verification results rather than assuming a fixed number of days is sufficient. Keep the old service available while you confirm that:

  • The old feed redirects to the new feed
  • The new feed contains the complete catalogue with the correct GUIDs
  • New episodes publish correctly from the new host
  • Important directories are using the new feed
  • Listening apps are not creating duplicate episode entries
  • The old host still provides the redirect

If your old host does not support self-service redirects, contact its support team and confirm what they need, when they can apply it and what must remain active on the account.

The cutover checklist

Step 1 — Make a complete backup

Before changing either account, download or export everything the current host makes available:

  • Every audio file, including chapter or video files where applicable
  • Episode artwork and the show cover art in their original sizes
  • Show notes and episode metadata, ideally as a CSV or spreadsheet
  • A copy of the current RSS feed
  • A list of episode GUIDs
  • Any monetization, dynamic ad or other configuration you rely on
  • Historical analytics data that matters to your records

Keep the original audio files unaltered as the first import source. This gives you a clean fallback if the import changes metadata, adds processing markers or otherwise changes the files.

Step 2 — Prepare and import into the new host

Most migration workflows follow this sequence:

  1. Create the new account and show profile.
  2. Add the required show metadata and artwork.
  3. Use the host’s import or migration process, typically by entering the current RSS feed URL.
  4. Review the imported catalogue before publishing anything new.

If the show uses dynamic ads or programmatic insertion, understand how the old host has altered the audio before importing it. A clean source is important, but changing the arrangement without checking can also alter an established workflow. Keep the original configuration in your backup.

Do not assume an import is complete merely because the episode count matches. Verify the feed itself.

Step 3 — Compare the old and new feeds

Open the old and new RSS feeds side by side and review them line by line. Check:

  • Title, author, description and category
  • Show artwork and episode artwork
  • The full episode list and its order
  • Titles, descriptions and publish dates
  • Season and episode numbers
  • GUIDs for every episode
  • The audio URL for at least one old episode
  • The enclosure type, file location and other feed-level settings

Confirm that the GUIDs match the old feed exactly. If they do not, resolve that issue before proceeding where possible.

Also check whether the new feed exposes the episode history in the same way as the old feed. A complete-looking catalogue can still contain differences that affect how directories or apps display it.

Step 4 — Configure the redirect on the old feed endpoint

The redirect must be configured at the old RSS URL, not only inside the new host. Depending on the old provider, the dashboard may offer a feed redirect, RSS migration or 301 redirect option. Some hosts require the old and new feed URLs to be submitted to support.

Before submitting the request, confirm that you have:

  • The exact old feed URL
  • The exact new feed URL
  • Continued access to the old host and its paid plan
  • The redirect configured on the old endpoint

After the host applies it, test the old URL. Confirm that it sends a permanent redirect to the new feed and that the new feed responds correctly. If the redirect does not work, fix that issue before moving the show’s publication workflow fully to the new host.

Step 5 — Review directory entries and submission records

Podcast directories may handle redirects differently. Some can follow a redirect automatically; others may require the publisher to update the feed URL or resubmit the show.

Review the show in each directory that matters to your audience. Check the feed URL shown in its publisher or show-management interface, then look for duplicate entries, missing artwork, incorrect episode metadata or an old feed address.

For Apple Podcasts, use the available hosting-provider change process. If you cannot retain or redirect the old feed, update the RSS feed URL through the show’s Apple Podcasts Connect record. An Apple confirmation email can indicate that Apple processed a feed change or redirect; it should not be treated as proof that propagation to every platform or app is complete.

For other directories, use their current submission or feed-update controls where available. If a directory still shows the old feed, follow that directory’s instructions rather than assuming a manual edit will produce the same result everywhere.

Keep a simple migration log:

Directory Feed shown Action taken Verification date Follow-up needed
Apple Podcasts
Spotify
Other directory

The point is not to predict an exact update window. It is to establish which systems you have checked and which still need attention.

Step 6 — Publish a genuine low-profile episode from the new host

After the redirect and feed checks are in place, publish a real, useful episode from the new host. It can be brief and deliberately low-profile, but it should be a legitimate part of the show rather than a disposable test.

Avoid publishing a placeholder and then deleting it. Deletion can leave redirects, GUIDs or directory records in an inconsistent state, and some systems may continue to reference an item that is no longer available.

Use the episode to confirm that:

  • It appears in the directories and listening apps you monitor
  • The artwork, title, description, date and audio are correct
  • It uses the intended GUID behavior
  • It does not appear as a duplicate of an old episode
  • A listener who follows the old feed can access it through the new feed

Do not rely on a fixed delivery window. Directory ingestion and app refresh behavior can vary, so verify against the systems you actually use.

Step 7 — Monitor the migration before closing the old account

During the overlap period:

  • Keep the old host, its plan and the old feed endpoint active.
  • Confirm that every new episode appears where expected.
  • Watch for duplicate episode reports or new subscriptions attributed to the wrong feed.
  • Compare old and new dashboard figures cautiously, recognizing that reporting methods and date ranges may differ.
  • Export any historical reports you need before closing the old account.
  • Revisit directories that have not yet switched to the new feed.
  • Keep the old audio files and metadata available outside the old host.

Close the old service only when the redirect is no longer needed by the directories and apps you depend on, required data has been exported, and the old endpoint can be retired without disrupting access. If you are unsure whether a platform still uses the old feed, keep the old service active.

What can go wrong, and how to spot it

Duplicate episodes

A changed GUID can cause an existing episode to be presented as new content. Compare the old and new feeds before the cutover. If duplicates have already appeared, ask the new host whether it can restore the original GUIDs, then check how directories handle the corrected feed.

Missing episode or season numbers

Older feeds may contain fields that do not transfer cleanly. Review the imported feed and enter missing values manually where necessary.

Confusing analytics

Analytics from the old and new dashboards may use different definitions, date ranges or attribution methods. A visual dip or increase after the move does not by itself establish where all traffic has gone. Preserve the old reports, compare like-for-like periods where possible and note each dashboard’s reporting differences.

Do not assume that platform analytics reset at a particular point or that one platform’s reporting will necessarily remain more stable than another’s. Verify the actual feeds, dates and metrics in each system.

Stale directory records

A directory may continue showing an old URL, missing episode or duplicate listing. Check its publisher interface and submission records rather than waiting for an assumed universal update window.

The redirect stops working

The redirect lives on the old feed endpoint. Closing the old account, letting the relevant plan expire or otherwise removing that endpoint can break the redirect. Keep the old account and required plan active until your verification supports retirement.

The new feed contains the wrong files

Test several imported episodes, not just the most recent one. Check that the audio resolves, carries the correct metadata and remains accessible from the intended feed.

Frequently asked questions

Do listeners have to resubscribe?

Usually, no. A working permanent redirect can let existing subscriptions continue receiving episodes from the new feed without a manual resubscribe. Do not guarantee that every app, directory or listener state will behave identically. Check your important platforms and communicate the change through your normal show channels.

How long does the redirect take to propagate?

There is no single window that applies to every directory and app. Test the old feed directly, review the directory’s current feed URL and monitor the first published episode. An Apple confirmation email can confirm that Apple processed a change or redirect, but it does not establish that propagation is complete everywhere.

Can I migrate if I no longer have access to the old host?

It is more difficult because the redirect must be set on the old feed endpoint. If the old feed remains live and you can contact the old provider, ask whether support can configure the redirect. If the old feed is gone or cannot be redirected, update the feed URL directly in each directory using its current process. Keep the new feed and show records consistent while you do so.

Should I tell the audience that the show is moving?

A brief note in an episode or show update is useful transparency. It can explain that the feed is changing hosts, invite listeners to report missing episodes and note any genuine workflow improvement without implying that the move requires a new subscription.

What happens to old download numbers and analytics?

Historical data remains tied to the system that collected it unless the new provider imports it. Export available reports before closing the old account. Because dashboards may calculate metrics differently, avoid presenting old and new totals as directly comparable without checking definitions, periods and coverage.

Final checklist

Use this sequence as the core migration plan:

  1. Back up audio, artwork, metadata, GUIDs, feed configuration, monetization settings and needed reports.
  2. Set up the new host and import the feed.
  3. Compare the old and new feeds, including every GUID.
  4. Configure the permanent redirect on the old feed endpoint.
  5. Test the redirect and review each directory’s feed record.
  6. Publish a genuine low-profile episode from the new host.
  7. Monitor the migration while keeping the old host, plan and endpoint active.
  8. Export remaining data and close the old account only after verification.

A careful migration is less about waiting for a fixed number of days than preserving control of the old feed endpoint, checking what each system has actually done and keeping enough access to recover if the cutover is incomplete.

Sources