Migrate DigitalOcean to Vultr VPS: Complete 2026 Guide

This post contains affiliate links. If you purchase through our links, we may earn a commission at no extra cost to you.

You’ve already decided to migrate from DigitalOcean to Vultr – so this guide skips the “which is better?” debate and goes straight to the how. The migration process isn’t complicated, but it has a few specific failure points (DNS propagation, configuration drift, database cutover timing) that catch people out. Do it right and you’ll be fully moved in a weekend with zero data loss.

Why Migrate: Pricing and Performance at a Glance

If you want one reason to switch: at $24/month, Vultr gives you 2 vCPU / 4 GB RAM / 100 GB NVMe / 5 TB transfer. DigitalOcean’s equivalent Basic Droplet gets you 2 vCPU / 4 GB RAM / 80 GB SSD / 4 TB transfer – same price, less storage, slower disk, less bandwidth.

The performance gap is wider than the specs suggest. In Geekbench 6 single-core benchmarks (March 2026), Vultr’s AMD EPYC-Genoa scored 1,926 vs DigitalOcean’s 772 – 149% faster on CPU workloads. Disk I/O tells a similar story: Vultr’s NVMe storage hits ~118,400 IOPS vs DigitalOcean’s ~54,200. If you’re running anything database-heavy (WordPress, Laravel, Django), you’ll feel this.

Prices last verified: 2026-06-29

One honest caveat before diving into the migration: DigitalOcean scores higher on consistency (69 vs Vultr’s 61 on VPS Benchmarks). If you’re running multi-instance production loads where predictability matters more than peak performance, that’s worth factoring in. For most single-instance setups, Vultr’s raw performance advantage wins. our full Vultr vs DigitalOcean comparison covers this in depth if you want the complete picture.

Three Migration Methods (Choose One Before Starting)

Vultr documents three approaches. Pick yours before doing anything else – they’re not interchangeable mid-way through.

Method 1: Fresh install + rsync (recommended for most users) Spin up a clean Vultr instance, reinstall your software stack, then transfer data with rsync. Vultr’s own docs explicitly recommend this: “If you are migrating the system yourself and can tolerate some downtime, this is the recommended option.” Supported by Vultr’s support team.

Method 2: Snapshot/image migration (not recommended) Take a raw disk image of your Droplet and upload it to Vultr as a snapshot. Vultr’s docs warn against it: “This strategy is not generally recommended because many low-level configuration items can vary between cloud providers.” If something breaks, Vultr support won’t help. Requires x86-64, UEFI (no MBR), VirtIO drivers, and a disk under 150 GB. Only use this if reinstalling your stack is genuinely impractical.

Method 3: Live migration via partner Zero-downtime replication through Rackware or Siatik. Appropriate for production systems that can’t afford any downtime. Adds cost and coordination overhead – skip it unless downtime is truly unacceptable.

This guide covers Method 1 in full, with separate sections for block storage, databases, and object storage.

Step 1: Pre-Migration Prep (Do This First)

Before touching either server:

1. Inventory your Droplet: OS version, installed packages (dpkg -l or rpm -qa), open ports (ss -tlnp), environment variables, SSL certificates, cron jobs (crontab -l).
2. Take a DigitalOcean snapshot: Go to your Droplet ? Snapshots ? Take Snapshot. This is your safety net, not your migration method.
3. Lower DNS TTL: Set your A/AAAA records to 300 seconds (5 minutes) – do this 48 hours before your planned cutover. If your current TTL is 3600, clients will cache the old IP for up to an hour post-switch. Lowering TTL early kills that problem.
4. Confirm rsync is installed: which rsync on both servers. If missing: sudo apt install rsync.

Step 2: Deploy Your Vultr Instance

Sign up for Vultr with the $300 free credit promo link (new accounts get $300 valid for 30 days – enough to run your migration in parallel without paying twice). Deploy a Cloud Compute instance:

💡 Tip: Not sure about the cron syntax? Our free Cron Expression Builder lets you set the schedule visually and previews the next five runs.

