Apa yang Perlu Dipertimbangkan Saat Bermigrasi ke Penyedia Web Hosting Lain

Migrasi website ke penyedia hosting baru adalah salah satu operasi infrastruktur berisiko tertinggi yang dapat dilakukan oleh pemilik situs. Jika dilakukan dengan benar, hasilnya adalah nol kehilangan data, downtime yang dapat diabaikan, dan performa yang terukur lebih baik. Jika dilakukan dengan sembrono, hasilnya adalah database yang rusak, kegagalan DNS, penurunan peringkat SEO, dan berjam-jam pekerjaan pemulihan darurat.

Panduan ini mencakup setiap fase kritis migrasi hosting — mulai dari audit pra-migrasi dan validasi kompatibilitas, melalui mekanisme peralihan DNS, hingga pemantauan pasca-migrasi — dengan kedalaman teknis yang diperlukan untuk melaksanakannya tanpa insiden.

Fase 1: Audit Lingkungan Hosting Anda Saat Ini Sebelum Menyentuh Apapun

Kegagalan migrasi yang paling umum terjadi karena melewatkan audit menyeluruh terhadap lingkungan yang ada. Sebelum Anda mengevaluasi penyedia baru, Anda memerlukan inventaris yang tepat tentang apa yang sebenarnya Anda jalankan.

Profiling Traffic dan Sumber Daya

Ambil setidaknya 90 hari data sumber daya server — bukan hanya jumlah pageview. Metrik yang penting adalah:

• Puncak koneksi bersamaan — bukan traffic rata-rata, tetapi batas lonjakan yang harus ditangani server Anda
• Konsumsi memori per PHP worker atau proses aplikasi
• Pola Disk I/O — terutama relevan jika Anda menjalankan aplikasi berbasis database seperti WooCommerce atau CRM kustom
• Utilisasi bandwidth — total transfer bulanan versus batas paket Anda saat ini

Jika host Anda saat ini menyediakan cPanel atau Plesk, data ini dapat diakses di bagian penggunaan sumber daya atau AWStats. Pada Linux VPS, jalankan perintah berikut untuk mengambil snapshot baseline:

vmstat 1 10
iostat -x 1 5
free -m
df -h

Output ini memberi tahu Anda apakah bottleneck Anda adalah CPU, RAM, atau disk — yang secara langsung menentukan apakah Anda memerlukan paket shared yang lebih besar, VPS, atau Dedicated Server.

Inventaris Software Stack

Dokumentasikan setiap komponen stack Anda dengan nomor versi yang tepat:

• Versi PHP (misalnya, 8.1, 8.2) dan ekstensi aktif (mbstring, curl, gd, imagick, redis)
• Versi MySQL atau MariaDB dan storage engine (InnoDB vs. MyISAM penting untuk tooling migrasi)
• Software web server: Apache, Nginx, LiteSpeed, atau kombinasi reverse-proxy
• Modul yang dikompilasi, aturan .htaccess kustom, atau blok nginx.conf location
• Cron job — ekspor dari crontab -l dan dokumentasikan secara terpisah
• Jenis dan penerbit sertifikat SSL (Let’s Encrypt, CA komersial, wildcard)

Melewatkan bahkan satu ekstensi PHP pada server tujuan dapat secara diam-diam merusak fungsionalitas yang hanya muncul dalam tindakan pengguna tertentu — sebuah bug yang terkenal sulit dilacak setelah migrasi.

Fase 2: Evaluasi dan Pilih Tier Hosting yang Tepat

Memilih tier hosting yang salah adalah kesalahan struktural yang memaksa migrasi kedua dalam beberapa bulan. Petakan temuan audit Anda ke kelas infrastruktur yang tepat.

Perbandingan Tier Hosting

