Pindah Website dari Server Ubuntu Non-Panel ke cPanel: Panduan Lengkap Migrasi File dan MySQL dengan Aman

Pas aku baru dua tahun kerja di posisi NOC, ada satu job yang sampai sekarang masih keinget jelas. Klien nelpon jam sembilan pagi, nadanya panik banget. Website-nya harus pindah dari server Ubuntu yang dulu dirakit manual sama developer lamanya, ke hosting cPanel yang baru. Dan dia cuma kasih dua hal: username SSH sama password.

Nggak ada dokumentasi, nggak ada catatan path, bahkan nggak ada yang tau website-nya ditaruh di folder mana. Bayangin. Aku harus ngorek server itu satu-satu, dari config Apache sampai isi folder /home, cuma buat nemu domain dan document root-nya. Dari situlah aku belajar: migrasi itu sebenernya gampang, yang susah itu nyari barangnya dulu.

Kenapa Kasus Kayak Gini Sering Banget Ketemu

Masalahnya bukan cuma di “file-nya di mana”, tapi banyak layer lain yang ikutan ruwet. Server Ubuntu non-panel itu ibarat rumah yang dibangun sendiri sama tukang yang udah pindah — layout-nya cuma dia yang tau. Kadang website nyasar di /var/www/html, kadang di /home/site-lama-client.com, bahkan pernah ketemu di folder backup lama yang udah bukan siapa-siapa. Karena nggak ada panel, konfigurasi vhost dan database biasanya diracik manual satu-satu. Jadi pas diminta pindah, kita jalan mundur kayak detektif: buka config, baca ServerName, cari DocumentRoot, baru tau apa aja yang harus dibawa.

Yang bikin makin pelik, server macam ini biasanya udah jalan bertahun-tahun dan ditinggali beberapa domain sekaligus. Kadang satu server isi 5-6 website. Nah, kalau cuma satu yang dimigrasi, kita harus jago milah-milah mana file yang mana. Ini soal ketelitian, bukan cuma soal teknis. Sekali salah tarik, website yang masih stay di server lama ikut ganggu.

Impact-nya kalau salah langkah? Lumayan serem. Website down, email kacau, database corrupt, atau yang paling sering: lupa kalau file website dan database MySQL itu dua barang beda yang harus sama-sama dibawa. Trust user langsung drop, revenue ikut turun, dan yang nggak kalah penting, reputasi kita sebagai engineer ikut dipertaruhkan. Makanya aku selalu bilang ke tim: migrasi itu 70% persiapan, 30% eksekusi. Dan persiapan yang benar dimulai dari tau persis apa yang kita punya di server lama.

Mari aku kasih analogi dulu biar makin paham. Bayangin kamu mau pindah rumah. Server Ubuntu non-panel itu kayak rumah kontrakan yang kamu desain sendiri: semua barang ada di tempat yang cuma kamu yang tau. cPanel itu kayak apartemen ber-manajemen, semua ada lokernya dan rapi. Sebelum pindah, kamu harus inventaris dulu barang kamu di mana aja. Kalau nggak, di rumah baru nanti banyak yang ketinggalan. Migrasi website persis kayak gitu, cuma barangnya berupa file PHP, database MySQL, dan konfigurasi domain yang numpang di file config.

Persiapan Sebelum Eksekusi

Sebelum nyentuh apa-apa, siapin dulu barang-barang ini:

• SSH access ke server Ubuntu lama (root atau user dengan sudo). Kalau nggak ada, minta dulu ke yang ngelola.
• Akses ke WHM/cPanel server baru: login credentials, dan tau nama akun cPanel yang bakal dipakai.
• Kontak pemilik domain, buat ngatur DNS nanti. Ini penting banget, sering dilupain.
• IP publik kedua server: server lama buat referensi, server baru buat tes pakai /etc/hosts nanti.
• Screen atau tmux kalau transfer datanya gede. Percaya deh, jaringannya bisa putus di tengah jalan.

