Migrating to LYLIX from DigitalOcean, Linode, or Vultr

This article covers the practical mechanics of moving a working Linux VPS from a hyperscaler (DigitalOcean, Linode, Vultr) to LYLIX. Same pattern works for any source — the steps are hosting-agnostic, but the gotchas vary by where you're coming from. Plan a half day; many migrations finish faster.

The four phases

1. Provision the new LYLIX VPS to match your source.
2. Replicate data and config from old to new.
3. Switch DNS to the new IP and verify.
4. Decommission the old one.

Phase 1: Provision the new VPS

Order a Linux VPS in the LYLIX customer portal. Match (or exceed) your source's resource specs:

• vCPU count, RAM, disk to at least what you're using on the source.
• Same Linux distribution as the source if possible — Debian, AlmaLinux, or Ubuntu. Same major version where reasonable.

Within ~60 seconds your new VPS is up. SSH in and complete the basics from first hour with a LYLIX VPS:

• Update the system: apt update && apt full-upgrade (or dnf upgrade).
• Set up SSH key auth.
• Change the root password.

Don't install your applications yet — you'll replicate config from the source.

Phase 2: Replicate

The general strategy: rsync system state and application data from source to destination, install packages on destination to match what's on source.

2a. Inventory what's installed on the source

On the source VPS:

# Debian / Ubuntu:
dpkg --get-selections > /tmp/packages.list

# AlmaLinux / RHEL:
rpm -qa > /tmp/packages.list

Copy that file to your local machine, then to the destination:

# From your local machine:
scp source-user@source-IP:/tmp/packages.list .
scp packages.list root@new-LYLIX-IP:/tmp/

Re-install on the destination:

# Debian / Ubuntu (after copying packages.list to /tmp/):
dpkg --set-selections < /tmp/packages.list
apt-get -y dselect-upgrade

# AlmaLinux:
xargs -a /tmp/packages.list dnf install -y

2b. Snapshot databases on the source

If your VPS runs a database, dump it before rsync:

# MySQL / MariaDB on the SOURCE:
mysqldump --all-databases --single-transaction --routines --triggers \
    | gzip > /root/db-source.sql.gz

# PostgreSQL on the SOURCE:
sudo -u postgres pg_dumpall | gzip > /root/db-source.sql.gz

You'll restore from this on the destination after rsync.

2c. rsync /etc and application data

From your local machine (so you control the SSH session and neither end's connectivity ends the transfer):

rsync -aHAXx --numeric-ids --info=progress2 \
    --exclude '/etc/fstab' \
    --exclude '/etc/network' \
    --exclude '/etc/netplan' \
    --exclude '/etc/hosts' \
    --exclude '/etc/hostname' \
    --exclude '/etc/machine-id' \
    --exclude '/etc/ssh/ssh_host_*' \
    -e "ssh -A" \
    source-user@source-IP:/etc/ \
    /tmp/source-etc/

# Then push to destination:
rsync -aHAXx --numeric-ids --info=progress2 \
    /tmp/source-etc/ \
    root@new-LYLIX-IP:/etc/

Exclude list explained:

• /etc/fstab, /etc/network, /etc/netplan, /etc/hosts, /etc/hostname, /etc/machine-id: host-specific config. Copying these from source to destination breaks networking and the system identity.
• /etc/ssh/ssh_host_*: SSH host keys. If you copy them, your local SSH client won't warn on the host-key change — convenient but loses the security check. Up to you; usually safer to skip and let the destination keep its own host keys.

Then rsync your application data:

rsync -aHAXx --numeric-ids --info=progress2 -e "ssh -A" \
    source-user@source-IP:/srv/ \
    /tmp/srv/

rsync -aHAXx --numeric-ids --info=progress2 \
    /tmp/srv/ \
    root@new-LYLIX-IP:/srv/

# Same for /home, /var/www, or wherever your data lives.

2d. Copy and restore the database dump

# Copy the dump to destination:
scp source-user@source-IP:/root/db-source.sql.gz root@new-LYLIX-IP:/root/

# On destination:
gunzip -c /root/db-source.sql.gz | mysql      # MySQL/MariaDB
# or
sudo -u postgres psql < <(gunzip -c /root/db-source.sql.gz)   # PostgreSQL

2e. Apply config tweaks for the new host

Some config files reference the source IP — find and fix:

grep -r "<source-IP>" /etc /srv 2>/dev/null
# Edit each match to use the new IP, or use a hostname instead.

Common offenders: nginx vhost server_name, application config files, certbot configs (will need re-issuing on the new host), mail server config.

2f. Re-issue Let's Encrypt certs

Certs on the source aren't valid on the destination IP. Re-issue on the destination after DNS is pointing at it (next phase). Until then, services that need certs may fail to start — that's expected.

Phase 3: Switch DNS and verify

Once data is replicated and the destination is running services (at least starting), point DNS at the new LYLIX IP:

1. In your DNS provider, edit your A records:
   • Lower the TTL to 300 (5 minutes) at least 24 hours before the actual switch. This means when you do switch, propagation is fast.
   • At the switch time, change the IP to the LYLIX IP.
2. Verify propagation:

   dig +short yourdomain.com
   # Should return the new LYLIX IP within minutes.

3. Test from outside (your phone on cell data is a good external check).

Set up reverse DNS on the new IP

LYLIX portal → Reverse DNS tab → set PTR for the new IPv4 to match your hostname. See the PTR article. Required if you send mail.

Issue Let's Encrypt certs

Now that DNS points at the LYLIX IP:

certbot --nginx -d yourdomain.com -d www.yourdomain.com
# or whatever your existing certbot setup uses

See Let's Encrypt setup if certbot isn't installed yet.

Phase 4: Decommission the source

Wait at least a week before deleting the source VPS. DNS caches, old links, monitoring systems all need time to learn the new IP. During this overlap:

• Watch monitoring on both. Confirm new is healthy, source is idle.
• Watch source's access logs. If they're still receiving traffic, the DNS hasn't fully propagated or some clients are caching the old IP heavily.
• Watch your mail logs. Recipient servers cache MX/A records differently from web browsers; mail can take longer to flip.

When source has been idle for a week and you're confident nothing's still pointing at it, cancel the service with the source provider.

Hyperscaler-specific gotchas

DigitalOcean

• DigitalOcean's "snapshots" and "backups" don't help you on a different host. Export them yourself before cancellation if you want them.
• DigitalOcean Spaces (S3-compatible storage): your app may reference Spaces by URL; that keeps working from the new host without changes.
• Floating IPs and Reserved IPs don't transfer — they're DigitalOcean-internal.

Linode

• Linode Object Storage: same story as Spaces — keeps working from a different host.
• Linode-issued SSL certs (the StackScripts kind) don't move; re-issue with Let's Encrypt.
• If you have Linode Volumes (block storage), the data on them isn't included in their VPS images — sync separately.

Vultr

• Vultr's "VC2" instances vs. "High Performance" vs. "Cloud Compute" differ slightly in IO patterns. Your app may notice; benchmark on the new LYLIX VPS to verify.
• Vultr Block Storage doesn't transfer.
• Vultr Object Storage: works from anywhere.

If you'd rather LYLIX do the migration

For small VPSes the above process takes a couple of hours and most customers do it themselves. For larger / more complex migrations (multiple databases, custom kernel modules, complex firewall rules), we can quote a migration service — open a ticket with your source provider, current VPS specs, and what's running. Pricing depends on complexity; typical small-VPS migration runs $100-300.