Splashtop On-Prem Gateway Server Migration

Overview

This article describes the standard procedure for migrating a Splashtop On-Prem Gateway from one server to another. The migration transfers all configuration, user data, and Streamer registrations to the new Gateway server with minimal downtime.

There are two connectivity methods for Streamer-to-Gateway communication: FQDN-based and IP address-based. The method your environment uses determines the migration steps required. We strongly recommend the FQDN-based approach, as it greatly simplifies the migration process.

Prerequisites

Version Compatibility

Before proceeding, verify that the Gateway versions are compatible:

  • Migration from a lower version to a higher version: Supported.
  • Migration between identical versions: Supported.
  • Migration from a higher version to a lower version: Not supported. The database schema of a newer version is not backward-compatible with older versions.
Important: Always ensure the destination Gateway version is equal to or higher than the source. Migrating to a lower version will result in database errors and is not supported.

 

Downloads

Download the Splashtop Gateway installer from the official downloads page:

Splashtop On-Prem Downloads

Backup & Restore Reference

For detailed backup and restore instructions, refer to:

System Backup and Restore Guide

 

Method A: FQDN-Based Migration (Recommended)

If your Streamers connect to the Gateway using a Fully Qualified Domain Name (e.g., gateway.company.com), this is the recommended migration path. After migration, you simply update the DNS record to point to the new server, and all Streamers will reconnect automatically—no Streamer re-deployment required.

Recommended: FQDN-based connectivity is strongly recommended for production deployments, as it allows seamless server migrations, failovers, and IP changes without touching individual Streamers.

 

Procedure

Step 1. Back Up the Old Gateway

While the old Gateway is still running normally, create a full backup. This captures all configuration—including the original production port—along with user data and Streamer registrations. Transfer the backup file to the new server for use in Step 3.

Step 2. Change the Listening Port on the Old Gateway

On the old (source) Gateway, change the listening port to a non-standard value (e.g., from 443 to 9443). This will disconnect all online Streamers without deleting their registrations. The Streamers will enter a connection retry loop and automatically reconnect once they can reach the Gateway again.

Do not delete Streamers from the old Gateway. The port change is only intended to gracefully disconnect active sessions while you complete the remaining migration steps.

Step 3. Install the Gateway on the New Server and Restore During OOBE

Install the same or higher version of the Splashtop Gateway on the new server. During the Out-of-Box Experience (OOBE) setup, select the option to restore from an existing backup and provide the backup file created in Step 1. The Gateway will import all configuration, user data, and Streamer registrations as part of the initial setup. Since the backup was taken before the port change, the new Gateway will already have the correct production port configured—no manual port adjustment is needed.

Step 4. Update DNS to Point to the New Server

In your DNS server, update the FQDN record (e.g., gateway.company.com) to resolve to the new server’s IP address. Once DNS propagates, Streamers will begin reconnecting to the new Gateway gradually.

Step 5. Verify Streamer Reconnection

Allow several minutes for all Streamers to reconnect. Monitor the new Gateway’s management console to confirm that Streamers are appearing online. The reconnection time depends on DNS TTL settings and the number of deployed Streamers.

 

Method B: IP Address-Based Migration

If your Streamers connect to the Gateway using a static IP address (without FQDN), the migration requires additional steps. Because Streamers are registered to a specific IP address, they cannot automatically discover the new server at a different IP.

Important: In an IP address-based deployment, all existing Streamers must be deleted from the old Gateway and re-deployed to the new Gateway. For environments with a large number of Streamers, this can be a significant operational effort. Consider migrating to an FQDN-based setup to avoid this overhead in the future.

 

Procedure

Step 1. Back Up the Old Gateway

Create a full backup of the old Gateway server while it is still running. Transfer the backup file to the new server for use in the next step.

Step 2. Install the Gateway on the New Server and Restore During OOBE

Install the same or higher version of the Splashtop Gateway on the new server. During the Out-of-Box Experience (OOBE) setup, select the option to restore from an existing backup and provide the backup file created in Step 1. The Gateway will import all configuration, user data, and Streamer registrations as part of the initial setup.

Step 3. Delete Streamers from the Old Gateway

Remove all Streamer registrations from the old Gateway. This is necessary because the Streamers were deployed with the old server’s IP address and will not connect to the new IP automatically.

Step 4. Assign the IP Address to the New Server

Assign the appropriate IP address to the new server. If you are able to re-use the same IP address, some Streamers may reconnect; however, a clean re-deployment is recommended for consistency.

Step 5. Re-deploy Streamers

Deploy Streamers to all target endpoints, pointing them to the new Gateway server’s IP address.

Step 6. Verify Streamer Reconnection

Confirm that all Streamers appear online in the new Gateway’s management console.

 

Comparison: FQDN vs. IP Address Migration

Aspect FQDN (Recommended) IP Address
Streamer re-deployment Not required Required for all Streamers
Downtime Minimal (DNS propagation) Extended (re-deployment time)
Operational effort Low High (scales with Streamer count)
DNS update required Yes No
IP address can change Yes Must be reassigned or kept

 

Troubleshooting

  • Streamers not reconnecting after DNS change: Verify the DNS TTL and confirm the FQDN resolves to the new server’s IP (e.g., using nslookup or dig). Streamers may take several minutes to retry.
  • Database restore fails: Confirm the new Gateway version is equal to or higher than the old Gateway. Restoring a backup from a newer version onto an older version is not supported.

 

0 out of 0 found this helpful