> For the complete documentation index, see [llms.txt](https://docs.podigee.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.podigee.com/documentation/grow-and-monetize/monetization/plan-a-safe-migration.md). # Plan a safe migration Plan a controlled move from another ad platform while keeping the current podcast delivery live. Podigee Audio Video Ad Server gives you a controlled path from another ad platform to Podigee. After the first mention, this article uses Podigee Ad Server for the product name. The plan defines the scope, authority, source mapping, acceptance checks, delivery mode, evidence, and rollback boundary before you import records or change listener delivery. The current RSS feed and public podcast identity can remain stable while the delivery authority is prepared. Planning does not move listeners, create paid delivery, or change the current source of truth. ## Before you start * You are the migration owner or have permission to create a migration project. * You can export the source platform records and their source references. * You know which podcasts, Campaigns, inventory, Creatives, policies, reports, and finance records are in scope. * You know the current delivery authority and the target Podigee workspace. * You have an owner, reviewers, acceptance criteria, and a rollback owner. Do not start with a live switch. The first plan must make the migration measurable and reversible. ## Define the migration scope Write down the exact scope before you open the task: * Podcasts and episodes included. * Audio, video, RSS, HLS, Marketplace, and report surfaces included. * Campaigns, Flights, targeting, Creatives, inventory packages, and policies included. * Delivery, event, finance, and external integration records included. * Records that must remain in the current platform. * Data that must not be imported, such as expired, test, or unsupported records. Use a small, representative set first when the source contains many records. Include at least one audio delivery path, one video delivery path when applicable, one no-fill or fallback case, and one record with a meaningful source reference. ## Define authority and the stable RSS boundary Record these decisions in the migration plan: 1. The current platform remains the listener-facing authority until the cutover is explicitly approved. 2. The existing RSS feed URL and episode identity stay unchanged unless a separate publishing change is approved. 3. The delivery path may change only at the agreed source and time boundary. 4. Analytics, delivery events, billing, and support evidence must identify which authority produced each result. 5. A rollback returns the same podcast and episode scope to the last verified delivery authority. This boundary prevents a migration from creating two competing sources for one episode. ## Map source records to Podigee records Prepare a mapping table for each record type: * Source identifier and source version. * Podigee record type and target identifier when one already exists. * Proposed new record when no target exists. * Owner, status, market, dates, and external references. * Mapping decision, reviewer, and reason for any exception. Keep source identifiers as references. Do not use a name or filename as the only mapping key. Flag duplicates, missing parents, unsupported formats, and records with uncertain ownership for review before import. ## Set acceptance criteria Define pass and stop rules before any comparison runs. Include: * Exact source and target record counts. * Media duration, codec, loudness, and rendition checks. * Ad break and marker position checks. * Decision, targeting, frequency, pacing, and fallback behavior. * RSS, HLS, Apple, Spotify, and player behavior that is in scope. * Analytics events and report totals. * Delivery cost, booked value, and billing evidence. * Maximum accepted difference and the evidence required for each exception. An accepted difference must have an owner and a written reason. An unexplained difference blocks the next migration step. ## Choose the delivery mode Use the safest mode that answers the next question: * **Preparation:** records are mapped and validated. Listener delivery stays on the current path. * **Shadow checks:** the target prepares and compares delivery without changing what listeners receive. * **Cutover ready:** all blocking checks pass and a reviewed transition boundary exists. * **Live:** the approved target is the delivery authority for the selected podcast scope. Never describe preparation or shadow checks as live delivery. The existing path stays live until the cutover is complete and verified. ![The current One Podigee confirmation dialog starts shadow checks for Cedar Vale Stories and states that existing listener delivery will not change.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-0a48f23825438403b5d897f5e3c75841584ef90c%2Fdoc-monetization-055-start-shadow-confirmation.png?alt=media) *Shadow checks do not move listeners to the new delivery path.* ![The current One Podigee Integrations page shows Cedar Vale Stories in shadow mode, the existing delivery safety notice, the recheck control, and the safe-switch checklist.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-420a27a5d3c2ed105bfe4b6aad2788ec3863ea1c%2Fdoc-monetization-055-shadow-checks.png?alt=media) *Use shadow mode to prepare and verify delivery while the existing podcast stays live.* ## Create the migration project 1. Open **Monetization > Revenue jobs**. 2. Select **Migration and portability**. 3. Select **Start a migration**. 4. In **Current ad platform**, choose the source platform. 5. In **Migration export file**, select the prepared source export. 6. In **Areas to migrate**, select only the areas included in the approved scope. 7. Select the target workspace and the migration owner when the form asks for them. 8. Review the source snapshot, scope, acceptance profile, delivery mode, and rollback plan. 9. Select **Start migration**. Podigee freezes the source snapshot and records its digest before import. If the file is incomplete, changed, or outside the selected scope, the project remains blocked. ## Review the plan before import The migration project should show: * **Draft** or **Planned** state, not live delivery. * The current source platform and frozen export reference. * The target workspace and in-scope areas. * The source snapshot and mapping expectations. * Acceptance criteria and blocking findings. * A named migration owner and rollback owner. * The current delivery authority. Do not import records until the plan has a complete source snapshot and a clear stop condition. ## If the plan cannot be created * **The source export is missing:** create a complete export and include its source reference. * **The export changed:** upload the final file again and start a new frozen snapshot. * **A requested area is unsupported:** remove it from scope or document the provider boundary before you continue. * **The target workspace is unavailable:** correct the workspace and access before creating the project. * **The RSS or delivery authority is unclear:** stop and name one current authority before import. * **The acceptance criteria are incomplete:** add a measurable pass or stop rule for every delivery surface in scope. ## Expected result You have one migration project with a frozen source snapshot, explicit record scope, mapping and acceptance rules, named owners, a delivery mode, and a rollback boundary. The existing RSS and listener delivery remain unchanged until a later, separately approved cutover. ## Next useful tasks Next, import records and resolve mappings when the project has a valid frozen snapshot. Then run deterministic synthetic delivery checks before you request a cutover review. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.podigee.com/documentation/grow-and-monetize/monetization/plan-a-safe-migration.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.