• Region: Pick the one closest to your users, or match your current DigitalOcean region if latency consistency matters.
• Plan: High Performance (NVMe) is worth the small premium over Regular if you’re running anything disk-intensive. For a like-for-like migration, match your current Droplet size or go one tier up.
• OS: Match your Droplet’s OS version exactly. If you’re on Ubuntu 22.04, deploy Ubuntu 22.04 on Vultr – don’t use the migration as an excuse to upgrade the OS at the same time. One change at a time.

Once the instance is live, install your software stack fresh. Use Vultr’s Marketplace for pre-built stacks (LAMP, LEMP, Node.js) if you want to save setup time. For WordPress specifically, our Vultr WordPress setup guide walks through the full process.

Step 3: Transfer Data with rsync

From your DigitalOcean source server, run:

rsync -avz --progress /path/to/source/ vultr-user@VULTR_IP:/path/to/destination/

Flag breakdown:

• -a: Archive mode – preserves permissions, timestamps, symlinks
• -v: Verbose output so you can see what’s happening
• -z: Compress data in transit (matters on slow connections)
• --progress: Per-file progress display

For a WordPress site, that’s typically:

rsync -avz --progress /var/www/html/ vultr-user@VULTR_IP:/var/www/html/

Verify the transfer before touching DNS:

# On DigitalOcean (source)
sudo find /var/www/html -type f -exec md5sum {} \; > source-checksums.txt

# On Vultr (destination)
find /var/www/html -type f -exec md5sum {} \; > destination-checksums.txt

# Copy source checksums to Vultr, then compare
diff -y --suppress-common-lines source-checksums.txt destination-checksums.txt

Zero differences means a clean transfer. Any differences need investigating before you proceed.

Step 4: Block Storage Migration (Skip If You Don’t Use It)

If your Droplet has DigitalOcean Block Storage volumes attached, migrate those separately.

On DigitalOcean (source):

lsblk                          # identify the block storage device
sudo mkdir -p /mnt/source
sudo mount /dev/sda /mnt/source
df -h                          # confirm it's mounted and check usage

On Vultr (destination) – attach a Vultr Block Storage volume equal or larger than source, then:

lsblk                          # typically shows as /dev/vdb
sudo mkfs.ext4 /dev/vdb
sudo mkdir /mnt/destination
sudo mount /dev/vdb /mnt/destination
sudo chown -R linuxuser:linuxuser /mnt/destination

Transfer:

rsync -avz --progress /mnt/source/ linuxuser@VULTR_IP:/mnt/destination/

Both volumes should be in the same region for best transfer performance. Once verified, add the Vultr volume to /etc/fstab so it mounts on reboot.

Step 5: Database Migration

MySQL / MariaDB

Simplest path – mysqldump:

# Export from DigitalOcean Managed MySQL (port 25060)
mysqldump --host=DO_HOSTNAME --port=25060 --user=doadmin --password=YOUR_PASS \
  --all-databases > migration.sql

# Import to Vultr Managed Database (port 16751)
mysql --host=VULTR_HOSTNAME --port=16751 --user=vultradmin \
  --password=YOUR_PASS < migration.sql

If you’re migrating to Vultr’s managed database, there’s also a live migration option directly in the Vultr console: go to your cluster’s Migration tab, enter your DigitalOcean credentials with SSL enabled, test the connection, and click “Begin migration.” It handles live replication until you’re ready to detach. Vultr’s managed database review covers what you get on the Vultr side.

After migration: update your application’s database connection strings and restart the app before touching DNS. Confirm data consistency with a row count check on critical tables.

PostgreSQL

Same approach – pg_dump for export, pg_restore or psql for import. Match the PostgreSQL major version between source and destination to avoid compatibility issues.

Step 6: Object Storage Migration (DigitalOcean Spaces ? Vultr Object Storage)

Uses Rclone – the cleanest tool for S3-compatible bucket-to-bucket transfers.

# Install Rclone on either server
sudo apt update
wget -O rclone.sh https://rclone.org/install.sh
sudo bash rclone.sh

