tinjauhost.biz.id

Review hosting Indonesia, perbandingan VPS lokal vs internasional, panduan migrasi

Migrasi Hosting: Panduan Teknis Aman Tanpa Downtime

by Andi Saputra
Migrasi Hosting: Panduan Teknis Aman Tanpa Downtime

Migrasi Hosting: Panduan Teknis Aman Tanpa Downtime

Banyak pemilik situs lokal yang ragu bermigrasi dari hosting lama ke VPS baru—bukan karena kurang yakin dengan target hosting, melainkan takut situs down saat proses. Pertanyaan yang sering datang: "Berapa lama downtime? Bagaimana kalau email terputus? Apa data saya aman?"

Artikel ini menjelaskan metodologi migrasi yang sudah diuji berkali-kali, baik dari shared hosting ke VPS lokal, maupun dari provider lokal ke internasional. Kami fokus pada teknis—bukan hanya teori.

Mengapa Migrasi Hosting Sering Gagal?

Sebelum terjun ke langkah teknis, penting tahu penyebab utama migrasi bermasalah:

  1. Tidak ada backup terpisah – Hanya mengandalkan backup dari hosting lama, padahal saat migrasi bisa terjadi kesalahan transfer.
  2. TTL DNS tidak diturunkan lebih dulu – TTL (Time To Live) yang tinggi membuat DNS cache lama di ISP, sehingga beberapa pengunjung masih tersambung ke IP lama.
  3. Testing tidak matang – Langsung cutover tanpa verifikasi di environment baru.
  4. Email dan subdomain terlupakan – Fokus pada situs utama, tapi MX record atau subdomain lain tidak dikonfigurasi di server baru.
  5. Database belum dioptimalkan – Migrasi database besar tanpa import test dulu, risiko timeout atau error.

Kriteria Penilaian Keberhasilan Migrasi

Sebelum mulai, tetapkan standar:

  • Downtime ≤ 5 menit – Ideal untuk situs bisnis; acceptable untuk situs personal.
  • Semua file dan database intact – Verifikasi checksum atau record count.
  • Email tetap berfungsi – MX record aktif di server baru.
  • SSL certificate valid – Tidak ada warning di browser.
  • Performa lebih baik atau setara – Cek TTFB (Time To First Byte) dan load time.

Fase 1: Persiapan (3–5 hari sebelum cutover)

1.1 Audit Situs Lama

Buat inventory lengkap:

- Jumlah file (gunakan: du -sh /home/username/public_html)
- Ukuran database (phpMyAdmin → klik database → lihat "Data length")
- Jumlah email account dan forwarding
- Subdomain dan addon domain
- SSL certificate (self-signed atau paid?)
- Cron job yang berjalan
- Custom .htaccess atau nginx rule

1.2 Backup Penuh

Jangan andalkan hosting lama. Buat tiga backup:

Backup 1: Full backup dari hosting lama

  • Gunakan cPanel Backup atau manual via FTP/SSH.
  • Download ke komputer lokal dan eksternal drive.

Backup 2: Database dump terpisah

mysqldump -u username -p database_name > database_backup.sql

Backup 3: File tarball

tar -czf website_files.tar.gz /home/username/public_html

1.3 Turunkan TTL DNS

Ini langkah yang paling sering terlewat. TTL default biasanya 3600 detik (1 jam).

  • Login ke panel DNS (registrar atau hosting).
  • Ubah TTL menjadi 300 detik (5 menit) untuk semua record A, AAAA, CNAME.
  • Tunggu 1 hari agar perubahan tersebar di cache ISP.
  • Catat IP lama dan IP baru untuk referensi.

Fase 2: Setup Server Baru (1–2 hari sebelum cutover)

2.1 Restore File dan Database

Di VPS baru (anggap OS Ubuntu 20.04), pastikan dev environment lokal Anda sudah siap sebelum memulai restore:

# Ekstrak file
cd /var/www
tar -xzf website_files.tar.gz

# Import database
mysql -u new_username -p new_database < database_backup.sql

# Set permission
chown -R www-data:www-data /var/www/html
chmod -R 755 /var/www/html

2.2 Konfigurasi Web Server

Jika menggunakan Nginx (recommended untuk VPS):

server {
    listen 80;
    server_name domain.com www.domain.com;
    root /var/www/html;
    index index.php index.html;

    location ~ \.php$ {
        fastcgi_pass unix:/var/run/php/php7.4-fpm.sock;
        fastcgi_index index.php;
        include fastcgi_params;
    }
}

Jika menggunakan Apache:

<VirtualHost *:80>
    ServerName domain.com
    ServerAlias www.domain.com
    DocumentRoot /var/www/html
    <Directory /var/www/html>
        AllowOverride All
        Require all granted
    </Directory>
</VirtualHost>

2.3 Setup SSL Certificate

Gunakan Let's Encrypt (gratis) via Certbot:

sudo certbot certonly --standalone -d domain.com -d www.domain.com

Konfigurasi Nginx untuk HTTPS:

listen 443 ssl http2;
ssl_certificate /etc/letsencrypt/live/domain.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/domain.com/privkey.pem;

2.4 Setup Email (MX Record)

Jika menggunakan mail server di VPS baru:

MX record: mail.domain.com (priority 10)
A record: mail.domain.com -> IP_VPS_BARU

Jika menggunakan layanan email eksternal (Google Workspace, Zoho):

  • Tidak perlu ubah MX record.
  • Pastikan hanya update A record domain utama saja.

Fase 3: Testing di Server Baru (2–3 hari sebelum cutover)

3.1 Test Lokal via Hosts File

