Migrasi VPS Antar Provider: Panduan Zero-Downtime 2026

Aku masih inget banget momen itu. Tahun 2021, pas aku masih NOC junior di sebuah startup yang lagi nge-host belasan VPS buat klien. Atasan manggil aku dan ngasih tugas yang bikin perasaan campur aduk: migrasi semua virtual server ke provider baru. Bukan satu-dua, hampir semuanya, dan mayoritas production.

“Deadline-nya kapan?” tanya aku. “Secepatnya,” jawabnya sambil senyum tipis. Nggak tegas, nggak jelas. Yang jelas, klien nggak boleh ngerasain down lebih dari beberapa menit. Intinya: migrasi VPS antar provider tanpa downtime.

Dulu aku mikir migrasi itu kayak pindah rumah. Matiin semuanya, pindahin barang, nyalain lagi di tempat baru. Simpel di kepala, tapi di dunia nyata banyak barang pecah, ada yang ketinggalan, dan tetangga baru belum tentu tau alamat kamu. Persis kayak migrasi server yang nggak direncanain: data korup, config nyasar, dan DNS yang belum propagate bikin sebagian user masih nyasar ke server lama. Padahal konsep sebenarnya simpel: dua server jalan bareng dulu, pegang data yang sama, sampai server baru bener-bener siap gantian. Baru tukeran trafik. Estafet, bukan lompat gedung.

Waktu itu aku masih polos. Kontrak provider baru, request VPS, terus mulai pindahin data manual pake scp satu per satu. Tebak hasilnya? Website down hampir satu hari penuh, database kelewat sinkronisasi terakhir, dan user mulai banyak yang komplain. Capeknya minta ampun, dan keselnya itu nggak ada abisnya karena sebenernya ini semua bisa dicegah. Dari kegagalan itu aku nyusun alur yang sekarang jadi SOP internal di tempat kerja, dan di artikel ini mau aku share lengkap biar kamu nggak ngalamin hal yang sama.

Jadi kerangka besarnya gini: kamu nggak perlu bikin server lama mati dulu buat mulai migrasi. Kamu siapin server baru, isi data dari server lama, terus biar data tetep nyambung dengan cara sinkronisasi berkala. Pada akhirnya kamu tinggal muter DNS (atau IP kalau providernya ngizinin), user tetep nyaman, dan kamu punya waktu buat verifikasi sebelum total pindah. Masing-masing tahap ada jebakannya sendiri, dan jebakan-jebakan itu justru yang paling sering bikin insiden. Yuk kita bahas satu-satu, pelan-pelan kayak lagi ngobrol.

Kenapa Migrasi VPS Antar Provider Bisa Bikin Server Down?

Kalau kamu pindah dalam provider yang sama, misalnya pindah node KVM di DC yang sama, biasanya ada fitur live migration. Tapi antar provider beda? Nggak ada. Provider A nggak bisa ngomong ke provider B buat mindahin VM kamu secara langsung. Mau nggak mau, kamu mindahin data lewat internet. Dan di situ masalahnya mulai keliatan.

Data nggak mungkin dipindahin sekali doang kalau aplikasimu terus nulis data baru. Selama server lama masih ngelayani user, database tetep nulis. Kalau kamu dump database jam 10 pagi, terus cutover jam 12 siang, dua jam data hilang. Itu bukan “downtime kecil”, itu data loss, dan ini yang paling sering bikin aku geregetan. Gejala klasiknya: admin nge-dump database, pindahin, terus baru sadar user masih posting komentar di server lama yang datanya nggak kepindah.

Masalah kedua adalah DNS. DNS itu kayak buku alamat kota. Kamu pindah rumah ke alamat baru, tapi buku alamat di tiap rumah warga nggak langsung ke-update. Semua orang masih dateng ke alamat lama. Makanya sebelum migrasi, TTL DNS harus diturunkan dari biasanya (24 jam misalnya) ke angka kecil kayak 300 detik, minimal seminggu sebelum cutover. Kalau nggak, abis kamu pindah, sebagian user masih nembak IP lama berhari-hari. Dan server lama udah kamu matiin. Hasilnya? Error, not found, capek ngelayani komplain.

