How to Migrate a Service to Another Server on Sliplane

How a migration to another server plays out depends on your setup. In some cases, you can migrate a service with zero downtime. If that's not possible, plan ahead: inform your users and schedule the migration for a time when usage is low.

To minimize risk and downtime, try the migration in a staging environment first. If you migrate many services or do this regularly, you can also automate parts of the process with the Sliplane API.

Before you get started

This guide assumes you already have a target server to migrate your service to. If you don't, create a new server first. Keep in mind that a server is billed as soon as it exists, even if no services are deployed on it yet.

Next, identify the dependencies of the service you want to migrate:

• Shared volumes. If multiple services use the same volume, you might need to migrate them together.
• Services that talk to each other. The internal network is only reachable from services on the same server. If services communicate via internal hostnames (like servicexyz.internal), you might need to migrate them together. The order matters: start with the lowest service in the chain, for example the database first, then the backend, then the frontend.
• Services that reference the migrated service. Its public endpoint (the sliplane.app domain and exposed ports) and its internal hostname can change during the migration. Note down every service that connects to it, so you can update their config afterwards.
• IP allowlists. Your service gets the IP address of the new server. Look up the new server's IP in its settings and add it to any allowlists (databases, external APIs, firewalls) ahead of time.

Lower your DNS TTL (optional). If you use a custom domain, lower the TTL of its DNS records to the minimum (for example 60 seconds). This makes the domain switch at the end take effect within a minute instead of hours. Do this early, since resolvers keep caching your records for the old TTL. If it's currently 24 hours, lower it a day ahead.

How the migration works

The migration consists of three steps: move the data, move the service, then update your domains and DNS records.

Step 1: Move the data

If the service has volumes attached, the first step is to move all of them to the new server. If there's no volume attached, skip to Step 2. Moving the data takes three steps:

1. Pause the service. You can pause it in the service settings or in the three-dot menu next to the service in the project overview. This takes about 10 seconds. The service, its data and its config stay untouched. More on pausing services
2. Create a manual backup of each volume. Open the old server, go to the Volumes tab, open the volume's three-dot menu and click Create Backup. Depending on the volume size, this takes a few seconds to several minutes. You can create one manual backup per volume every 30 minutes. More on volume backups
3. Restore the backups on the new server. In the volume's backup list, click Restore next to the backup you just created and select the new server as the Target server. This creates a new volume with the backup's contents on the new server. You can follow the progress in the volume details. More on restoring backups

Restores to another server only work to current-generation servers. Legacy servers show up in the list, but are disabled.

Pausing the service is necessary for two reasons. First, it prevents data corruption: a database, for example, writes to several files at once. If the backup captures them mid-write, they don't match, and the restored database might not start or might contain broken data. Second, it prevents data loss: anything written after the backup stays on the old server and won't make it to the new one.

If the data in the volumes is read-only or rarely written to, you might not need to pause the service. You can then migrate while it keeps running to minimize downtime. But double-check this, because a running service can become a problem in the next step: once you deploy the copy, two instances of your service run at the same time. If both connect to the same external data source, for example, there's a risk of data corruption.

If a volume you're moving is attached to multiple services that write to it, pause all of them.

Step 2: Move the service

Deploy a new version of your service on the new server and attach the volumes you moved in Step 1.

The easiest way is Deploy copy: open the three-dot menu on the service card in the project overview and click Deploy copy. This copies the service's config and prefills the deploy form for you. Select the new server, check the config and deploy. More on Deploy copy

Things to watch out for:

• Secrets aren't copied. Deploy copy copies your env vars, except the ones marked as secret. Add those again manually.
• Select the restored volumes. Deploy copy doesn't know about the volumes you restored in Step 1. If it can't find the original volume on the new server, it creates a new, empty one by default. In the deploy form, replace these with the restored volumes from Step 1 and check the mount paths.
• Domains aren't copied. You move them in Step 3.
• Internal hostnames only work on the same server. After moving a service, you might have to migrate dependent services as well. Update all internal hostname references in their env vars.
• Avoid unintended upgrades with latest tags. A deploy always pulls the latest available image for a tag. If your service uses the latest tag, the copy might end up on a newer version than the original, including breaking changes. Pin the exact version you're currently running in the service settings first, so you deploy the same version on the new server.
• Two services running in parallel. If the original service is still running, two instances run at the same time. For some services this is a problem: if both connect to the same data source, for example, there's a risk of data corruption.
• Public endpoints change. The copy gets a new sliplane.app domain, and publicly exposed TCP/UDP ports change too. Update all references to your service.

Once the copy is deployed, test it on its sliplane.app domain before you switch any traffic.

Step 3: Update domains and DNS records

If you use custom domains, you can now switch them over. A domain can only be attached to one service at a time, so first remove it from the old service, then add it to the new one in the Domains tab. More on custom domains

Then update your DNS records to the values Sliplane shows:

• CNAME/ALIAS records: point them to the new xyz.sliplane.app domain.
• A/AAAA records: point them to the new server's IP addresses.

The SSL certificate is issued automatically once DNS points to the new server. If you lowered the TTL, the switch takes a minute or two. Afterwards, set the TTL back to its previous value.

Wrapping up

Your service now runs on the new server. Keep the old service paused for a day or two, so you can switch back if something goes wrong. Once everything works as expected, delete the old service. If the old server is empty now, delete it as well, since it's billed until you do.

Questions or stuck somewhere? Reach out at support@sliplane.io.