Oh ya, satu lagi. Catat semua yang kamu temukan dalam file catatan. Aku biasanya bikin checklist lokal kayak gini: domain, IP server lama, document root, engine (Apache/Nginx), versi PHP, daftar database, daftar cron job, dan config khusus (redirect, .htaccess, dsb). Percaya, di tengah pusing-pusingnya, catatan ini bakal nyelametin kamu.

Langkah 1: Temukan Domain dan Document Root di Server Ubuntu

Ini bagian yang paling sering bikin orang nyerah. Tapi tenang, caranya sistematis. Pertama, login SSH ke server lama, terus identifikasi web server yang dipakai.

Cek Web Server dan Vhost di Apache

Kalau server pakai Apache, vhost-nya biasanya ada di /etc/apache2/sites-enabled/ atau /etc/httpd/conf.d/ (kalau pakai CentOS — tapi ini kan Ubuntu, jadi fokus ke yang pertama). Ini perintahnya:

ls -la /etc/apache2/sites-enabled/

Terus, buka satu-satu file config-nya. Biasanya di dalemnya ada ServerName dan DocumentRoot kayak gini:

grep -RE "ServerName|DocumentRoot" /etc/apache2/sites-enabled/

Output-nya kira-kira:

/etc/apache2/sites-enabled/site-lama-client.com.conf: ServerName site-lama-client.com
/etc/apache2/sites-enabled/site-lama-client.com.conf: ServerAlias www.site-lama-client.com
/etc/apache2/sites-enabled/site-lama-client.com.conf: DocumentRoot /home/site-lama-client.com/public_html

Nah, itu dia. Domain-nya site-lama-client.com, dan document root-nya ada di /home/site-lama-client.com/public_html. Tapi kadang nggak serepot ini. Kalau DocumentRoot-nya nggak ketulis eksplisit, atau pakai vhost wildcard, kamu bisa cek arah DocumentRoot ke mana dengan:

grep -R "DocumentRoot" /etc/apache2/sites-available/ | sort -u

Dan kalau Apache-nya pakai port 443 (HTTPS), jangan lupa cek juga file config SSL-nya. Kadang document root buat HTTPS beda sendiri.

Cek Web Server dan Vhost di Nginx

Kalau ternyata pakai Nginx, config-nya ada di /etc/nginx/sites-enabled/ atau /etc/nginx/conf.d/. Cari server_name dan root:

grep -RE "server_name|root " /etc/nginx/sites-enabled/

Contoh output:

/etc/nginx/sites-enabled/site-lama-client.com: server_name site-lama-client.com www.site-lama-client.com;
/etc/nginx/sites-enabled/site-lama-client.com: root /var/www/site-lama-client.com;

Kalau nggak ketemu juga, cek di file utama /etc/nginx/nginx.conf, atau cari semua file yang ngandung nama domain:

grep -R "site-lama-client.com" /etc/nginx/

Cek DNS dan /etc/hosts

Kalau dari config nggak nemu, jangan panik. Cek arah DNS domain-nya masih ke server ini atau nggak. Dari laptop atau server mana aja:

dig +short site-lama-client.com
dig +short www.site-lama-client.com

Kalau IP yang keluar sama dengan IP server lama, berarti DNS masih nunjuk ke sini. Itu bagus, artinya kamu bisa cek langsung. Terus cek juga /etc/hosts di server lama, siapa tau domainnya diarahkan manual:

cat /etc/hosts

Lha, kalau di sana ada entry kayak “203.0.113.10 site-lama-client.com”, berarti ada pengalihan manual yang harus ikut dipindah nanti.

Cek Siapa yang Dengerin Port 80

Alternatif terakhir yang jujur-jujur ampuh: cek siapa yang lagi dengerin port 80 dan 443 di server itu.

sudo ss -tlnp | grep -E ":80|:443"

Output:

LISTEN 0 511 0.0.0.0:80 0.0.0.0:* users:(("apache2",pid=1234,fd=4))
LISTEN 0 511 0.0.0.0:443 0.0.0.0:* users:(("apache2",pid=1234,fd=5))