Ketiga, urusan database. Kalau database kamu udah gede, mysqldump bisa makan waktu berjam-jam, dan di tengah jalan dump bisa bikin load server naik. Belum lagi kalau tabelnya MyISAM, dump bisa nge-lock dan bikin aplikasi nge-freeze. Banyak admin yang nggak nyadar ini, terus nge-dump pas jam sibuk. Akibatnya, bukan cuma migrasinya yang bermasalah, server lama-nya pun ikut sekarat. Nah, di langkah-langkah di bawah ini, semua jebakan itu aku carikan jalan keluarnya, lengkap dengan perintah yang bisa langsung kamu jalankan.

Langkah 1: Audit dan Dokumentasi — Ini Bukan Basa-basi

Sebelum nyentuh apa-apa, kamu harus tau persis apa yang jalan di server lama. Nggak jarang aku nemu server yang isinya nggak sesuai catatan: ada cron job yang nggak dikenal, ada service jalan tanpa pengawas, atau ada domain yang ternyata nempel di IP tertentu. Audit ini nentuin skenario migrasi kamu, jadi jangan dilewatin.

Mulai dari mencatat spek dan resource:

cat /etc/os-release
nproc
free -h
df -h
lsblk

Terus daftarin service yang lagi jalan:

systemctl list-units --type=service --state=running

Dan jangan lupa cron job:

crontab -l
ls -la /etc/cron.d/
ls -la /etc/cron.daily/

Terus cek port yang kebuka:

ss -tulpn

Dari sini kamu bikin checklist. Aplikasi apa aja, database mana, config file di path mana, cron mana yang kritis, dan external service apa yang narik data ke server ini, misalnya payment gateway yang whitelist IP. Semua ini wajib tercatat sebelum langkah berikutnya, karena nanti jadi dasar verifikasi.

Pro tip dari aku: simpan dokumentasinya di tempat yang nggak ikut ke-migrasi, misalnya di Google Docs atau di laptop kamu. Jangan cuma di notes server lama, karena kalau server lama bermasalah, catatan kamu ikut tenggelam.

Langkah 2: Turunkan TTL DNS Minimal Seminggu Sebelum

Ini langkah yang paling sering di-skip, dan ini langkah yang paling sering bikin aku senyum kecut pas nolongin kasus migrasi. Cek dulu TTL DNS domain kamu sekarang:

dig +short example.com SOA
dig example.com A

Kalau TTL-nya masih kayak 86400 (24 jam), berarti begitu kamu ganti IP di nameserver, cache resolver di dunia bisa nahan alamat lama sampai 24 jam. Satu hari full user nembak server lama yang mungkin udah kamu shutdown. Nggak banget.

Turunin TTL semua record yang relevan ke 300 detik (5 menit), minimal H-7 sebelum cutover. Record yang perlu: A/AAAA, MX, CNAME, dan record lain yang ngaruh ke service kamu. Ini bisa dilakukan di panel DNS masing-masing provider, atau di file zone kalau kamu self-host DNS.

Kenapa H-7? Karena perubahan TTL yang kamu set hari ini baru “berlaku” untuk resolver setelah TTL lama mereka kedaluwarsa. Kalau TTL kamu tadi 24 jam, kamu set TTL baru 5 menit hari ini, sebagian resolver masih nempel di nilai 24 jam selama sehari ke depan. Jadi kasih buffer minimal seminggu biar seluruh ekosistem DNS nyelesaiin TTL lamanya. Ini detail yang jarang diperhatiin tapi nentuin sukses atau gagalnya cutover kamu.

Langkah 3: Setup Server Baru di Provider Target

Pasang OS yang versinya sama atau lebih baru dari server lama. Kalau server lama CentOS 7 dan umurnya udah EOL, justru ini momentum yang bagus buat upgrade ke versi supported — tapi inget, upgrade OS saat migrasi artinya tambah satu variabel risiko. Kalau mau aman, samain dulu versi OS-nya, upgrade belakangan. Kecil-kecil dulu, lanjut ke hal gede setelah service stabil.

Setelah OS jalan, hardening dasar sebelum data masuk. Soal SSH ini penting banget, kamu bisa baca juga cara amankan SSH server VPS biar server barumu nggak jadi mangsa brute force sejak hari pertama:

ssh-keygen -t ed25519
ssh-copy-id root@203.0.113.10

Ganti SSH port kalau perlu, pasang fail2ban, update semua paket:

apt update && apt upgrade -y
apt install -y fail2ban

Terus, yang sering kelewat: samain versi aplikasi. Kalau server lama pake PHP 7.4 dan kamu baru install PHP 8.3 di server baru, jangan heran config lama langsung error atau ada sintaks PHP yang deprecated. Cek versi di server lama:

php -v
mysql --version
nginx -v

…dan samain dulu versi itu di server baru. Migrasi bukan waktunya berani-berani upgrade versi besar. Setelah data masuk dan aplikasi terbukti jalan, baru deh rencana upgrade dengan tenang.

Langkah 4: Sinkronisasi File dengan Rsync

Untuk pindahin file dari server lama ke server baru, rsync adalah sahabat kamu. Keunggulannya, dia bisa nyinkronin lagi tanpa mindahin ulang file yang sama (incremental), jadi aman dipake berulang-ulang sampai cutover.

Contoh sinkronisasi dari root filesystem (pengecualian buat folder khusus sistem):

rsync -avz --delete 
  --exclude '/proc' --exclude '/sys' --exclude '/dev' 
  --exclude '/run' --exclude '/tmp' 
  -e ssh root@OLD_SERVER_IP:/ 
  /

Hmm, hati-hati dengan perintah di atas kalau kamu baru pertama kali. Versi yang lebih terkontrol: pindahin dulu folder data aplikasi, kayak /home atau /var/www:

rsync -avz --delete 
  -e ssh root@OLD_SERVER_IP:/home/ 
  /home/

Nah, perhatiin flag –delete. Flag ini bikin rsync hapus file di sisi tujuan yang nggak ada di sisi sumber. Aman selama arahnya bener, tapi fatal kalau kamu ketuker. Aku pernah lihat orang ngebalik arah rsync-nya… eh, itu cerita buat lain kali. Intinya, selalu tulis sumber lalu tujuan, dan coba dulu dengan –dry-run:

rsync -avz --dry-run --stats 
  -e ssh root@OLD_SERVER_IP:/var/www/ /var/www/

Baca hasilnya dulu, kalau masuk akal baru jalankan tanpa –dry-run. Buat config file yang spesifik ke server, kayak /etc/nginx/nginx.conf atau /etc/mysql/my.cnf, jangan langsung nimpuk. Bawa, bandingin, terus sesuaikan manual. Setting yang nyangkut IP atau hostname server baru biasanya perlu edit dikit.

Jadwal sinkronisasi: kamu bisa jalankan rsync beberapa kali selama masa transisi. Pertama buat baseline (pindahin semuanya, bisa lama), terus sinkronisasi kedua pas mau cutover (cepat, karena cuma delta). Praktis dan nggak makan waktu.

Langkah 5: Replikasi Database MySQL/MariaDB

Ini bagian yang paling bikin deg-degan. Kalau aplikasi kamu nulis ke database terus-menerus, rsync file aja nggak cukup, karena file database di server lama pasti berubah terus. Dua opsi: dump + import yang di-repeat, atau replication beneran. Untuk zero downtime, replication adalah jawabannya. Kalau mau ngulik lebih dalem soal ini, aku pernah nulis panduan replikasi MySQL/MariaDB realtime yang bisa kamu baca sebagai pelengkap.

Opsi pertama, dump biasa (cocok buat database kecil dan aplikasi yang bisa idle sebentar):

mysqldump -u root -p 
  --all-databases 
  --single-transaction 
  --routines --triggers --events 
  > alldb.sql

Import di server baru:

mysql -u root -p < alldb.sql

Note penting: –single-transaction cuma berlaku untuk InnoDB dan butuh read consistency, jadi kalau ada tabel MyISAM, dump bisa lock. Untuk database besar, mending jalankan di jam sepi.

Opsi kedua, replication. Di server lama (master), tambahkan config di /etc/mysql/mariadb.conf.d/50-server.cnf:

[mysqld]
server-id = 1
log_bin = /var/log/mysql/mysql-bin
binlog_format = ROW
expire_logs_days = 7

Restart MySQL, terus buat user replikasi:

CREATE USER 'repl'@'203.0.113.10' IDENTIFIED BY 'password_kuat_dan_unik';
GRANT REPLICATION SLAVE ON *.* TO 'repl'@'203.0.113.10';
FLUSH PRIVILEGES;

