Move the podcast host without making old episodes look new

Inventory the show before the move

Capture the current feed, show metadata, episode list and the operational owners of the old and new hosting accounts. Include trailers, bonus episodes, seasons, subscriber variants and any material that is intentionally unavailable. A migration acceptance record needs to describe the archive actually being moved, not just the latest few episodes visible in a dashboard.

Apple’s hosting guidance emphasizes consistent metadata and stable episode GUIDs, and warns that changed identifiers can create duplicate episodes or affect analytics. It also describes feed redirects as a migration route. These are platform-specific technical considerations that support a broader continuity check; they do not replace each provider’s current migration procedure.

Compare episode identity and media correspondence

Build a source-to-destination mapping for each episode. Verify the identifier, title, publication information, season and episode numbers, and the audio associated with it. A title match alone is insufficient because edited titles can belong to the same episode and similar titles can belong to different episodes. Ask a technical owner to inspect the actual feed identifiers where dashboards hide them.

Listen to selected old and new media references, including an early episode, a recent episode and an unusual format. Check that the intended audio version and any access boundary are preserved. Do not expose subscriber-only material as an accidental consequence of simplifying the export. Keep any deliberate editorial correction separate from the infrastructure move so a mismatch can be diagnosed.

Agree the cutover and old-feed responsibility

Identify who controls the old feed URL and can maintain the approved redirect or supported migration mechanism. Do not assume cancelling the old plan leaves that route operating. Review the provider’s current requirements and the dependencies of directories, websites, embedded players and campaign links before committing to an end date.

Choose a bounded change window and identify how late episode edits will be reconciled. Have the technical owner explain what can be rolled back and what would create another identity problem. A rushed reversal can be as confusing as the original move if it publishes another copy of the show. Record the decision authority and the evidence that must be checked before expanding the migration or retiring old infrastructure.

Verify the listener-facing result and the reporting boundary

Check the show in its important distribution surfaces after the supported refresh interval. Look for duplicate episodes, missing artwork, incorrect ordering, broken playback and lost subscriber associations. Confirm that a new episode reaches the intended feed route. Keep a list of checked surfaces and limitations rather than claiming every app has updated from one successful test.

Annotate analytics around the migration. Different hosting methods can produce reporting discontinuities, so preserve old definitions and exports where authorized. Investigate changes before presenting them as audience growth or decline. Close the project only after the agreed continuity gates pass and the responsible owner approves the remaining service-retirement steps separately.

Make the reasoning concrete.

A fictional company moves its interview series to a cheaper host. The new feed generates fresh identifiers for old episodes, and several appear as new items in a podcast app.

The team keeps the old route under accountable control while the providers resolve the mapping. It records the analytics discontinuity and does not count duplicated episode exposure as new audience demand.

Take the questions into your next brief.

Use these prompts in your own notes. Nothing is submitted from this page.

1. Inventory

   Which public and subscriber episodes must transfer?

2. Identity

   Which stable identifier maps every old episode to its new record?

3. Route

   Who maintains the old feed redirect or supported handoff?

4. Acceptance

   Which listener-facing surfaces and edge cases will be checked?

5. Retirement

   Who separately approves ending old services after continuity is verified?

Watch for the wrong conclusion.

• Matching episodes only by title.
• Regenerating GUIDs to make an import look clean.
• Cancelling the old host before confirming its redirect responsibility.
• Calling a measurement discontinuity audience growth without investigation.

Sources & scope

Workflows, worksheets and hypothetical examples are original editorial analysis. Platform documentation supports only identified technical principles. No measured business result or named human reviewer is claimed.

• Apple Podcasts for Creators: How to change hosting providers →Primary platform documentation · Supports: Stable episode GUIDs, metadata checks, feed redirects and possible analytics effects during a host migration. The acceptance workflow is original editorial analysis.