Aturan keputusan utama: Jika aplikasi Anda memerlukan konfigurasi PHP-FPM pool tertentu, koneksi Redis socket, penulisan ulang Nginx kustom, atau proses daemon apapun, shared hosting tidak kompatibel secara arsitektur. Anda memerlukan minimal VPS dengan akses root.

Untuk situs WordPress atau Joomla dengan traffic sedang, VPS dengan cPanel menyediakan antarmuka control panel yang familiar sambil mempertahankan isolasi dan performa mesin virtual.

Kriteria Evaluasi Penyedia

Di luar klaim pemasaran, evaluasi penyedia berdasarkan faktor teknis yang dapat diverifikasi ini:

• SLA uptime dengan klausul penalti finansial — SLA 99.9% tanpa kompensasi tidak berarti apa-apa
• Rating tier data center (Tier III atau Tier IV untuk beban kerja produksi)
• Redundansi jaringan — BGP multi-homing, beberapa penyedia upstream
• Jenis penyimpanan — NVMe SSD versus SATA SSD versus spinning disk (perbedaan latensi sangat signifikan)
• Kebijakan backup — frekuensi, periode retensi, apakah backup disimpan off-site
• SLA waktu respons dukungan — bedakan antara waktu respons pertama dan waktu penyelesaian

Fase 3: Buat dan Verifikasi Backup Lengkap

Tidak ada migrasi yang boleh dimulai tanpa backup yang terverifikasi dan dapat dipulihkan. “Terverifikasi” berarti Anda benar-benar telah menguji pemulihan — bukan hanya mengonfirmasi bahwa file backup ada.

Apa yang Harus Disertakan dalam Backup Lengkap

• File web root — seluruh document root, termasuk file tersembunyi seperti .htaccess dan .env
• Semua database — diekspor sebagai dump .sql, bukan hanya salinan file direktori database
• Data email — jika Anda menggunakan Email Hosting yang terikat ke domain Anda, ekspor mailbox sebelum perubahan DNS apapun
• Cron job — crontab -l > crontab_backup.txt
• Sertifikat SSL dan private key — jika menggunakan sertifikat komersial, ekspor full chain
• File konfigurasi server — /etc/nginx/, /etc/apache2/, /etc/php/, pengaturan my.cnf kustom

Melakukan Ekspor Database

Untuk MySQL/MariaDB, gunakan mysqldump dengan opsi yang mempertahankan fidelitas penuh:

mysqldump 
  --single-transaction 
  --routines 
  --triggers 
  --events 
  --set-gtid-purged=OFF 
  -u root -p your_database_name > database_backup_$(date +%F).sql

Flag --single-transaction sangat penting untuk tabel InnoDB — ini mengambil snapshot yang konsisten tanpa mengunci tabel, yang berarti situs live Anda terus melayani permintaan selama dump berlangsung.

Memverifikasi Integritas Backup

# Check the SQL dump is not truncated
tail -5 database_backup_2024-01-15.sql

# Verify file count in web root backup
tar -tzf webroot_backup.tar.gz | wc -l

# Test restoration to a local or staging environment
mysql -u root -p test_restore_db < database_backup_2024-01-15.sql

Backup yang belum Anda uji pemulihannya bukanlah backup — itu adalah rasa aman yang palsu.

Fase 4: Validasi Kompatibilitas pada Server Tujuan

Sebelum mentransfer data produksi, jalankan lingkungan baru dan validasi kompatibilitas menggunakan pendekatan staging.

Verifikasi Versi PHP dan Ekstensi

# On the destination server
php -v
php -m | grep -E 'mbstring|curl|gd|imagick|redis|zip|intl|opcache'

Bandingkan output ini dengan inventaris Anda dari Fase 1. Ekstensi yang hilang harus diinstal sebelum migrasi, bukan setelahnya.

Pemeriksaan Kompatibilitas Database

Jika bermigrasi dari MySQL 5.7 ke MySQL 8.0 (skenario umum), perhatikan perubahan yang merusak ini:

• Charset utf8mb3 sudah tidak digunakan lagi; kolom mungkin memerlukan deklarasi charset eksplisit
• Perilaku GROUP BY berubah — kueri yang berfungsi di 5.7 mungkin gagal di 8.0 tanpa penyesuaian mode ONLY_FULL_GROUP_BY
• NO_ZERO_DATE diaktifkan secara default dalam strict mode, yang menolak field tanggal yang berisi 0000-00-00

Uji dump SQL Anda terhadap versi MySQL tujuan sebelum beralih ke traffic produksi.

Terjemahan Konfigurasi Web Server

Jika bermigrasi dari Apache ke Nginx (skenario umum saat berpindah ke VPS yang dioptimalkan untuk performa), aturan .htaccess Anda tidak otomatis diterjemahkan. Konversi umum:

Redirect .htaccess Apache:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

Ekuivalen Nginx dalam blok server:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$host$request_uri;
}

Melewatkan terjemahan ini adalah salah satu penyebab paling umum error 404 dan redirect loop pasca-migrasi.

Fase 5: Eksekusi Migrasi dengan Minimalisasi Downtime

Pilih Jendela Migrasi Secara Strategis

Analisis Google Analytics atau log server Anda untuk mengidentifikasi jendela traffic terendah — biasanya antara pukul 02:00 dan 05:00 di zona waktu audiens utama pada hari Selasa atau Rabu. Hindari hari Jumat; jika ada yang salah, opsi dukungan Anda menyempit secara signifikan selama akhir pekan.

Alur Kerja Migrasi Staging-First

1. Arahkan subdomain ke server baru (misalnya, staging.example.com) menggunakan A record, tanpa menyentuh DNS produksi
2. Transfer semua file dan database ke server baru
3. Perbarui string koneksi database aplikasi untuk menunjuk ke database baru
4. Modifikasi file /etc/hosts lokal Anda untuk me-resolve domain produksi ke IP server baru — ini memungkinkan Anda menguji konfigurasi produksi penuh tanpa mempengaruhi pengguna live:

# Add to /etc/hosts on your local machine
203.0.113.50  example.com www.example.com

1. Jalankan pengujian fungsional penuh — setiap formulir, alur pembayaran, sistem login, endpoint API, dan unggahan media
2. Jalankan benchmark performa menggunakan ab (Apache Benchmark) atau wrk:

ab -n 1000 -c 50 https://example.com/

1. Hanya setelah semua pengujian lulus, lanjutkan ke peralihan DNS

Konfigurasi Sertifikat SSL

Pastikan sertifikat SSL Anda terinstal dan tervalidasi di server baru sebelum peralihan DNS. Jika menggunakan Let’s Encrypt:

certbot --nginx -d example.com -d www.example.com

Jika menggunakan sertifikat komersial dari penyedia seperti yang tersedia melalui SSL Certificates, instal full certificate chain (sertifikat + CA perantara + CA root) untuk menghindari error validasi chain pada klien lama.

Fase 6: Peralihan DNS — Langkah Paling Sensitif Secara Teknis

Propagasi DNS sering disalahpahami. Angka 48 jam adalah batas kasus terburuk, bukan durasi tipikal. Dalam praktiknya, sebagian besar resolver menghormati nilai TTL dari record yang diubah.

Pengurangan TTL Pra-Peralihan

Setidaknya 24–48 jam sebelum jendela migrasi, kurangi TTL pada A record dan CNAME record Anda menjadi 300 detik (5 menit):

example.com.    300  IN  A  203.0.113.50
www.example.com. 300 IN  A  203.0.113.50

Ini berarti setelah Anda memperbarui record ke IP baru, nilai cache lama kedaluwarsa dalam 5 menit untuk sebagian besar resolver — bukan 48 jam. Ini adalah teknik paling berdampak untuk meminimalkan jendela propagasi DNS.

Pembaruan Name Server vs. A Record