Catat posisi binlog:

SHOW MASTER STATUS;

Hasilnya kayak gini:

+------------------+----------+--------------+------------------+
| File             | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+------------------+----------+--------------+------------------+
| mysql-bin.000042 | 1234567  |              |                  |
+------------------+----------+--------------+------------------+

Dump dulu database yang ada di server lama buat jadi baseline di server baru, terus import, lalu jalankan:

CHANGE MASTER TO
  MASTER_HOST='203.0.113.10',
  MASTER_USER='repl',
  MASTER_PASSWORD='password_kuat_dan_unik',
  MASTER_LOG_FILE='mysql-bin.000042',
  MASTER_LOG_POS=1234567;
START SLAVE;

Verifikasi selalu:

SHOW SLAVE STATUSG

Cek dua baris ini:

Slave_IO_Running: Yes
Slave_SQL_Running: Yes

Kalau dua-duanya Yes dan Seconds_Behind_Master mulai mendekati nol, berarti server baru udah live datanya. Setelah cutover nanti, barulah arahkan replikasi kebalikannya atau stop slave dan reset. Oh ya, semua ini butuh jaringan antara dua server lancar, jadi pastikan port 3306 kebuka dari server baru ke server lama. Port itu jalan dua arah ya, jangan sampai cuma satu sisi.

Detail yang sering bikin gagal: firewall. Banyak server baru yang langsung tolak koneksi ke port 3306 karena UFW atau iptables. Cek dengan:

ss -tlnp | grep 3306
ufw status

…dan jangan lupa samain timezone dan character set antara dua server biar data yang direplikasi nggak jadi aneh.

Langkah 6: Cutover DNS yang Mulus

Setelah data sync dan replication jalan, saatnya eksekusi. Tapi sebelum ganti DNS, ada satu hal yang wajib kamu lakuin: verifikasi server baru jalan normal dulu. Akses aplikasi lewat IP langsung atau edit /etc/hosts di laptop kamu:

echo "203.0.113.10 example.com" >> /etc/hosts

Terus buka https://example.com. Cek login, fitur yang sering dipake user, dan pastikan semua asset (gambar, JS, CSS) termuat. Kalau ada yang error, ini waktu buat fix, bukan nunggu abis cutover.

Kalau semua oke, saatnya ganti record A (dan MX kalau email juga ikut pindah) ke IP server baru di nameserver provider DNS kamu. Karena TTL udah kita turunin jadi 300 detik, perubahan ini bakal kebawa resolver dalam hitungan menit. Prosesnya nggak langsung kayak ngilangin lampu, tapi pelan-pelan migrasi trafik dari server lama ke server baru.

Setelah ganti, jangan langsung matiin server lama. Tunggu 2-24 jam dan pantau. Banyak admin yang semangat langsung shutdown server lama, terus baru nyadar ada cron yang nyala di server lama buat kirim email, atau ada payment callback yang masih nembak IP lama. Biarin server lama hidup dulu sebagai jaring pengaman. Kamu bisa lihat siapa yang masih nyasar ke server lama lewat log akses:

tail -f /var/log/nginx/access.log

Kalau udah sepi, berarti hampir semua trafik udah pindah. Baru deh kamu matiin server lama, atau setidaknya matiin service utamanya sambil tetep nyimpen data sebagai backup cadangan.

Langkah 7: Verifikasi dan Monitoring Pasca Migrasi

Pindah itu belum selesai. Selesai itu setelah semua terverifikasi dan dipantau beberapa hari. Ini checklist yang aku pake tiap kali migrasi, kamu boleh contek:

• Cek semua website/domain response 200, bukan 502 atau 504.
• Cek SSL certificate aktif dan nggak ada SAN mismatch.
• Cek email delivery (kalau MX ikut pindah) — kirim test ke beberapa provider (Gmail, Yahoo, Outlook).
• Cek cron job jalan: job harian apa aja yang biasanya jalan, pastikan hasilnya muncul di log server baru.
• Cek integrasi eksternal: payment gateway, API pihak ketiga, webhook. Kalau mereka whitelist IP, daftarin IP baru.
• Cek resource usage beberapa hari pertama: kalau tiba-tiba load tinggi atau disk penuh, itu sinyal ada yang nggak bener di tuning.
• Cek log error aplikasi di server baru, bukan cuma response code.