Edit /etc/hosts (Linux/Mac) atau C:\Windows\System32\drivers\etc\hosts (Windows):

123.45.67.89 domain.com
123.45.67.89 www.domain.com

Buka browser, akses domain.com. Verifikasi:

  • Situs tampil normal.
  • Semua gambar dan CSS ter-load.
  • Form submit berfungsi.
  • Database query bekerja (cek halaman yang menampilkan data).
  • Email test bisa dikirim.

3.2 Test dengan Online Tools

Gunakan layanan pihak ketiga untuk test dari berbagai lokasi:

  • Pingdom (pingdom.com): Cek load time.
  • SSL Labs (ssllabs.com): Verifikasi SSL certificate.
  • MXToolbox (mxtoolbox.com): Test MX record dan mail server.
  • DNS Propagation Checker (whatsmydns.net): Cek DNS spread.

3.3 Verifikasi Database dan File

# Hitung jumlah record database
mysql -u new_username -p new_database -e "SELECT COUNT(*) FROM table_name;"

# Verifikasi file count
find /var/www/html -type f | wc -l

# Bandingkan dengan server lama

Fase 4: Cutover (Hari H)

4.1 Maintenance Mode (Opsional)

Jika situs menggunakan CMS (WordPress, Drupal), aktifkan maintenance mode untuk mencegah user akses saat migrasi:

WordPress:

// Tambah di wp-config.php
define('WP_MAINTENANCE_MODE', true);

4.2 Update DNS A Record

Login ke registrar atau panel DNS:

  • Update A record domain.com ke IP VPS baru.
  • Update A record www.domain.com ke IP VPS baru (atau CNAME ke domain.com).
  • Catat waktu update (timestamp).

4.3 Monitor Propagation

Gunakan dig atau nslookup untuk monitor DNS propagation:

dig domain.com +short
# Output harus menunjukkan IP baru dalam beberapa menit

# Monitor setiap 2 menit
while true; do dig domain.com +short; sleep 120; done

4.4 Verifikasi dari Browser Berbeda

  • Buka situs dari komputer lain (berbeda ISP jika mungkin).
  • Cek dari mobile hotspot.
  • Clear browser cache atau gunakan incognito mode.

4.5 Cek Log Server

Monitor error log di VPS baru:

# Nginx
tail -f /var/log/nginx/error.log

# Apache
tail -f /var/log/apache2/error.log

# PHP
tail -f /var/log/php-fpm.log

Fase 5: Post-Cutover (Hari H+1)

5.1 Disable Maintenance Mode

Setelah verifikasi semua berjalan normal:

// Hapus atau comment di wp-config.php
// define('WP_MAINTENANCE_MODE', true);

5.2 Monitor Uptime dan Error

  • Gunakan tool monitoring (Uptime Robot gratis, atau Datadog berbayar).
  • Cek analytics untuk traffic anomali.
  • Monitor database query time.

5.3 Rencanakan Deactivation Server Lama

Jangan hapus server lama dulu. Tunggu minimal 7 hari untuk memastikan:

  • Tidak ada cache issue dari ISP.
  • Semua user sudah tersambung ke server baru.
  • Tidak ada emergency rollback perlu.

Setelah aman, baru hapus atau downgrade server lama.

Tabel Perbandingan: Strategi Migrasi

Aspek Shared Hosting → VPS Lokal Lokal → VPS Internasional Lokal → Lokal (Provider Beda)
Downtime Expected 5–15 menit 10–30 menit 5–10 menit
Kompleksitas DNS Sedang Tinggi (TTL global) Sedang
Risiko Email Rendah (jika setup benar) Tinggi (timezone, MX delay) Sedang
Testing Perlu Ya, 2–3 hari Ya, 3–5 hari Ya, 1–2 hari
Rollback Mudah? Ya (DNS revert cepat) Ya, tapi tunggu TTL Ya (DNS revert cepat)

Kelebihan dan Kekurangan Pendekatan Ini

Kelebihan

  • Downtime minimal – TTL rendah memastikan switch cepat.
  • Testing menyeluruh – Mengurangi risiko error di production.
  • Backup berlapis – Jika ada masalah, recovery lebih mudah.
  • Rollback feasible – Bisa balik ke server lama dalam hitungan menit.

Kekurangan

  • Persiapan lama – Butuh 3–5 hari planning dan testing.
  • Perlu skill teknis – SSH, DNS, database dump bukan hal trivial.
  • Maintenance window perlu – Harus ada waktu untuk cutover (ideal malam atau weekend).
  • Email bisa delay – Jika menggunakan mail server di VPS, delay 1–2 jam mungkin terjadi.

Vonis

Rekomendasi: Gunakan panduan ini jika Anda migrasi dari shared hosting ke VPS lokal atau internasional. Strategi TTL-turun-dulu + testing-menyeluruh adalah standar industri yang terbukti meminimalkan risiko. Jika Anda juga ingin memastikan situs tampil optimal di mesin pencari setelah migrasi, perhatikan pula schema markup yang sering diabaikan saat pindah server.

Alternatif untuk yang ingin lebih mudah: Jika tidak percaya diri dengan teknis, gunakan layanan migrasi berbayar dari hosting target (banyak VPS lokal menawarkan ini gratis untuk paket tahunan). Biaya Rp 500–2 juta tapi downtime bisa dijamin ≤ 5 menit dan Anda tidak perlu pusing.

Jangan lakukan: Migrasi langsung tanpa backup berlapis, tanpa test, atau tanpa turunkan TTL. Risiko downtime 30+ menit sangat nyata—dan itu bisa biaya lebih besar dari backup atau migrasi profesional.