Ada dua pendekatan peralihan DNS yang berbeda:

• Ubah A record saja (sambil mempertahankan nameserver otoritatif yang sama): Propagasi mengikuti TTL record. Pendekatan tercepat jika registrar domain Anda memungkinkan manajemen record langsung.
• Ubah nameserver (arahkan ke DNS host baru): TTL nameserver biasanya 24–48 jam dan tidak berada di bawah kendali langsung Anda. Pendekatan ini membutuhkan waktu lebih lama.

Utamakan pembaruan A record jika memungkinkan. Kelola DNS domain Anda melalui panel kontrol Domain Registration untuk kontrol langsung di tingkat record.

Menjaga Server Lama Aktif Selama Propagasi

Jangan batalkan atau matikan paket hosting lama segera setelah peralihan DNS. Pertahankan selama minimal 72 jam. Selama propagasi, sebagian pengguna Anda masih akan me-resolve ke IP lama — permintaan tersebut harus terus dilayani. Mematikan server lama sebelum waktunya menciptakan pemadaman nyata bagi pengguna tersebut.

Fase 7: Pemantauan dan Validasi Pasca-Migrasi

Pemantauan Uptime dan Performa

Konfigurasikan pemantauan uptime eksternal segera setelah peralihan DNS — bukan setelah Anda pikir propagasi selesai. Alat yang perlu digunakan:

• UptimeRobot atau Better Uptime — pemeriksaan HTTP(S) setiap 1–5 menit dari beberapa lokasi geografis
• Google Search Console — pantau laporan Coverage dan Core Web Vitals untuk anomali dalam 7 hari pasca-migrasi
• New Relic atau Datadog — pemantauan performa tingkat aplikasi jika aplikasi Anda memerlukannya

Mengidentifikasi dan Menyelesaikan Error Pasca-Migrasi

Jalankan crawl situs baru segera menggunakan Screaming Frog atau mirror wget:

wget --spider --recursive --no-verbose --output-file=crawl_log.txt https://example.com
grep -i "broken|404|error" crawl_log.txt

Masalah umum pasca-migrasi dan penyebabnya:

Memperbaiki URL yang Di-Hardcode dalam Database WordPress

Masalah yang sering dan halus: WordPress menyimpan URL situs dalam database, dan banyak tema serta plugin menyimpan URL absolut dalam data terserialisasi. Setelah migrasi ke domain atau protokol baru, jalankan:

wp search-replace 'http://old-domain.com' 'https://new-domain.com' 
  --all-tables 
  --precise 
  --report-changed-only

Flag --precise menangani data terserialisasi PHP dengan benar, yang rusak jika dilakukan penggantian string secara naif.

Fase 8: Batalkan Paket Hosting Lama

Batalkan paket lama hanya setelah semua kondisi berikut dikonfirmasi:

• Propagasi DNS selesai (verifikasi dengan dig +trace example.com dari beberapa lokasi)
• Pemantauan uptime menunjukkan ketersediaan 100% selama minimal 72 jam berturut-turut
• Tidak ada error 404 atau broken link yang terdeteksi dalam log crawl
• Pengiriman email berfungsi dengan benar di server baru
• Analytics menunjukkan pola traffic normal tanpa penurunan yang tidak wajar
• Anda memiliki salinan lokal semua file backup yang independen dari kedua penyedia hosting

Daftar Periksa Teknis Utama

Gunakan ini sebagai daftar periksa eksekusi migrasi Anda:

Pra-Migrasi

• [ ] Mengekspor baseline penggunaan sumber daya 90 hari (CPU, RAM, I/O, bandwidth)
• [ ] Mendokumentasikan software stack lengkap dengan nomor versi yang tepat
• [ ] Mengurangi DNS TTL menjadi 300 detik setidaknya 24 jam sebelum peralihan
• [ ] Membuat dan menguji backup penuh (file + database + cron job + email)
• [ ] Memvalidasi versi PHP dan semua ekstensi yang diperlukan di server tujuan
• [ ] Menerjemahkan aturan .htaccess ke format Nginx jika beralih web server
• [ ] Menginstal dan memvalidasi sertifikat SSL di server baru sebelum perubahan DNS

