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 move a service over with zero downtime. If that's not possible for your service, it helps to plan ahead: let your users know about the migration and pick a time when usage is low.

To keep risk and downtime to a minimum, it's a good idea to try the migration in a staging environment first. And if you migrate many services or do this regularly, you can automate parts of the process with the Sliplane API.

Before you get started

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

It's also worth taking a moment to map out the dependencies of the service you want to migrate:

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

Lower your DNS TTL (optional). If you use a custom domain, you can lower the TTL of its DNS records to the minimum (for example 60 seconds). That way, the domain switch at the end takes effect within a minute instead of hours. Since resolvers keep caching your records for the old TTL, it's best to do this early. If your TTL is currently 24 hours, lower it a day ahead.

How the migration works

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

Step 1: Move the data

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

1. Pause the service in the service settings or via the three-dot menu in the project overview. If a volume is attached to multiple services that write to it, pause all of them. More on pausing services
2. Create a manual backup of each volume via Create Backup in the volume's three-dot menu on the old server. Depending on the volume size, this takes a few seconds to several minutes. More on volume backups
3. Restore the backups on the new server by clicking Restore next to the backup and selecting the new server as the Target server. Once the restore has finished, you'll find a new volume with the backup's contents on the new server. 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 important 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 anymore, and the restored database might not start or might contain broken data. Second, it prevents data loss, because anything written after the backup stays on the old server and won't make it to the new one.

If the data in your volumes is read-only or rarely written to, you might not need to pause the service at all. In that case, you can migrate while it keeps running and keep downtime to a minimum. It's worth double-checking this, though, 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.

Step 2: Move the service

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

The easiest way to do this is Deploy copy. You'll find it in the three-dot menu on the service card in the project overview. It copies the service's config and prefills the deploy form for you, so all that's left is to select the new server, check the config and deploy. More on Deploy copy

There are a few things to watch out for:

• Secrets aren't copied. Deploy copy takes over your env vars, except the ones marked as secret. You'll need to 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'll 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 and update their internal hostname references.
• Avoid unintended upgrades with latest tags. A deploy always pulls the newest image available 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. To be safe, pin the exact version you're currently running in the service settings first, so the new server gets the same version.
• 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. Make sure to update all references to your service.

Step 3: Update domains and DNS records

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

After that, 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 beforehand, the switch takes just a minute or two. Afterwards, you can set the TTL back to its previous value.

Wrapping up

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