Buat monitoring sederhana, kamu bisa polling dari laptop atau server lain:

while true; do
  curl -o /dev/null -s -w "%{http_code} %{time_total}sn" https://example.com
  sleep 60
done

Biarkan jalan beberapa jam sambil kamu nikmatin kopi. Kalau semuanya hijau terus, migrasi kamu secara praktis udah kelar. Kalau ada yang kuning-merah, kamu masih punya waktu buat rollback, dan itu kenapa langkah terakhir berikut ini penting.

Rencana Rollback: Jaring Pengaman yang Jangan Kamu Abaikan

Semua rencana migrasi yang bagus punya plan B. Rollback di sini gampang banget asal kamu nggak buru-buru matiin server lama: kamu tinggal ganti balik record DNS ke IP server lama, dan dalam hitungan menit trafik balik ke server lama lagi. Data yang masuk selama jendela itu mungkin selisih beberapa jam, tapi server nggak down, dan itu yang utama.

Catatan penting: sebelum cutover, jangan matiin replication maupun cron di server lama. Dua-duanya masih bagian dari sistem sampai kamu nyata-nyata nyerahin tongkat estafet. Baru setelah kamu verifikasi berhari-hari dan trafik udah pindah total, kamu matiin service di server lama pelan-pelan.

Terus, backup terakhir server lama sebelum mati total: snapshot atau full rsync lagi ke tempat aman. Bukan karena kamu pesimis, tapi karena backup itu selalu nyimpen harapan. Kayak orang bijak bilang, ora ono sing sia-sia nek isih dipegang. Masa sih kamu mau balik nyari data lama yang udah keputusan hapus? Ora, kan?

Troubleshooting Umum Saat Migrasi VPS

Gejala	Kemungkinan Penyebab	Solusi Cepat
User masih dapat halaman lama / error 404 setelah cutover	TTL DNS belum kedaluwarsa di resolver tertentu	Tunggu sesuai TTL, atau cek via dns.google dari lokasi berbeda
MySQL Slave nggak jalan, Slave_IO_Running: No	Koneksi port 3306 keblok firewall / credentials salah	Cek ufw/iptables, test telnet 203.0.113.10 3306, reset slave dengan posisi binlog baru
Website error 502 Bad Gateway di server baru	Service aplikasi (PHP-FPM/Node) belum start atau versi beda	systemctl status php*-fpm, cek versi PHP vs config lama
Disk penuh setelah rsync	Rsync mindahin log lama atau file duplikat	Exclude folder log/backup di rsync, cek du -sh /
Email nggak terkirim abis migrasi	MX record belum pindah / reverse DNS IP baru belum set	Set PTR record di provider baru, cek dig +short MX domain
Koneksi SSH ke server baru lambat	DNS reverse lookup di SSH (UseDNS)	Set UseDNS no di /etc/ssh/sshd_config, restart sshd

Kalau kamu nemu gejala yang nggak ada di tabel ini, jangan panik dulu. Mulai dari log. Log itu kayak buku harian server — di situ semua kejadian tercatat. Baca dari awal sampai akhir, jangan cuma cari kata “error”. Kadang penyebab aslinya ada di baris sebelum error muncul. Pelan-pelan, satu-satu.

FAQ Migrasi VPS Antar Provider

Nah, segitu dulu cerita dan pengalaman aku soal migrasi VPS antar provider tanpa downtime. Kalau diceritain pelan-pelan kayak gini, sebenernya nggak serumit yang dibayangin, ya? Kuncinya cuma dua: persiapan yang teliti dan jangan buru-buru matiin yang lama. Semua teknik yang aku sebut di atas udah aku praktekin berkali-kali, dan sampai sekarang masih jadi alur utama kalau ada migrasi di kantor.

Oh ya, kalau kamu mau nyimak cerita-cerita lain dari pengalaman aku di NOC, beberapa artikel ini mungkin bisa nemenin: cara bikin backup VPS otomatis dengan rsync biar jaring pengaman kamu makin kuat, dan troubleshooting DNS propagation buat jaga-jaga pas cutover. Kalau ada pertanyaan, tulis di kolom komentar aja. Aku baca kok, pelan-pelan, kayak cerita di atas. Matur nuwun udah mampir, ya!