Selama Migrasi

• [ ] Mentransfer file menggunakan rsync dengan verifikasi checksum (rsync -avz --checksum)
• [ ] Mengimpor database dan memverifikasi jumlah baris sesuai dengan sumber
• [ ] Menguji fungsionalitas situs penuh melalui override /etc/hosts sebelum perubahan DNS
• [ ] Memperbarui file konfigurasi aplikasi (host database, kredensial, URL situs)

Pasca-Migrasi

• [ ] Pemantauan uptime eksternal aktif dalam 5 menit setelah peralihan DNS
• [ ] Server lama tetap berjalan minimal 72 jam pasca-peralihan
• [ ] Crawl situs penuh selesai; semua 404 dan broken link diselesaikan
• [ ] URL yang di-hardcode diperbaiki dalam database (terutama untuk WordPress)
• [ ] Google Search Console dipantau selama 7 hari pasca-migrasi
• [ ] Paket hosting lama dibatalkan hanya setelah semua item di atas dikonfirmasi

Pertanyaan yang Sering Diajukan

Berapa lama propagasi DNS sebenarnya berlangsung, dan bisakah saya mempercepatnya?

Durasi propagasi DNS ditentukan oleh nilai TTL dari record yang diubah, bukan jendela tetap 48 jam. Jika Anda mengurangi TTL A record menjadi 300 detik setidaknya 24 jam sebelum migrasi, sebagian besar resolver akan mengambil IP baru dalam 5–10 menit setelah perubahan. Angka 48 jam berlaku untuk perubahan delegasi nameserver, yang memiliki TTL di luar kendali Anda.

Apakah migrasi ke host baru akan merusak peringkat pencarian Google saya?

Migrasi yang dieksekusi dengan benar tanpa downtime, struktur URL yang terjaga, dan SSL yang valid tidak memiliki dampak negatif pada SEO. Peringkat dapat turun sementara jika server baru lebih lambat, jika URL berubah tanpa redirect 301 yang tepat, atau jika situs tidak dapat diakses selama crawling. Pantau laporan Coverage dan Core Web Vitals Google Search Console selama 14 hari pasca-migrasi.

Apa cara paling aman untuk mentransfer database besar tanpa merusak data?

Gunakan mysqldump dengan flag --single-transaction untuk tabel InnoDB guna memastikan snapshot yang konsisten tanpa table lock. Transfer file dump melalui SSH menggunakan scp atau rsync daripada phpMyAdmin, yang memiliki batasan ukuran file dan kendala timeout yang menyebabkan pemotongan diam-diam pada database besar.

Apakah saya perlu menginstal ulang sertifikat SSL setelah migrasi?

Ya. Sertifikat SSL terikat pada private key server, yang berada di server asli. Anda harus menerbitkan ulang sertifikat di server baru (gratis untuk Let’s Encrypt) atau mengekspor private key dan certificate chain dari server lama dan menginstalnya di server baru. Pastikan sertifikat tervalidasi penuh sebelum memperbarui DNS, sehingga HTTPS langsung berfungsi setelah peralihan.

Bagaimana cara memverifikasi bahwa migrasi saya selesai sebelum membatalkan paket lama?

Jalankan dig +trace example.com @8.8.8.8 dan dig +trace example.com @1.1.1.1 untuk mengonfirmasi bahwa resolver Google dan Cloudflare mengembalikan IP server baru. Periksa pemantauan uptime selama 72 jam berturut-turut dengan respons yang bersih. Crawl situs untuk error 404 dan verifikasi pengiriman email. Hanya setelah semua ini lulus, aman untuk mengakhiri akun hosting lama.