Cara yang lebih aman untuk memigrasikan Laravel dari shared hosting ke VPS adalah menyiapkan server baru secara paralel, menguji aplikasi sebelum traffic dialihkan, lalu melakukan controlled cutover. Pada tahap cutover, write traffic ke server lama perlu dihentikan sementara, scheduler dan queue worker dihentikan, final file/database sync dilakukan, lalu qVM baru divalidasi sebelum production dibuka kembali. Pendekatan ini tidak menjanjikan zero downtime, tetapi membantu menjaga satu source of truth untuk data selama perpindahan.
Transparansi AI. Artikel ini disusun dengan bantuan AI untuk riset dan drafting, kemudian ditinjau dan disunting oleh tim Sequel Cloud untuk memastikan akurasi teknis dan relevansi isi.
Intisari Artikel
- Parallel preparation membantu memindahkan pekerjaan setup dan testing ke server baru tanpa langsung mengganggu production lama.
- Jangan membiarkan dua database independen menerima production writes secara bebas saat cutover; tentukan source of truth dan gunakan write freeze untuk final sync.
- Checklist migrasi harus mencakup runtime, backup, queue/scheduler, DNS, SSL, firewall, external integrations, monitoring, dan rollback boundary.
- Dalam panduan ini, target migration menggunakan qVM Sequel. aaPanel dapat dipakai jika tim ingin workflow berbasis control panel yang lebih familiar setelah pindah dari shared hosting.
Sebelum Mulai: Pastikan Target VPS Sudah Benar
Migrasi sebaiknya tidak menjadi tempat untuk menebak-nebak resource. Sebelum membuat qVM tujuan, tentukan lebih dulu kebutuhan CPU, RAM, storage, dan headroom dari workload Laravel yang benar-benar dijalankan.
Jika resource target belum jelas, selesaikan dulu panduan Spesifikasi VPS untuk Laravel: Cara Menentukan CPU, RAM, Storage, dan Budget.
Mental Model: Prepare in Parallel, Cut Over Once
Tujuan parallel preparation bukan menjalankan dua production database secara bebas. Tujuannya adalah memindahkan pekerjaan setup, transfer awal, dan testing ke qVM baru sementara shared hosting lama tetap menjadi production source of truth.
Source of truth baru berpindah ketika cutover dilakukan.
Source of truth sebaiknya berpindah sekali, pada boundary cutover yang jelas.
Fase 0 — Tentukan Source of Truth dan Cutover Strategy
Untuk tutorial ini, kita menggunakan controlled maintenance/write freeze. Ini berbeda dengan active-active database migration atau replication-based cutover yang membutuhkan architecture dan procedure tersendiri.
- Tentukan kapan shared hosting masih menjadi source of truth.
- Tentukan kapan write traffic akan dihentikan sementara.
- Tentukan siapa PIC yang memberi keputusan GO / NO-GO.
- Tentukan rollback threshold sebelum eksekusi dimulai.
- Tentukan kapan qVM resmi menjadi source of truth baru.
Fase 1 — Audit Environment Lama
Sebelum menyentuh qVM, inventarisasi seluruh komponen yang membuat Laravel benar-benar berjalan di production.
| Area | Yang perlu dicatat |
|---|---|
| Runtime | Laravel version, PHP version, extension, Composer dependency, web server. |
| Database | Engine/version, ukuran database, storage engine, user/privilege, connection config. |
| Application state | .env, APP_KEY, cache/session driver, uploads, storage paths. |
| Background process | Laravel Scheduler, cron, queue worker, Horizon, Supervisor/systemd, websocket/long-running process. |
| External dependency | SMTP, payment gateway, webhook, SMS/WhatsApp, API pihak ketiga, object storage/CDN. |
| DNS | A/AAAA/CNAME record yang berhubungan dengan aplikasi, API, subdomain, dan layanan lain. |
Fase 2 — Backup dan Restore Readiness
Backup bukan hanya pekerjaan “file sudah berhasil dibuat”. Backup baru berguna jika tim tahu bagaimana mengembalikannya.
- Backup database berhasil dibuat.
- Backup application files dan persistent uploads tersedia.
- Configuration/secrets disimpan secara aman.
- Ukuran dan timestamp backup masuk akal.
- Restore procedure diketahui.
- Untuk workload critical, lakukan test restore atau minimal validasi dump dapat dibaca.
Fase 3 — Siapkan qVM Tujuan di Console Sequel
Environment tujuan pada tutorial ini menggunakan qVM Sequel. Detail pemesanan lengkap tetap tersedia di KB Cara Pesan Layanan qVM di Console Sequel; di artikel ini kita fokus pada langkah yang relevan dengan migration.
1. Pilih Project lalu buka Virtual Machine
Login ke Console Sequel, pilih project yang benar, lalu buka menu Virtual Machine.
Console Sequel — menu Virtual Machine di dalam project.
2. Klik Create Virtual Machine
Tombol Create Virtual Machine pada Console Sequel.
3. Pilih flavor berdasarkan hasil sizing
Jangan menggunakan shortcut seperti “qVM-3 untuk kecil” atau “qVM-4 untuk menengah”. Pilih flavor berdasarkan target CPU, RAM, dan storage yang sudah ditentukan pada sizing.
Flavor qVM menampilkan vCPU, RAM, NVMe storage, dan estimasi biaya bulanan.
4. Pilih OS atau Marketplace image
Pilih operating system yang kompatibel dengan kebutuhan Laravel. Jika aaPanel sudah tersedia pada tab Marketplace, opsi ini dapat dipilih agar panel tidak perlu diinstal manual setelah VM dibuat.
Console Sequel menyediakan pemilihan operating system dan tab Marketplace pada tahap image selection.
5. Pilih authentication
Gunakan SSH Key untuk production jika workflow tim sudah mendukungnya. Console Sequel juga menyediakan password authentication.
Authentication qVM: SSH Key atau Password.
6. Tunggu VM Active dan catat IP
Setelah payment dan provisioning selesai, pastikan status VM sudah Active. Catat IP address serta username OS yang digunakan. Root username dinonaktifkan secara default; username login mengikuti image OS, misalnya ubuntu, debian, atau almalinux.
Detail VM yang sudah Active: status, spesifikasi, OS, IP address, dan project.
Dengan aaPanel atau Tanpa Control Panel?
Kalau sebelumnya terbiasa dengan shared hosting, salah satu perubahan terbesar saat pindah ke VPS adalah level control. Pindah ke VPS tidak berarti seluruh pekerjaan harus berubah menjadi command line.
Path A — Dengan aaPanel
- Workflow lebih familiar untuk tim yang terbiasa control panel.
- Website, PHP, database, SSL, file, dan service dapat dikelola melalui browser.
- Cocok sebagai transition path dari shared hosting ke VPS.
Path B — Tanpa Control Panel
- Nginx/Apache, PHP-FPM, database, certificate, dan process manager dikelola langsung.
- Cocok untuk tim yang nyaman dengan CLI dan server configuration.
- Tidak menambah control-panel layer ke stack.
aaPanel bukan requirement Laravel dan bukan performance guarantee. Panel hanya mengubah cara tim mengelola service. Setelah migration selesai, perbandingan lebih lengkap tersedia di aaPanel vs CloudPanel untuk Laravel.
Fase 4 — Samakan Environment Laravel
Environment baru tidak harus identik byte-per-byte dengan shared hosting lama, tetapi harus kompatibel dengan kebutuhan aplikasi.
- PHP version compatible dengan Laravel/application code.
- Required PHP extensions tersedia.
- Composer dapat menyelesaikan dependency production.
- Web server dan document root benar.
- Database version/engine compatible.
- Queue/runtime dependency siap.
Perlakukan .env sebagai configuration state, bukan file biasa
Gunakan konfigurasi lama sebagai baseline secara aman. Update value yang memang berubah seperti database host/credential, cache/session endpoint, mail configuration, atau storage path. Jangan mengganti APP_KEY tanpa memahami dampaknya, karena key tersebut digunakan Laravel untuk encryption dan continuity data tertentu.
Fase 5 — Initial File dan Database Copy
Application files
Pisahkan application code, persistent uploads, dependency, dan temporary files. Jangan memperlakukan seluruh directory sebagai satu jenis data.
rsync -avz --exclude '.env' --exclude 'vendor' /path/aplikasi/ user@IP_QVM:/path/aplikasi/Jika vendor tidak disalin, jalankan composer install --no-dev --optimize-autoloader di destination. Pastikan persistent upload seperti storage/app/public ikut ditangani sesuai architecture aplikasi.
Database initial copy
Untuk database InnoDB, mysqldump --single-transaction dapat digunakan untuk membuat consistent snapshot tanpa memblokir normal reads/writes seperti table lock biasa. Namun ini bukan incremental/delta sync.
mysqldump -u USER -p --single-transaction --quick NAMA_DATABASE > laravel-initial.sqlGunakan caveat: konsistensi --single-transaction berlaku untuk transactional tables seperti InnoDB. Hindari perubahan schema seperti ALTER TABLE, CREATE TABLE, DROP TABLE, RENAME TABLE, atau TRUNCATE TABLE selama dump.
Fase 6 — Test qVM Sebelum Cutover
Test server baru tanpa mengubah DNS global. Salah satu cara adalah hosts-file override pada laptop penguji.
IP_QVM domain-aplikasi.comSafety mode sebelum testing
- Production scheduler pada qVM masih disabled.
- Production queue worker/Horizon masih disabled.
- Email, payment, webhook, SMS/WhatsApp, atau external side effect diarahkan ke sandbox/disabled bila memungkinkan.
- Test data tidak dianggap sebagai production transaction.
Functional test
- Login berhasil.
- CRUD flow penting berjalan.
- Upload/download bekerja.
- Report penting dapat dibuka.
- Database connection normal.
- Storage permission benar.
- Application log tidak menunjukkan error kritis.
Checklist Migrasi Laravel: Pra-Migrasi, Cutover, dan Pasca-Migrasi
Checklist ini berfungsi sebagai runbook. Setiap fase memiliki exit criteria; jangan pindah fase hanya karena langkah sebelumnya “sepertinya sudah selesai”.
FASE A — PRA-MIGRASI
- Laravel, PHP, extension, Composer, web server, dan database version sudah dicatat.
- APP_KEY dan secret penting sudah diinventarisasi.
- Scheduler, cron, queue worker, Horizon, Supervisor/systemd, dan long-running process sudah diinventarisasi.
- SMTP, payment gateway, webhook, API, SMS/WhatsApp, object storage/CDN sudah dicatat.
- Backup database, application files, dan persistent uploads tersedia.
- Restore path diketahui; untuk workload critical, backup sudah diuji atau divalidasi.
- DNS record penting dicatat.
- TTL critical records sudah diturunkan jauh sebelum migration window sesuai current TTL.
- Target CPU/RAM/storage qVM sudah ditentukan.
- qVM Active dan login sudah berhasil.
- Firewall policy sudah direncanakan berdasarkan service yang benar-benar diperlukan.
- SSL issuance/migration plan sudah ditentukan.
- Cutover window, PIC, write-freeze plan, dan rollback threshold sudah disepakati.
FASE B — GO / NO-GO CUTOVER
- Backup verified dan restore path diketahui.
- qVM test path sudah lolos functional test.
- Final file sync command siap.
- Final database dump/restore command siap.
- Scheduler/queue state pada old dan new environment terdokumentasi.
- Write-freeze communication siap.
- DNS access tersedia.
- SSL plan siap.
- Rollback threshold sudah jelas.
- PIC cutover tersedia.
FASE C — PASCA-MIGRASI
- HTTPS valid dan certificate chain benar.
- HTTP→HTTPS redirect benar jika memang digunakan.
- Domain, API, dan subdomain penting mengarah ke destination yang benar.
- Firewall aktif dengan hanya service/port yang memang diperlukan architecture.
- SSH/admin access sesuai policy; temporary migration credentials dicabut bila tidak diperlukan.
- Database tidak terbuka ke public network tanpa kebutuhan.
- Scheduler berjalan hanya di environment baru.
- Queue worker/Horizon/Supervisor healthy.
- Email transactional, payment callback, webhook, API, dan integration lain diuji.
- CPU, RAM, storage capacity, disk I/O, PHP-FPM, queue backlog, dan logs dipantau.
- Real user flow seperti login, create/update, upload, report, atau checkout diuji sesuai aplikasi.
- Tidak ada unexplained data mismatch atau duplicate processing.
- Old server belum di-terminate sampai observation window selesai.
- Hosts-file override dan temporary migration rule sudah dibersihkan.
- Checklist dan perubahan environment didokumentasikan.
Fase 7 — Controlled Cutover
- Freeze application writes di shared hosting. Gunakan maintenance mode atau mekanisme lain yang benar-benar menghentikan new production writes.
- Stop scheduler dan background consumers. Hentikan cron/Laravel Scheduler, queue worker, Horizon, atau process lain yang dapat mengubah data.
- Final file sync. Sinkronkan persistent files yang berubah sejak initial copy.
- Final database dump dan restore. Ini final controlled sync; bukan “delta dump” sambil writes tetap aktif.
- Validate destination. Pastikan database dapat dibaca, Laravel boot normal, dan critical application flow dapat dibuka.
- Switch DNS/routing. Arahkan domain ke IP qVM baru sesuai DNS provider yang digunakan.
- Validate HTTPS/SSL. Pastikan certificate valid sebelum production dibuka penuh.
- Enable production di qVM. Keluar dari maintenance mode, lalu aktifkan scheduler dan queue worker pada environment baru.
Apa yang Terjadi Setelah DNS Diganti?
TTL rendah membantu memperpendek cache window resolver, tetapi tidak menjamin semua user berpindah tepat dalam lima menit. Sebagian local/upstream cache dapat membuat pengalaman aktual lebih lama.
Karena itu, jangan langsung menghapus shared hosting lama setelah A record diubah. Pertahankan environment lama selama observation window yang disepakati, tetapi jangan biarkan environment tersebut kembali menerima production writes setelah source of truth berpindah.
Referensi: Cloudflare DNS — Time to Live (TTL).
Rollback: Sebelum dan Sesudah qVM Menerima New Writes
Rollback sebelum qVM menerima production writes
Relatif sederhana karena database lama masih authoritative. Traffic dapat diarahkan kembali, lalu old scheduler/worker dipulihkan sesuai runbook.
Rollback setelah qVM menerima production writes
Jangan hanya mengembalikan DNS. Freeze terlebih dahulu, identifikasi new writes, tentukan authoritative dataset, lalu lakukan reconciliation atau reverse-sync procedure yang sesuai.
Post-Migration Validation: Technical dan Operational
Technical validation
- HTTP/HTTPS normal.
- Laravel boot tanpa critical error.
- Database reachable.
- Scheduler dan queue worker healthy.
- CPU, RAM, storage, PHP-FPM, queue backlog, dan logs dalam kondisi wajar.
Operational validation
- Real user dapat login.
- Flow create/update/delete yang memang dipakai bisnis berjalan.
- Upload/report/checkout sesuai application use case normal.
- Email/payment/webhook/integration external berfungsi.
- Tidak ada missing recent transaction atau duplicate processing.
Migration dianggap selesai ketika outcome operasional sudah tervalidasi, bukan hanya karena DNS sudah mengarah ke IP baru.
Kalau Laravel Sudah Siap Pindah, qVM Memberi Landing Zone yang Lebih Terkontrol
Setelah sizing menunjukkan bahwa VPS memang sesuai untuk workload, qVM memberi target environment yang bisa disiapkan lebih dulu melalui Console Sequel, diuji tanpa langsung mengubah production traffic, lalu digunakan sebagai destination saat controlled cutover.
qVM menggunakan NVMe storage, menyediakan kontrol server, resource scaling, monitoring, dan self-service provisioning melalui Console Sequel. Untuk workload Laravel yang sudah tidak nyaman berada di shared hosting, ini memberi ruang lebih besar untuk mengatur runtime, queue worker, database, security policy, dan deployment flow sesuai kebutuhan aplikasi.
qVM — destination VPS untuk Laravel yang sudah siap keluar dari shared hosting
Tentukan resource dari workload, provision qVM melalui Console Sequel, uji environment baru, lalu lakukan cutover saat semua checkpoint sudah terpenuhi.
Tidak Ingin Menjalankan Cutover Sendiri?
Untuk scope yang sesuai assessment, Sequel menyediakan free migration untuk 1 aplikasi + 1 database; kebutuhan tambahan seperti multiple application, multiple database, complex architecture, atau implementation scope lain dapat dikenakan biaya.
Jika kebutuhan tim tidak berhenti pada migrasi dan berlanjut ke pengelolaan infrastructure secara rutin, qManaged dapat dievaluasi sesuai scope layanan yang dibutuhkan. Tidak semua managed package memiliki coverage dan migration scope yang sama, jadi treatment-nya harus mengikuti assessment.
Glosarium
| Istilah | Bahasa Sederhana | Makna di Tutorial |
|---|---|---|
| Source of truth | Sumber data utama | Environment/database yang dianggap paling authoritative untuk production writes. |
| Write freeze | Hentikan perubahan data sementara | Window ketika aplikasi lama tidak lagi menerima new writes sebelum final sync. |
| Cutover | Pengalihan production | Momen traffic dan source of truth dipindahkan dari old environment ke qVM. |
| TTL | Waktu cache DNS | Menentukan berapa lama resolver dapat menyimpan DNS record sebelum bertanya ulang. |
| Rollback | Kembali ke kondisi sebelumnya | Procedure untuk membatalkan cutover dengan memperhatikan data yang mungkin sudah berubah. |
| rsync | Sinkronisasi file | Tool untuk menyalin file dan perubahan antar-host. |
| mysqldump | Logical database export | Tool MySQL untuk menghasilkan SQL dump yang dapat di-restore. |
| Queue worker | Pekerja background | Process yang menangani job Laravel di luar request web langsung. |
| Scheduler | Jadwal otomatis | Laravel Scheduler/cron yang menjalankan task terjadwal. |
| Provisioning | Membuat server | Proses membuat qVM sampai status Active. |
FAQ Migrasi Laravel ke VPS
Apakah migrasi Laravel bisa benar-benar tanpa downtime?
Bisa ada architecture yang mendekati zero downtime, tetapi tutorial ini tidak menjanjikannya. Untuk migration dari shared hosting ke qVM dengan database independen, controlled write freeze dan final sync memberi boundary data yang lebih mudah dipahami dan diuji.
Mengapa write traffic perlu dihentikan sebelum final database sync?
Agar database lama berhenti berubah ketika final snapshot dibuat. Tanpa boundary ini, old dan new database dapat menerima state yang berbeda sehingga source of truth menjadi tidak jelas.
Apakah APP_KEY Laravel boleh diganti saat migrasi?
Jangan menggantinya tanpa alasan dan impact assessment yang jelas. APP_KEY digunakan Laravel untuk encryption, sehingga perubahan key dapat memengaruhi data yang sebelumnya dienkripsi oleh aplikasi.
Apakah migrasi wajib menggunakan aaPanel?
Tidak. aaPanel adalah management layer opsional. Laravel dapat dikelola melalui control panel atau langsung melalui Nginx/Apache, PHP-FPM, database, process manager, dan CLI sesuai kemampuan tim.
Berapa lama server lama perlu dipertahankan?
Tidak ada angka universal. Pertahankan selama observation window yang cukup untuk memvalidasi technical health, integration, dan operational flow. Setelah qVM menerima writes, old server sebaiknya tidak kembali menerima production writes tanpa reconciliation plan.
Apakah Sequel menyediakan bantuan migrasi?
Free migration tersedia untuk scope 1 aplikasi + 1 database. Scope tambahan dapat dikenakan biaya dan perlu assessment lebih dulu.
Daftar Pustaka
- Cloudflare. (2026). Phase 2: Preparation. Cloudflare Learning Paths. https://developers.cloudflare.com/learning-paths/dns-best-practices/concepts/phase-2/
- Cloudflare. (2026). Time to Live (TTL). Cloudflare DNS Documentation. https://developers.cloudflare.com/dns/manage-dns-records/reference/ttl/
- Laravel. (n.d.). Configuration. Laravel Documentation. https://laravel.com/docs/13.x/configuration
- Laravel. (n.d.). Queues. Laravel Documentation. https://laravel.com/docs/13.x/queues
- Oracle. (n.d.). mysqldump — A database backup program. MySQL Reference Manual. https://dev.mysql.com/doc/refman/8.0/en/mysqldump.html