Inventarisasi proyek sebelum memesan pemindahan
Gunakan situs web pertanyaan ilustratif di client.example.com: editor mempublikasikan halaman proyek, pengunjung mengunggah brief, dan tugas terjadwal mengekspor pertanyaan ke sistem klien. Memindahkan halaman publiknya hanya akan mencakup sebagian pekerjaan. Konfirmasi akses yang diizinkan ke sumber dan tujuan, kontrol domain, dan salinan pemulihan sebelum menetapkan tanggal.
Untuk setiap komponen, catat pemilik, versi, lokasi, dependensi, dan pemeriksaan penerimaannya. Simpan lokasi kredensial dalam inventaris; simpan kata sandi dan kunci pribadi di penyimpanan rahasia yang disetujui.
Gulir secara horizontal untuk semua kolom tabel.
| Komponen | Catat sebelum memindahkan | Siapa yang mengonfirmasi |
|---|---|---|
| Domain dan DNS | Registrar, operator DNS, catatan saat ini, dan TTL | Pemilik akun klien |
| Aplikasi | Rilis, runtime, ekstensi, dan metode deployment | Pemelihara agensi |
| Data dan unggahan | Basis data, jalur unggahan, metode pencadangan, dan salinan terakhir yang dapat digunakan | Operator data |
| Formulir dan integrasi | Penerima, titik akhir webhook, dan tujuan uji yang diizinkan | Pemilik alur kerja klien |
| Pekerjaan terjadwal | Cron atau penjadwal, zona waktu, antrean, dan eksekusi sukses terakhir | Pemelihara agensi |
Buktikan salinan pemulihan sebelum menyentuh produksi
Pulihkan ke tujuan uji terpisah, jangan pernah menimpa basis data live. Untuk PostgreSQL, dump SQL mewakili snapshot basis data yang konsisten, tetapi dump satu basis data tidak menyertakan peran atau tablespace seluruh klaster. Catat objek pendukung yang diperlukan aplikasi Anda. Snapshot basis data itu juga tidak otomatis membuat unggahan yang disalin terpisah menjadi konsisten. Dokumentasi dump SQL PostgreSQL.
Untuk proyek WordPress, sertakan file dan basis datanya. Jika URL akan berubah, ikuti panduan khusus migrasinya: pencarian-dan-ganti basis data yang sembarangan dapat merusak nilai berserialisasi. Latih metode yang dipilih pada salinan. Panduan migrasi WordPress.
Catat pertanyaan yang diketahui dan lampirannya, pulihkan keduanya, dan verifikasi keduanya melalui aplikasi. Simpan cadangan asli tetap terlindungi di luar server yang dipindahkan. Transfer file yang selesai bukan penerimaan pemulihan.
Latih alur kerja yang akan diperhatikan klien
Uji menggunakan hostname sementara yang dikontrol akses atau pemetaan nama khusus operator. Konfigurasikan aplikasi untuk rute uji tersebut, termasuk HTTPS dan URL callback yang relevan. Cegah salinan mengirim pesan produksi, memproses pembayaran nyata, atau menjalankan jadwal produksi. Gunakan catatan sintetis yang disetujui daripada data pribadi yang tidak perlu.
Tulis hasil yang diharapkan sebelum setiap pemeriksaan. Catat lulus atau gagal, lokasi bukti, dan orang yang meninjaunya; tangkapan layar beranda tidak dapat mewakili seluruh kisi.
Gulir secara horizontal untuk semua kolom tabel.
| Alur kerja | Hasil yang diharapkan | Bukti yang harus disimpan |
|---|---|---|
| Formulir dan lampiran | Satu pertanyaan tersimpan dan satu file yang dapat dibaca; hanya penerima uji | Pengenal catatan sintetis dan pengamatan pengiriman |
| Webhook | Peristiwa uji yang disetujui mencapai konsumen uji yang dimaksud | Pengenal peristiwa dan hasil konsumen |
| Ekspor terjadwal | Satu eksekusi terkendali, zona waktu benar, tidak ada duplikat server lama | Pengenal eksekusi dan perbandingan catatan yang diekspor |
| Rute editor dan pengunjung | Izin yang diharapkan, pengalihan, aset, dan perilaku HTTPS | URL yang diperiksa dan detail kegagalan apa pun |
Tentukan penulisan terakhir pada sistem lama
Untuk contoh ini, agensi mengusulkan jendela pemeliharaan singkat: jeda pengajuan pertanyaan dan pengeditan, hentikan jadwal ekspor lama, selesaikan atau hitung pekerjaan yang mengantre, lalu buat salinan basis data dan unggahan final. Klien harus menyetujui bagaimana pengunjung diberi tahu bahwa pengajuan sementara tidak tersedia.
Catat pengenal pertanyaan terakhir yang diterima dan waktu penulisan berhenti. Validasi bahwa tujuan menyertakan catatan tersebut dan lampirannya sebelum mengizinkan pengajuan baru. Jaga agar sumber tidak dapat menerima penulisan independen selama jawaban DNS mungkin berbeda. Proyek yang tidak dapat menjeda penulisan memerlukan desain sinkronisasi khusus aplikasi; jangan mengimprovisasinya saat cutover.
Simpan log keputusan DNS
TTL mengontrol berapa lama jawaban DNS di-cache. Menurunkannya saat cutover tidak membatalkan jawaban yang sudah di-cache dengan nilai sebelumnya, jadi persiapkan perubahan TTL terlebih dahulu dan amati transisi dari jaringan yang relevan. Cloudflare juga mencatat bahwa caching lokal dapat menunda perubahan yang terlihat. Dokumentasi TTL DNS Cloudflare.
Catat nama dan jenis catatan, nilai lama, nilai yang dimaksudkan, TTL sebelumnya, persetujuan, waktu perubahan, dan hasil yang diamati. Periksa catatan IPv6 serta catatan IPv4 jika keduanya ada. Pertahankan catatan email yang tidak terkait. Setelah perubahan, verifikasi hostname publik mencapai aplikasi yang dimaksud dan alur kerja kritisnya, bukan hanya alamat IP yang dimaksud.
Jadikan rollback sebagai keputusan data
Sepakati kondisi berhenti yang konkret: pertanyaan terakhir hilang, lampiran tidak dapat dibuka, masuk gagal, atau webhook mencapai penerima yang salah. Sebelum penulisan baru dimulai, kembalinya ke sumber yang dipertahankan mungkin dapat dilakukan setelah latihan. Setelah tujuan menerima pertanyaan baru, memulihkan cadangan lama atau membalikkan DNS saja dapat kehilangan catatan tersebut.
Jika kondisi berhenti muncul setelah pembukaan kembali, jeda penulisan, pertahankan kedua salinan, dan minta operator yang disebutkan merekonsiliasi perubahan sebelum memilih sistem otoritatif. Persetujuan klien memutuskan apakah akan melanjutkan pemulihan atau menggunakan alternatif yang disepakati. Simpan log insiden singkat daripada berulang kali mengganti DNS.
Tutup pemindahan dengan bukti dan kepemilikan
Minta klien meninjau kisi penerimaan. Konfirmasi satu penjadwal aktif, jalur pencadangan baru, kepemilikan peringatan, dan titik pemeriksaan pengamatan berikutnya. Pertahankan sumber untuk periode yang disepakati, lalu setujui penghentiannya secara eksplisit. Hapus akses sementara dan data uji sesuai perjanjian proyek.
Gunakan hasilnya untuk memperbarui lembar tanggung jawab operasional dan anggaran proyek. Prosedur ini mengatur pekerjaan tim Anda; ini tidak menyiratkan bantuan migrasi yang disertakan atau layanan tanpa gangguan.
Sumber & tinjauan
Referensi teknis diperiksa pada September 12, 2026. Contoh adalah latihan perencanaan; dokumentasi perangkat lunak yang direferensikan tidak menetapkan kemampuan layanan PrivateHostLab.