Dari situ kamu bisa mastiin web server apa yang aktif. Dan kalau penasaran isi website-nya, bisa cek langsung:

curl -sI http://site-lama-client.com | head -20

Itu bakal nunjukin header server, dan biasanya sekalian nunjukin apakah dia nge-serve langsung atau lewat proxy.

Langkah 2: Kenali Isi Website

Setelah nemu document root, masuk ke sana dan intip isinya:

ls -la /home/site-lama-client.com/public_html/

Dari isi foldernya kamu bisa nebak CMS-nya. Ada wp-config.php? Berarti WordPress. Ada artisan atau .env? Berarti Laravel. Ada application/config/database.php? Berarti CodeIgniter. Cek juga file .htaccess kalau ada, karena isinya suka ada rewrite rules penting yang harus ikut dibawa:

cat /home/site-lama-client.com/public_html/.htaccess

Catat juga versi PHP yang dipakai server lama, biar nanti di cPanel bisa diset sama. Cek dengan:

php -v

Hmm, kadang php -v yang muncul beda sama yang dipakai vhost. Paling akurat ya dari config vhost-nya (kalau Apache pakai php-fpm, biasanya ada set handler). Tapi minimal kamu punya gambaran.

Langkah 3: Backup File Website (Wajib Sebelum Apa-Apa)

Buat arsip file website dari document root yang barusan kamu temukan. Dari server lama, masuk ke direktori induk dulu biar path di dalam tar nggak aneh:

cd /home
tar -czf /tmp/site-lama-client.com-files-$(date +%Y%m%d).tar.gz site-lama-client.com/

Jangan lupa include file tersembunyi kayak .htaccess, .env, dan .user.ini. Tar default udah ikut, tapi pastiin aja. Habis itu, verifikasi arsipnya bener dan nggak kosong:

ls -lh /tmp/site-lama-client.com-files-*.tar.gz
tar -tzf /tmp/site-lama-client.com-files-*.tar.gz | head -30

Pastikan ada .htaccess di daftar. Kalau nggak ada, berarti file itu nggak kebackup — dan ini bahaya, karena di cPanel .htaccess itu bisa nentuin hidup-matinya website.

Langkah 4: Backup Database MySQL

Dua barang wajib: file website DAN database. Kalau cuma bawa file, nanti website-nya jadi kerangka kosong. Lihat dulu database apa aja yang ada di server:

mysql -u root -p -e "SHOW DATABASES;"

Atau kalau nggak bisa login root, coba pakai user yang ada di file config aplikasinya. Contohnya buat WordPress, buka wp-config.php dan catat DB_NAME, DB_USER, DB_PASSWORD:

grep "DB_" /home/site-lama-client.com/public_html/wp-config.php

Nah, dari situ kamu tau database apa yang relevan. Terus dump databasenya. Penting: dump per-database biar restore-nya di cPanel gampang:

mysqldump -u root -p --single-transaction --routines --triggers client_production > /tmp/client_production-$(date +%Y%m%d).sql

Buat yang ukurannya gede banget, bisa dipecah per tabel, atau pakai kompresi pas dump:

mysqldump -u root -p --single-transaction --routines --triggers client_production | gzip > /tmp/client_production-$(date +%Y%m%d).sql.gz

Verifikasi lagi, jangan sampai file SQL-nya kosong. Pastikan ada baris CREATE TABLE dan INSERT di dalamnya:

grep -c "INSERT INTO" /tmp/client_production-*.sql

Kalau angkanya nol, dump kamu gagal. Jangan lanjut sebelum ini bener, nggih.

Langkah 5: Kirim File dan SQL ke Server cPanel

Sekarang data udah di /tmp di server lama. Kirim ke server baru pakai scp atau rsync. Dari server cPanel (atau dari server lama, dua-duanya boleh, tergantung arah jaringan yang terbuka). Contohnya dari server cPanel:

scp root@203.0.113.10:/tmp/site-lama-client.com-files-*.tar.gz /home/client_user/
scp root@203.0.113.10:/tmp/client_production-*.sql.gz /home/client_user/

Atau kalau file-nya gede, rsync lebih tahan banting (bisa lanjut kalau putus):

rsync -avzP root@203.0.113.10:/tmp/ /home/client_user/migrasi-tmp/

Jangan lupa verifikasi file sampe dengan bandingin ukurannya. Kalau ukuran beda dikit aja, file rusak di tengah jalan:

ls -lh /home/client_user/site-lama-client.com-files-*.tar.gz

Langkah 6: Restore di cPanel — File dan Database

Upload dan Extract File ke public_html

Login ke cPanel akun yang bakal dipakai. Pertama, setup dulu addon domain atau subdomain yang sesuai di bagian “Domains” — jadi nanti public_html-nya (atau folder addon-nya) udah kebentuk. Nah, setelah itu upload arsip tar.gz ke folder document root tadi via File Manager atau SFTP.

Terus extract. Kalau pakai terminal, contohnya buat akun cPanel dengan document root di /home/client_user/public_html:

cd /home/client_user/public_html
tar -xzf /home/client_user/site-lama-client.com-files-*.tar.gz

Perhatiin struktur foldernya. Kalau di server lama document root-nya isinya langsung file-file website (index.php, wp-config.php), di cPanel juga harusnya isi folder public_html langsung file-file itu, bukan folder site-lama-client.com di dalamnya. Kalau ketemu folder bersarang kayak gitu, pindahin isinya satu level ke atas. Ini kesalahan paling umum saat migrasi, dan sering bikin orang bingung kok website-nya 404.

Buat Database di cPanel dan Import SQL

Di cPanel, masuk ke “MySQL Databases”, buat database baru, user baru, dan attach user ke database dengan all privileges. Catat nama database dan user-nya — biasanya diprefix sama username akun, kayak client_user_dbname. Terus import file SQL-nya. Di “phpMyAdmin”, pilih database yang barusan dibuat, klik tab “Import”, pilih file .sql atau .sql.gz, jalan.

Atau kalau lewat terminal, import pakai mysql client:

cd /home/client_user
gunzip -k client_production-*.sql.gz
mysql -u client_user_dbuser -p client_user_dbname < client_production-20260730.sql

Pastikan nggak ada error kayak “database already exists” atau “duplicate entry” yang fatal. Kalau ada, balik lagi ke file SQL-nya, jangan dibiarkan.

Langkah 7: Sesuaikan Konfigurasi Aplikasi

Ini langkah yang sering bikin orang berhenti di tengah jalan. File website udah pindah, database udah import, tapi kok website error? Karena config aplikasinya masih nunjuk ke server lama. Perbaiki sesuai CMS-nya.

WordPress — edit wp-config.php:

define('DB_NAME', 'client_user_dbname');
define('DB_USER', 'client_user_dbuser');
define('DB_PASSWORD', 'password-baru-di-cpanel');

Dan kalau URL-nya berubah, bisa set di wp_options lewat phpMyAdmin (update option_value untuk siteurl dan home), atau tambahin baris ini di wp-config.php biar nggak rebutan:

define('WP_HOME', 'https://site-lama-client.com');
define('WP_SITEURL', 'https://site-lama-client.com');

Laravel — edit file .env:

DB_DATABASE=client_user_dbname
DB_USERNAME=client_user_dbuser
DB_PASSWORD=password-baru

Abis itu jalanin migrate dan storage permission biar upload gambar nggak eror. Buat CMS lain, tinggal cari file config database-nya, perbaiki kredensial yang sama.

Jangan lupa juga cek .htaccess atau file konfigurasi nginx yang dibawa, karena rewrite rules di dalamnya bisa nunjuk path lama. Oh ya, dan set versi PHP di cPanel (menu “MultiPHP Manager”) biar sama kayak di server lama. PHP version mismatch ini salah satu penyebab website blank page paling umum pasca-migrasi.