Configure ~/.config/rclone/rclone.conf with two blocks – one for DigitalOcean Spaces ([dg]) and one for Vultr Object Storage ([vultr]). Both are S3-compatible, so the config is nearly identical except for the endpoint URL.

# List your source buckets
rclone lsd dg:

# Sync all buckets (this runs until complete - use screen or tmux for large datasets)
rclone sync dg: vultr: --progress

# Verify integrity - should output "0 differences found"
rclone check dg: vultr:

After verification, update your application config to point to Vultr’s endpoints, then delete the DigitalOcean Spaces to stop being billed for them.

Step 7: DNS Cutover

This is where most migrations go wrong – not technically, but in timing.

Before cutover:

• Confirm your DNS TTL is already at 300 seconds (you set this in Step 1)
• Run a final rsync to pick up any files changed since your initial transfer
• Test everything on the Vultr instance directly via IP: web server, SSL, database connections, any external API calls

Cutover:

• Update your A/AAAA records (root domain and www) to the Vultr instance IP
• Do this during your lowest-traffic window
• Note the exact time – you’ll use this to judge when propagation is complete

After cutover (keep the Droplet running 48-72 hours): Some clients will still have the old IP cached. Kill the Droplet now and they’ll hit a dead server. Keep it running and monitor it:

# On the DigitalOcean Droplet - watch for incoming connections
netstat -an | grep :80
netstat -an | grep :443

Once incoming traffic on the old Droplet drops to zero, you’re clear. Take a final snapshot as a backup, then destroy the Droplet to stop billing.

Post-Migration Checklist

Run through this before declaring the migration complete:

• ☐ Application connects to Vultr database (not old DigitalOcean database)
• ☐ SSL certificates active and auto-renewing on Vultr (test with certbot renew --dry-run)
• ☐ Firewall rules configured on Vultr (use Firewall Groups – you can reuse them across instances)
• ☐ Monitoring/alerting tools (Uptime Robot, Datadog, etc.) pointed at the new IP
• ☐ Configuration management tools (Terraform, Ansible) updated with new instance IPs
• ☐ Object storage endpoints updated in all app configs
• ☐ Cron jobs running on Vultr (check crontab -l matches what was on the Droplet)
• ☐ DigitalOcean invoices reviewed – destroy all unused Droplets, volumes, and Spaces to stop billing
• ☐ Vultr Firewall Group configured (equivalent to DigitalOcean’s Cloud Firewall)

The DNS TTL step is the one that most often bites people who rush this migration. Lower the TTL early, wait a full 48 hours before cutting over, and the rest is straightforward.

Pricing Comparison: What You’ll Save

At $24/month on Vultr vs the same tier on DigitalOcean, the specs are identical in vCPU and RAM but Vultr gives you 25% more storage (100 GB NVMe vs 80 GB SSD) and 25% more bandwidth (5 TB vs 4 TB). NVMe vs SSD isn’t marketing fluff at this tier – the IOPS difference (118k vs 54k) directly translates to faster database queries and lower page load times for dynamic sites.

New Vultr accounts get $300 in free credit (valid 30 days) via the signup promo – enough to run your new instance in parallel with your Droplet during the migration window without paying for both. See our Vultr pricing breakdown for the full plan details.

Prices last verified: 2026-06-29

Related reading: deploying Django on your new Vultr VPS, deploying Docker workloads on Vultr, deploying WordPress on Vultr.

Take Your Time With the DNS Cutover

The migration itself isn’t complex – rsync, a database dump, and a DNS update. The part that requires patience is the TTL lowering and parallel-run window. Rush the DNS cutover and you’ll have clients hitting a dead server; give it the full 72 hours and it’s invisible.

For most developers and site owners running single-instance setups, Vultr is a clear upgrade at the same price: more storage, faster disk, better CPU benchmarks, and more regions. The trade-offs are a less polished UI and a thinner managed services ecosystem – if you’re heavily reliant on DigitalOcean App Platform or managed Kubernetes, those don’t have a direct equivalent on Vultr.

Ready to start? New accounts get $300 in free credit – enough to run both servers in parallel through your full migration window.