> 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/roll-back-a-migration.md). # Roll back a migration Return a podcast to its last verified delivery route when a migration is not safe to keep live. Podigee Audio Video Ad Server lets an authorized operator return a podcast to its last verified delivery route after a migration problem. The return is a controlled change for the selected scope. It does not change the RSS feed, episode identity, or published media address. Use this task when delivery evidence is unsafe, when the migration and commercial evidence do not agree, or when the migration owner requests a safe return. Do not use it to hide a reporting error. Keep the exact evidence so the cause can be corrected and reviewed. ## Before you start * You are the migration owner or have permission to restore the previous delivery route. * The migration project is **Failed**, **Podigee Ad Server active**, or **Post-cutover reconciling**. * The previous delivery route is still verified and marked as available for recovery. * You know the reason for the return and the podcast scope it must affect. * The required review is complete. If your workspace permits solo confirmation, use it only when the displayed rule allows it. * Someone is available to watch the first requests and evidence after the change. Do not start a return when the previous route is uncertain. A missing recovery check is a reason to stop and ask for operational help, not a reason to guess. ## Review the migration and recovery state 1. Open **Monetization > Revenue jobs**. 2. Select **Migration and portability**. 3. Open the migration project. 4. Confirm the project state and the podcast scope. 5. Review the current delivery route, the previous verified route, the migration result, and any blocking findings. 6. Check the last verification time and the recovery status. If the previous route is not verified, stop. If a late provider result, delivery error, or evidence disagreement is open, record it in the operational case before you continue. ![The current One Podigee Integrations page shows a live show with recovery verification still required before the return control becomes available.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-ac992861d771198c9c4ac80b118635f5faed9e5c%2Fdoc-monetization-055-active-verification-needed.png?alt=media) *A live show does not offer an unverified return action.* ## Start the return 1. Select **Restore the previous delivery route**. 2. In **Restore previous delivery at**, choose now or a planned time. 3. Select the reason that best describes the event: * **Delivery verification failed** * **Unexpected listener delivery behavior** * **Delivery and commercial evidence do not agree** * **Operator requested a safe return** 4. Review the exact podcast scope, previous route, current route, and effective time. 5. Complete the required review or confirmation for the workspace. 6. Select **Restore the previous delivery route**. Podigee binds the action to the selected migration project, the exact previous route, the effective time, the reason, and the review evidence. A planned time creates a scheduled return. It does not change delivery before that time. ## What happens at the return boundary At the effective time: * New listener and viewer requests use the last verified delivery route. * A presentation already assigned to a listener or viewer remains safe to finish. * The RSS feed URL and episode identity remain unchanged. * The return is recorded as a new delivery boundary. Earlier records stay unchanged. * Analytics keeps the route and boundary information needed to separate old and new requests. * Commercial evidence keeps the boundary needed to prevent duplicate delivery or duplicate billing. * Late events and provider responses remain available for reconciliation. They are not silently discarded. ![The current One Podigee Launch readiness page shows a paused delivery state with Resume delivery and Revoke publication controls.](https://2032417310-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FbqUKO6lljHGzkEAzliPI%2Fuploads%2Fgit-blob-5e8aacb2db51e95c321d566c032b0a879774ef3c%2Fdoc-monetization-061-live-delivery-paused.png?alt=media) *A paused or returned delivery remains visible until its recovery work is complete.* ## Verify the return When the operation completes, check: * The migration project shows **Rolled back** or **Post-rollback reconciling**. * The selected podcast scope uses the previous verified route. * The RSS feed and episode identity are unchanged. * A new audio request receives the expected route and media result. * A video or HLS request receives the expected route and media result when that format is in scope. * Decision, media, cache, event, analytics, and commercial records use one consistent boundary. * No duplicate impression, delivery, invoice line, or payout appears at the boundary. * Any late callback is linked to the correct delivery period and remains available for reconciliation. Keep the previous route live while the first evidence review is in progress. Do not delete the returned route, its records, or its evidence before the reconciliation period closes. ## If Podigee blocks the action * **The project state is not eligible:** resolve the migration state before you retry. * **The previous route is not verified:** run the recovery verification and review its result. * **The route has changed:** prepare a new exact recovery reference and repeat the review. * **The migration project changed:** open the current project and review it again. Do not reuse an old form. * **The review is missing or expired:** complete the required review again. * **The effective time is invalid:** choose a valid current or future boundary. * **A provider result is uncertain:** keep the current safe route live and open an operational case. ## Complete the recovery After the first delivery and finance evidence is available: 1. Open the migration project again. 2. Review the post-rollback reconciliation results. 3. Resolve each delivery, analytics, or commercial difference with an appended correction or an approved explanation. 4. Close the recovery only when totals agree or the remaining difference has an owner and a written decision. Do not edit a report to make totals agree. Keep the original evidence and add the correction or explanation as a new record. ## Expected result The selected podcast scope uses its last verified delivery route at one recorded boundary. Listener delivery remains safe, the RSS feed and episode identity remain stable, and delivery, analytics, and commercial evidence can be reconciled without duplicate billing. ## Next useful tasks Use [Authorize and execute cutover](/documentation/grow-and-monetize/monetization/authorize-and-execute-cutover.md) when the migration is ready to move to the new route again. Use [Reconstruct and export audit evidence](/documentation/grow-and-monetize/monetization/reconstruct-and-export-audit-evidence.md) when an incident requires a complete evidence package. --- # 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/roll-back-a-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.