Migrating a live streaming server to a new VPS without downtime means running both servers in parallel — encoder pushes to both, viewers stay on the old origin — until the new one is verified, then cutting traffic over via DNS or a load balancer while the old server stays live as a rollback target. Done this way, viewers see no outage and encoders never lose their connection. The two failure modes to avoid are cutting over blind (no parallel verification) and cutting over all at once (no gradual traffic shift).
We’ve walked customers through dozens of these migrations at StreamingVPS.com — usually triggered by a plan upgrade, a move to a different data center region, or a hardware refresh. The steps below are the same checklist we use internally when we move a customer’s Wowza, NGINX-RTMP, or Ant Media instance to new hardware.
Key Takeaways
- Run the old and new streaming servers in parallel (dual-push from the encoder) before switching any viewer traffic — never migrate by taking the old server offline first.
- Lower DNS TTL to 60-300 seconds 24-48 hours before the cutover so the switch propagates in minutes instead of hours.
- Copy application configs, stream keys, SSL certificates, and recording/VOD storage separately — each has different sync requirements and failure risks.
- Cut viewer traffic over gradually (DNS weighting, CDN origin swap, or load balancer) rather than in one instant flip, and watch error rates for 15-30 minutes before finishing.
- Keep the old VPS running for 48-72 hours post-cutover as a rollback target before decommissioning it.
Why Would You Need to Migrate a Streaming Server at All?
The three most common triggers we see: a plan or hardware upgrade (moving from a 4 vCPU / 8 GB instance to a 16 vCPU / 32 GB instance ahead of a bigger event), a data center region change (moving closer to your audience to cut RTMP/SRT latency), and provider consolidation (bringing a self-managed engine under a managed, pre-installed setup). Each has slightly different urgency — a planned capacity upgrade gives you days to prepare, while a hardware failure notice from your host might give you 24-48 hours.
How Do You Migrate a Streaming Server With Zero Downtime?
The core technique is dual-push: your encoder (OBS, vMix, a hardware encoder, or an upstream restreaming service) pushes the same RTMP/SRT feed to both the old and new server simultaneously, using a second output profile pointed at the new VPS’s IP or a staging hostname. In OBS this is the built-in “multiple outputs” or a plugin like the RTMP output filter; in FFmpeg, tee handles it natively:
ffmpeg -i rtmp://source/live/stream \
-c copy -f flv "rtmp://OLD_VPS_IP/live/streamkey" \
-c copy -f flv "rtmp://NEW_VPS_IP/live/streamkey"While both servers receive the live feed, viewers stay pointed at the old server. You verify the new server independently — check bitrate stability, dropped-frame count, and HLS segment generation on the new box — before touching any viewer-facing DNS or load balancer config. This is the same pattern we cover in our failover setup guide; a migration is essentially a one-time, planned version of a failover cutover.
What Needs to Be Copied Before Cutover?
Four categories, each with a different sync approach:
Engine configuration. For Wowza, this is everything under /usr/local/WowzaStreamingEngine/conf/ — application definitions, stream targets, transcoder templates. For NGINX-RTMP, it’s your nginx.conf rtmp {} block plus any HLS/DASH output paths. For Ant Media, export the application settings via the REST API or copy /usr/local/antmedia/webapps/<app>/WEB-INF/red5-web.xml. Diff the config after copying — don’t just trust a straight copy, since IP-bound settings (bind addresses, allowed-origin lists) usually need editing for the new host.
SSL certificates. If you’re on Let’s Encrypt, don’t copy the certificate files directly — reissue on the new VPS once DNS points there, or use a DNS-01 challenge if you need the cert ready before cutover. Copying an existing cert to a new host works but creates a renewal headache later if the old host’s ACME client keeps trying to renew it.
Stream keys and access control. Copy your stream key list, any token-auth secrets (see our DRM and token auth guide), and IP allowlists. Test that a stream key that works on the old server also authenticates on the new one before cutover.
VOD and recording storage. This is usually the slowest part. Use rsync with --progress for an initial bulk copy days ahead of the cutover, then a final delta sync in the hours before: rsync -avz --progress /var/www/recordings/ user@NEW_VPS:/var/www/recordings/. For large VOD libraries (100 GB+), budget real transfer time — on a 1 Gbps link between data centers we’ve seen roughly 300-400 GB/hour sustained, well below the theoretical line rate once storage I/O becomes the bottleneck.
How Should the Actual Traffic Cutover Happen?
Three approaches, in order of how much control they give you:
| Cutover method | Downtime risk | Rollback speed | Best for |
|---|---|---|---|
| DNS A-record swap | Low, if TTL pre-lowered | Minutes (re-point DNS) | Most single-origin setups |
| CDN origin swap | Very low | Seconds (dashboard toggle) | Sites already behind a CDN |
| Load balancer weighted shift | Lowest | Instant (adjust weights) | High-traffic events, gradual rollout |
For most of our customers without a load balancer in front of their origin, a DNS A-record swap with a pre-lowered TTL is the practical choice. Drop the TTL to 60-300 seconds at least 24-48 hours ahead so the old, longer TTL has already expired everywhere. At cutover, update the A record to the new VPS’s IP, then watch both servers: the old one for a trailing tail of clients still resolving the old IP, the new one for the growing majority. Once error rates and player buffering stay flat for 15-30 minutes, you’re done. If you’re behind a CDN (see our CDN guide), an origin swap in the CDN dashboard is faster and avoids TTL waiting entirely.
What Commonly Goes Wrong During a Migration?
The failures we see most often aren’t exotic — they’re checklist gaps. A firewall rule that was opened manually on the old VPS (see our firewall ports guide for the full RTMP/HLS/SRT/WebRTC port list) but never added to the new server’s provisioning script, causing streams to connect but playback to silently fail. A hardcoded IP address in a player embed or mobile app config that bypasses DNS entirely and keeps hitting the old server after cutover. Recording jobs that were mid-write during the storage sync, producing a truncated file that only surfaces when someone tries to play back that VOD weeks later. And forgetting that scheduled/recurring streams (a nightly show, a cron-triggered restream) need their scheduler migrated too, not just the live engine.
Migration Checklist
- Provision and fully configure the new VPS (engine installed, firewall ports open, SSL ready or reissue plan in place).
- Lower DNS TTL 24-48 hours ahead of the planned cutover.
- Sync VOD/recording storage with an initial bulk rsync, days ahead.
- Copy and adapt engine configuration, stream keys, and access control.
- Start dual-push from the encoder to both servers.
- Verify the new server independently: bitrate, dropped frames, HLS/DASH output, playback in a real player.
- Run a final delta storage sync.
- Cut viewer traffic over (DNS, CDN origin, or load balancer), gradually if possible.
- Monitor both servers for 15-30 minutes; roll back by reverting DNS/CDN if error rates spike.
- Keep the old VPS live for 48-72 hours as a rollback target before decommissioning.
FAQ
Can I migrate a live streaming server without any downtime at all?
Yes, if you run the old and new servers in parallel (dual-push) during the cutover window and switch viewers over via DNS or a load balancer once the new server is verified healthy. A brief single-digit-second glitch is possible during player reconnects, but a full outage is avoidable.
How long should I keep the old VPS running after migration?
Keep the old VPS running for at least 48-72 hours after cutover as a rollback target, and don’t cancel or reformat it until DNS TTL has fully expired everywhere and you’ve confirmed a full stream cycle, including any scheduled peak traffic, on the new VPS.
Do I need to change my stream key when migrating servers?
No, you can keep the same stream key if you copy the application and stream-key configuration files from the old server to the new one, but rotating the key during migration is a good opportunity to invalidate any leaked or shared keys.
What DNS TTL should I set before a streaming server migration?
Lower your DNS TTL to 60-300 seconds at least 24-48 hours before the migration so the change propagates quickly, then raise it back to a normal value like 3600 seconds once the cutover is confirmed stable.
Will viewers notice anything during a well-planned migration?
With dual-push and a gradual DNS or CDN-level cutover, most viewers see no interruption; at worst, a small percentage may experience a single player rebuffer of a few seconds as their session picks up the new origin.
Conclusion
A zero-downtime streaming server migration comes down to sequencing: parallel verification before any traffic moves, a gradual cutover instead of a single flip, and a rollback window you actually keep open. Skip any one of those three and you’re gambling on a live event.
If you’d rather skip the manual config copying entirely, StreamingVPS.com’s pre-installed streaming engines come live in 60 seconds with Wowza, NGINX-RTMP, Ant Media, Red5, Flusonic, or MistServer ready to go — our team can also handle the migration itself as part of onboarding. Check current plans or talk to us about migrating your existing setup with zero downtime.
