Moving From TVU Go, TVU Anywhere, or IRL Toolkit to StreamableRun

# Moving From TVU Go, TVU Anywhere, or IRL Toolkit to StreamableRun A migration is not a declaration that the old stack was bad. It is a way to move one responsibility—often the cloud program, scenes, or destinations—without breaking the field contribution path that got the show this far. The safest version is a bake-off: run the new path privately beside the existing one, define what ‘ready’ means, and keep a rollback that does not require anyone to improvise in front of an audience. The naming needs care before anything else. TVU’s April 15, 2025 announcement called TVU Go a phone-first IRL app and described launch-era capabilities. TVU’s current IRL page is branded TVU Anywhere and directs users to IRL Toolkit hosted OBS. TVU One is separate hardware, and TVU Producer is another cloud-production surface. Do not begin a migration by saying ‘we are leaving TVU’ when the team may only be changing a destination-control or Cloud OBS layer. Identify the exact product, account, and job first. This is a producer-style runbook, not a claim of personal hands-on testing. Use it to design your own private bake-off with the people, devices, and locations that matter to your show. ## Phase 1: Make an inventory nobody can argue with Open a blank document and list the show as it exists today. Include the field sender: phone app, TVU mobile workflow, backpack, encoder, or local OBS. Include every ingest and protocol, but never paste stream keys into a shared runbook. Include all scenes, browser sources, clips, remote guests, microphones, camera accessories, destination accounts, moderators, and people with permissions. Next to every item, write its job. A TVU contribution path may be responsible for getting the field video through difficult connectivity. IRL Toolkit or another hosted OBS layer may own scenes and destinations. A phone may only be a camera. A desktop may be the opening and backup. This inventory is where teams discover that a supposed migration would also remove a working bonding layer, or that the thing they actually want is a cleaner control panel for a remote producer. Mark three categories: **keep for the first bake-off**, **replace in the test**, and **retire only after approval**. Keeping a proven sender during the first test is not indecision. It is good change control. ## Phase 2: Decide what the StreamableRun path must prove Write observable acceptance criteria. ‘Feels more reliable’ is not useful. ‘The producer can switch between desktop and phone without the public destination ending’ is useful. ‘A backup phone arrives in its own ingest and can be previewed before it is taken’ is useful. ‘A problem at one destination can be investigated without stopping the others’ is useful. ‘The holding scene has no live field audio’ is useful. For most migrations, StreamableRun should prove its cloud-production role: Cloud Hosted OBS can hold the program, separate sources can arrive as ingests, a producer can operate scenes remotely, fallback content is ready, and destinations are managed from the cloud path. It should not be asked to prove cellular bonding. If TVU’s ISX or another bonded contribution method is the part that works at difficult venues, leave it upstream for the test. Set a stop condition too. If the tested source cannot arrive in a supported, stable way; if the producer cannot operate the needed scenes; if the destination checks fail; or if the team cannot explain a rollback in one sentence, the bake-off is not ready for public use. Stop, document, and fix the failure. ## Phase 3: Build a parallel, private program Create a separate StreamableRun workspace or isolated configuration appropriate to your team’s account setup. Do not point it at the public stream first. Create named ingests for desktop, main field source, and backup. Build only the scenes needed for the test: a desk scene, a field scene, a safe holding scene, a fallback clips scene if appropriate, a privacy scene, and a return scene. Use private, unlisted, or otherwise non-public destination tests where the platforms allow them. Connect only credentials the responsible destination owner is authorised to use. Store stream keys in the approved platform or password-management workflow; do not put them in chat, screenshots, article drafts, or a shared note that travels with the phone. Remove access promptly from a temporary device or contractor after the test. Before adding overlays, prove the underlying signal path. Send the existing TVU contribution, phone app, local OBS, or encoder to the test ingest. Confirm current video, correct audio, expected orientation, and a sensible delay. Watch the destination as a viewer would, on a separate device. A healthy source tile is not the finish line. ## Phase 4: Test compatibility without guessing Check the specific output protocol, codec, resolution, and audio configuration of the sender and the StreamableRun ingest. A sender that worked with one hosted service does not automatically work with another until the complete route is tested. If you are using a TVU product, verify the current supported handoff and account capabilities with TVU; product names and plans change. If you are using SRT, RTMP, or another transport, test the actual mode and endpoint rather than relying on a generic protocol label. Then test the boring peripherals. Does the field phone select the external microphone after a reconnect? Does the camera orientation stay as planned? Does a charger or battery bank introduce audio noise? Does a desktop browser source need a new login? Does the producer have only the controls they need, rather than a shared owner account? A migration that passes video but exposes credentials or loses sound is not ready. ## Phase 5: Rehearse the desktop-to-phone handoff Start the private program with desktop OBS as the active source. Bring the field source into preview in StreamableRun before the host leaves the desk. Confirm the phone’s lens, microphone, battery, and picture. The producer takes a short transition or a desk-safe holding scene, confirms the field source is current and intelligible, then takes the field scene. The public test destination should receive one continuing cloud program while the source changes. Reverse the move too. Bring desktop back to preview before the host returns. Check browser sources, local audio, and any desktop-specific graphics. Take a transition, then return to desk only after the desktop source is clean. This is where an otherwise good migration can fail: everyone practices the exciting walk out and nobody notices that the desktop machine displays a private tab after the return. TVU’s 2025 TVU Go launch material described a desktop-to-phone handoff. That may remain a valid reason to use a current TVU workflow. The purpose of this bake-off is not to deny it; it is to compare whether a persistent StreamableRun cloud program gives your team more useful source, scene, and destination control for the same show. ## Phase 6: Break the source on purpose With the field source live in the private program, remove it deliberately. Do not just tap a pause button; simulate the failure your show is likely to have: loss of data, app restart, bad audio, or a source that returns with the wrong orientation. Let the field contribution path attempt its recovery. Meanwhile, the producer takes the holding or Clips Player scene, confirms that private audio is muted, and checks the public destination. When the source returns, it should go to preview first. Confirm it is fresh video, safe location, correct mic, and usable framing. Return it to program only after those checks. This is the exact place where a cloud program earns its cost: a sender can reconnect without forcing the audience to stare at whatever frame came back first. Repeat with the backup ingest. Make sure it is genuinely different enough to be useful. A second phone on the same carrier and same battery pack may be a helpful spare, but it does not remove the primary failure point. ## Phase 7: Test destinations one at a time Each destination needs its own check: title, category, privacy, audio, video format, latency expectation, and public playback. Test a destination-specific interruption without restarting every output. The desired outcome is not that every platform behaves identically. It is that the producer and destination owner know what one platform’s problem looks like and can contain it. If the show includes a vertical output, test it on a real phone. Confirm the composition is a vertical show rather than a narrow crop of the landscape program. Check that lower thirds remain readable and that a holding scene also works in portrait. Do not claim a multistream workflow is complete because keys are connected. ## Phase 8: Decide whether to migrate, hybridize, or stop Move the cloud production and destination work to StreamableRun when the private bake-off meets the written criteria, the team can operate the control panel, the scenes behave correctly, and the rollback is rehearsed. Run a low-stakes public show first if the schedule allows; keep the old path available until the new one has survived normal use. Choose a hybrid when TVU contribution is still the best tested answer to the field-link problem while StreamableRun is the better answer to cloud scenes, multiple ingests, remote control, vertical output, or destination management. This is often the most honest design. A field sender and a cloud program have different jobs; replacing one just to reduce a vendor count can create risk without helping viewers. Stop the migration when the new path does not provide a clear operational improvement, a compatibility issue remains unresolved, or the crew cannot support the added complexity. There is no embarrassment in keeping a stable existing workflow and trying again after a better rehearsal. The failure is publishing a change because a feature grid looked persuasive. ## Rollback criteria and credential closeout Write the rollback trigger before the public change. Examples: main source cannot be previewed cleanly; holding scene leaks audio; a required destination fails its private check; desktop-to-phone handoff cannot be completed without ending the test broadcast; or the producer cannot take a backup source inside the agreed time. When a trigger occurs, return to the previous known-good program and log the symptom. After the bake-off, remove temporary destinations, revoke or rotate any credentials that were exposed or unnecessarily shared, remove test devices from platform access where appropriate, and update the runbook with the actual approved workflow. Credentials are part of production reliability. A perfect stream is not a success if access has been handled carelessly. ## Sources

• [TVU Go launch announcement, April 15, 2025](https://www.tvunetworks.com/story/tvu-go-irl-streaming-app-launch/) — historical TVU Go terminology, mobile workflow, and handoff claims.
• [TVU Anywhere IRL app page](https://www.tvunetworks.com/irl-streaming-app/) — current public TVU Anywhere branding, ISX positioning, and IRL Toolkit setup path, accessed September 3, 2026.
• [TVU Anywhere product page](https://www.tvunetworks.com/products/tvu-anywhere/) — current public mobile-contribution context.
• [StreamableRun live demo](https://streamable.run/blog/streamable-live-demo-video-cloud-hosted-obs) — public Cloud Hosted OBS, remote control, Clips Player, drop-protection, and multi-ingest workflow context.