Langkah 8: Arahkan DNS dan Potong ke Server Baru

Sebelum cutover, tes dulu website dari server baru tanpa ngubah DNS. Edit /etc/hosts di laptop kamu (atau di server sementara):

203.0.113.20 site-lama-client.com www.site-lama-client.com

Ganti 203.0.113.20 dengan IP server cPanel yang baru. Lalu buka browser, atau cek dari curl:

curl -sI http://site-lama-client.com | head -10

Kalau udah merespons dan HTML-nya muncul, lanjut potong DNS. Kurangi dulu TTL record di DNS provider ke nilai kecil (misal 300 detik) sehari sebelumnya, biar pas cutover perubahan cepet nyebar. Terus ganti A record site-lama-client.com (dan www) ke IP cPanel. Tunggu propagasi, dan tes dari beberapa jaringan.

Setelah dipastikan semua oke, jangan langsung hapus data di server lama. Biarin dulu beberapa hari sampai propagasi DNS tuntas dan semua aman. Habis itu baru bersihin.

Langkah 9: Verifikasi Akhir Sebelum Serah Terima

Sebelum close ticket, cek checklist ini satu-satu:

• Website kebuka normal via domain (bukan cuma via /etc/hosts).
• Semua halaman penting: homepage, halaman produk, kontak, form submission.
• Gambar dan file statis kebuka (cara cepet: cek satu-dua URL file gambar).
• Login admin/CMS jalan, dan bisa nyimpen data.
• HTTPS/SSL aktif — pasang sertifikat lewat AutoSSL di WHM atau manual di cPanel.
• Email domain jalan kalau memang ikut pindah.
• Cron job di server lama dipindah ke cPanel (menu “Cron Jobs”) — ini sering kelupaan!

Kalau semua ijo, berarti migrasi kelar. Oh ya, satu lagi yang sering dilupain: cek versi PHP dan ekstensi yang dibutuhin CMS (misal mysqli, gd, mbstring). Kalau kurang, install di cPanel atau hubungi support.

Tabel Troubleshooting: Error yang Sering Muncul Setelah Migrasi

Pro Tips dari Lapangan

• Selalu catat config lama sebelum ngubah apa-apa. Makan waktu 5 menit, nyelametin berjam-jam.
• Kalau bisa, tes dulu di staging sebelum DNS dipotong. Jangan jadiin production server sebagai tempat uji coba.
• Kalau transfernya lewat internet publik, pakai rsync + SSH. Dan pastikan pakai akses yang aman, jangan copy-paste password di chat publik.
• Buat database di cPanel dengan nama yang gampang dikaitin, dan simpan password di password manager. Jangan di post-it.
• Kalau ada email service aktif di server lama, jangan matiin server sebelum semua pengguna email dipastikan pindah.
• Set versi PHP SAMA persis kayak server lama kalau aplikasinya aplikasi lama yang sensitif. Update versi PHP bisa nunggu fase berikutnya.

FAQ

Artikel Terkait

• Panduan lengkap migrasi VPS KVM dengan zero-downtime
• Troubleshooting MySQL crash di VPS RAM kecil
• Cara troubleshooting high load di server cPanel
• Cara cek sertifikat SSL sebelum expired

Penutup

Jadi gitu cerita aku dulu. Awalnya ngeri, ternyata kalau tau caranya, migrasi website dari server Ubuntu non-panel ke cPanel itu cuma soal: nemu barangnya (document root dan database), bungkus rapi, pindahin, terus pasang lagi di tempat baru. Kuncinya satu: persiapan. Jangan pernah buru-buru eksekusi sebelum kamu yakin semua barang udah ketemu dan kebackup.

Kalau kamu lagi di posisi kayak aku dulu, semoga artikel ini nyelametin kamu. Dan kalau nanti nemu kasus unik yang belum kejadian di sini, cerita dong di kolom komentar — siapa tau bisa bantu NOC engineer lain yang lagi ngorek server sepi di tengah malam.