Tentukan skop sebenar pemindahan
Migrasi hosting mengubah tempat laman web disampaikan kepada pelawat, tetapi tidak secara automatik memindahkan pemilikan domain, peti mel, langganan atau integrasi luar. Nyatakan hasil yang dikehendaki sebelum memilih kaedah: menggantikan pelayan bermasalah, menukar teknologi, menyatukan pembekal atau menggunakan perkhidmatan terurus. Catat sama ada semua URL yang dilihat pelanggan kekal sama dan sama ada aplikasi asal masih digunakan. Jawapan ini menentukan keperluan pangkalan data, pengalihan URL, ujian dan carian Google. Anggap migrasi sebagai perubahan operasi perniagaan yang mempunyai pembuat keputusan jelas, bukan sekadar kerja memuat naik fail.
Sediakan inventori yang boleh digunakan orang lain
Sediakan inventori domain utama dan subdomain, akaun hosting, sistem pengurusan kandungan, versi perisian, enjin pangkalan data, tema, pemalam, tugasan berjadual serta lokasi storan. Masukkan risalah yang boleh dimuat turun, imej, fail dimuat naik pelanggan, pengalihan URL, halaman ralat tersuai dan direktori terhad. Kenal pasti pemegang akses setiap akaun dan cara mendapatkan semula akses jika juruteknik biasa tidak tersedia. Sebuah syarikat kecil mungkin mendapati borang pertanyaannya bergantung pada perkhidmatan luar walaupun laman dihoskan di tempat lain. Inventori yang boleh difahami oleh pengganti mengurangkan risiko kebergantungan ini terputus ketika pemindahan pelayan.
Asingkan kawalan domain daripada hosting
Sahkan akaun pendaftar domain, tarikh luput domain, pelayan nama berwibawa dan pihak yang mengurus DNS semasa. Pembaharuan hosting dan pendaftaran domain ialah dua tanggungjawab berasingan walaupun muncul dalam satu invois. Migrasi pelayan biasanya hanya memerlukan perubahan rekod A, AAAA atau CNAME tertentu untuk laman web; pertukaran pendaftar atau nameserver tidak semestinya perlu. Eksport atau rekod keseluruhan zon DNS sebelum merancang perubahan, termasuk entri yang kelihatan tidak berkaitan dengan laman. Jangan jadikan migrasi hosting alasan untuk memindahkan pemilikan domain atau mengubah perkhidmatan lain tanpa pelan berasingan yang diluluskan.
Lindungi e-mel sebelum menukar DNS
Kenal pasti destinasi MX, dasar SPF, pemilih DKIM, rekod DMARC serta rekod penemuan automatik atau pengesahan yang digunakan sekarang. Laman web boleh berpindah sedangkan e-mel syarikat kekal dengan pembekal sedia ada. Menggantikan nameserver tanpa menyalin rekod tersebut boleh mengganggu penerimaan e-mel atau melemahkan pengesahan walaupun laman baharu dapat dibuka. Jika akaun hosting lama turut menyimpan peti mel, semak storan dan penghalaan setempat sebelum menamatkannya. Tetapan penghalaan e-mel cPanel ialah keputusan pada pelayan, bukannya bukti konfigurasi DNS awam. Ujian penghantaran dan penerimaan sebenar hendaklah dibuat dalam pelan penerimaan migrasi yang dibenarkan.
Rekod garis dasar laman semasa
Sebelum memindahkan apa-apa, rekod keadaan laman sedia ada yang berfungsi. Simpan senarai URL penting, kod respons, tajuk halaman, pilihan bahasa, tingkah laku borang, fail muat turun dan tangkap layar mudah alih. Catat fungsi yang memerlukan log masuk, fungsi yang bergantung pada gerbang pembayaran dan fungsi yang tidak boleh diuji menggunakan transaksi pelanggan sebenar. Simpan ukuran prestasi yang tersedia bersama masa pengukuran, tetapi jangan menjanjikan hosting baharu pasti lebih pantas. Garis dasar ini memberikan perbandingan nyata kepada penyemak dan membezakan kerosakan lama daripada masalah yang timbul akibat migrasi.
Sandarkan lebih daripada halaman yang kelihatan
Sediakan salinan yang boleh dipulihkan bagi fail laman, pangkalan data, imej dimuat naik dan konfigurasi aplikasi melalui kaedah yang disokong platform. Panduan WordPress memasukkan pangkalan data, pemalam, imej dan fail lain apabila berpindah pelayan. Bagi akaun cPanel, fahami perbezaan antara sandaran akaun penuh dengan sandaran separa; arkib penuh tidak boleh dipulihkan secara automatik melalui antara muka cPanel biasa. Sahkan lokasi arkib, pihak yang mempunyai akses dan sama ada kandungannya boleh dibaca. Nama fail bertulis 'backup' atau mesej muat turun berjaya sahaja tidak membuktikan data benar-benar boleh dipulihkan.
Uji pemulihan tanpa menimpa produksi
Pelan migrasi yang selamat menilai sama ada sandaran mampu menghasilkan laman berfungsi dalam persekitaran berasingan. Selepas pemulihan percubaan, semak struktur fail, jadual pangkalan data, beberapa rekod contoh dan dokumen yang dimuat naik. Jangan pulihkan arkib di atas akaun langsung semata-mata untuk mengujinya. Jika pembekal perlu memulihkan akaun penuh melalui antara muka pentadbiran, sahkan tanggungjawab dan syaratnya secara bertulis. Rekod keputusan, komponen yang hilang serta tempoh pemulihan. Bukti ini lebih berguna daripada dakwaan umum bahawa sandaran dibuat setiap hari, khususnya apabila masa untuk berpatah balik adalah terhad.
Semak keserasian destinasi sebelum membeli
Bandingkan perkhidmatan sasaran dengan keperluan aplikasi sebenar, bukan hanya ruang cakera yang diiklankan. Semak versi perisian dan pangkalan data, kebenaran fail, tugasan berjadual, sambungan, had muat naik, sambungan keluar serta sijil keselamatan. Pemalam lama mungkin gagal dengan versi PHP lebih baharu; laman statik pula mungkin tidak memerlukan PHP langsung. Tanya siapa mengurus kemas kini keselamatan, log, sandaran dan akses kecemasan mengikut kontrak yang dicadangkan. Jika migrasi memerlukan sokongan khas atau gangguan perkhidmatan, tetapkan skop itu secara berasingan. Jangan anggap bahan pemasaran umum pembekal menjamin semua ciri pada pelan tertentu.
Rancang konsistensi pangkalan data dan perubahan akhir
Laman dinamik boleh terus menerima pesanan, komen atau pertanyaan ketika fail sedang disalin. Jika pangkalan data lama berubah selepas salinan dibuat, laman baharu mungkin dilancarkan tanpa rekod terkini. Pilih pendekatan yang sesuai: tempoh penyelenggaraan singkat yang diluluskan, penyegerakan akhir pangkalan data atau proses replikasi khusus aplikasi oleh petugas berkelayakan. Rekod masa henti kemas kini dan cara menyelaraskan penyerahan baharu. Jangan membuang transaksi secara senyap atau menganggap salinan semalam masih terkini. Laman brosur statik mempunyai lebih sedikit komponen, namun borang luarnya tetap memerlukan semakan kesinambungan berasingan.
Kendalikan URL dan tetapan WordPress dengan teliti
Bagi pemindahan WordPress yang mengekalkan domain dan laluan halaman, penyalinan fail serta pangkalan data mungkin mencukupi tertakluk pada perbezaan konfigurasi. Jika kelayakan pangkalan data berubah, konfigurasi laman perlu merujuk sambungan baharu. Menukar domain atau laluan ialah projek berlainan: pangkalan data mungkin menyimpan URL di dalam struktur data bersiri yang boleh rosak akibat penggantian teks biasa. Ikuti panduan migrasi WordPress dan gunakan proses yang memahami data bersiri apabila perlu. Semak menu, media, URL kanonik dan fungsi log masuk selepas pemindahan. Jangan gabungkan migrasi hosting dengan reka bentuk semula tanpa menetapkan risiko tambahan secara sengaja.
Sediakan salinan ujian yang tidak mengelirukan pelanggan
Gunakan persekitaran ujian yang dihadkan akses untuk menyemak laman selepas dipindahkan sebelum mengalihkan pelawat awam. Utamakan kawalan akses dan nama hos sementara yang tidak mengelirukan pelanggan dengan alamat rasmi. Jika hos ujian boleh diakses umum, Google menyarankan pencegahan pengindeksan tanpa sengaja semasa ujian; buang sekatan noindex atau crawler sementara daripada salinan produksi sebelum pelancaran. Matikan kutipan bayaran sebenar, pemberitahuan luar dan automasi produksi dalam ujian kecuali ujian terhad telah dibenarkan. Labelkan data contoh dengan jelas dan elakkan penyalinan maklumat pelanggan sensitif tanpa keperluan. Tangkap layar persekitaran ujian bukan bukti laman langsung berfungsi.
Semak halaman, aset dan kesetaraan bahasa
Uji sampel yang dipilih secara sengaja: halaman utama, perkhidmatan, artikel, hubungan, privasi, muat turun dan halaman ralat. Buka laman pada skrin kecil serta besar dan semak fon, imej, navigasi, kontras serta penggunaan papan kekunci. Bagi laman dwibahasa Inggeris dan Bahasa Melayu, periksa kedua-dua versi serta pautan silang; kejayaan satu halaman tidak membuktikan versi lain betul. Pastikan imej tidak lagi bergantung pada pelayan lama dan fail muat turun menggunakan jenis kandungan yang dijangka. Simpan daftar masalah dengan URL, hasil sebenar, hasil sepatutnya dan orang yang bertanggungjawab membetulkannya.
Kekalkan URL serta isyarat carian
Jika URL awam kekal sama, panduan Google untuk pertukaran hosting membezakan keadaan ini daripada pemindahan laman yang mengubah URL. Kekalkan laluan halaman, tajuk, tag kanonik, pautan hreflang, arahan robots dan rujukan sitemap. Bandingkan kod respons sebelum dan selepas pemindahan, termasuk pengalihan serta respons 404 yang sebenar. Jika laluan perlu berubah, sediakan peta pengalihan URL lama kepada URL baharu dan ikuti panduan berasingan bagi migrasi yang mengubah alamat. Pastikan pengesahan pemilikan Search Console terus berfungsi; fail atau tag pengesahan yang tertinggal menyukarkan pemantauan. Domain yang sama atau perubahan DNS berjaya tidak menjamin kedudukan carian.
Sahkan HTTPS pada destinasi sebenar
Sebelum pertukaran, sahkan destinasi mampu menyampaikan nama hos yang diperlukan menggunakan sijil HTTPS sah dan konfigurasi aplikasi betul. Uji domain asas dan www jika kedua-duanya digunakan, serta subdomain yang turut berpindah. Jika CDN atau proksi songsang berada di hadapan, semak sambungan tersulit ke pelayan asal selain sijil yang dilihat pelawat; ikon kunci pada pelayar sahaja tidak membuktikan keseluruhan laluan dikonfigurasi dengan betul. Periksa gelung pengalihan dan amaran kandungan bercampur. Pengeluaran serta pembaharuan sijil mungkin bergantung pada kebolehcapaian DNS, maka jadualkan persediaannya sebelum pertukaran awam apabila boleh.
Uji borang dan integrasi tanpa mendedahkan data
Halaman hubungan boleh kelihatan sempurna sedangkan penghantaran borangnya gagal. Senaraikan pemproses borang, pengesahan antispam, destinasi webhook, pemberitahuan e-mel, peta, tempahan dan pembekal bayaran. Bagi setiap integrasi, tentukan kaedah ujian selamat, respons dijangka dan pemilik sistem penerima. Elakkan maklumat pelanggan sebenar atau transaksi langsung ketika latihan. Sahkan notis privasi masih menggambarkan pemprosesan sebenar dan rahsia aplikasi tidak diletakkan dalam fail sumber awam. Jika endpoint belakang tabir di luar skop atau tertakluk pada kelulusan keluaran berasingan, rekod sebagai belum disahkan dan jangan mengisytiharkan seluruh laman sudah diterima.
Semak cache serta kebergantungan luar
Migrasi mungkin melibatkan cache pelayar, CDN, aplikasi dan DNS yang berkelakuan berbeza. Senaraikan peraturan proksi, pengecualian cache, pengalihan serta tetapan keselamatan kandungan sebelum menukar infrastruktur. Selepas menyalin laman, uji permintaan baharu dan halaman yang pernah dibuka supaya salinan cache lama tidak menyembunyikan ralat. Semak sama ada aset statik mempunyai URL stabil atau nama fail berversi. Jangan kosongkan semua cache atau mengubah CDN produksi tanpa pelan: perubahan melulu boleh meningkatkan beban pelayan asal atau menyebabkan halaman yang sengaja tidak dicache tersalah dikendalikan. Selaraskan perubahan cache dengan waktu pertukaran yang dibenarkan.
Kawal kelayakan akses dan kebenaran
Pastikan persekitaran baharu mempunyai pentadbir bernama, akses mengikut keperluan tugas, pengesahan yang disokong dan cara membuang akaun sementara selepas migrasi. Pindahkan rahsia melalui saluran selamat yang diluluskan, bukan dengan menampal kata laluan ke dalam tiket, dokumen kongsi atau repositori awam. Semak pemilikan fail dan kebenaran menulis selepas penyalinan; halaman mungkin boleh dibuka tetapi gagal menyimpan muat naik atau kemas kini. Pastikan sandaran peribadi, log dan fail konfigurasi tidak boleh dimuat turun oleh orang awam. Jika pembekal memerlukan akses tinggi, hadkan tempohnya dan batalkan selepas pengesahan. Perubahan akses memerlukan kebenaran serta rekod audit tersendiri.
Pilih waktu pertukaran berdasarkan operasi perniagaan
Pilih waktu pertukaran berdasarkan pola pertanyaan, pesanan, ketersediaan kakitangan dan waktu sokongan pembekal, bukan dengan menganggap tengah malam sentiasa paling selamat. Tetapkan orang yang meluluskan pertukaran, pelaksana dan penyemak hasil secara berasingan jika sumber mencukupi. Sediakan makluman dalaman ringkas tentang kesan dijangka, nombor hubungan kecemasan dan syarat pembatalan. Dalam contoh andaian perniagaan temu janji di Malaysia, waktu lengang mungkin mengurangkan gangguan, namun sistem tempahan penting masih memerlukan pelan transaksi. Jangan menjanjikan tiada masa henti apabila perkara itu belum dibuktikan melalui ujian.
Fahami TTL dan pertukaran DNS
Google menyarankan pertimbangan nilai time-to-live DNS yang lebih rendah lebih awal supaya cache boleh dikemas kini dengan lebih cepat. TTL bukan butang pertukaran serta-merta: resolver dan jawapan cache berlainan boleh menyebabkan pelawat sampai ke destinasi lama atau baharu semasa peralihan. Rekod rekod DNS khusus untuk web yang dibenarkan berubah serta nilai asal bagi tujuan pemulihan. Semak pembekal DNS berwibawa dan jangan menganggap editor zon pada hosting lama mengawal jawapan awam. Elakkan menukar MX, nameserver atau DNSSEC sebagai kerja sampingan. Jika boleh, pastikan kedua-dua persekitaran menyampaikan kandungan konsisten sementara jawapan cache beransur luput.
Pantau bukti selepas pertukaran
Selepas pertukaran yang dibenarkan, periksa URL penting daripada lebih satu rangkaian dan sahkan respons HTTPS, kandungan serta versi bahasa. Teliti log pelayan lama dan baharu jika akses tersedia; Google secara khusus menyarankan pemerhatian peralihan trafik sebelum hosting lama ditamatkan. Pantau ralat aplikasi, imej hilang, penghantaran borang gagal dan pengalihan luar biasa. Gunakan Search Console untuk memerhati petunjuk crawling serta pengindeksan tanpa menganggap turun naik sementara sebagai bukti penalti. Catat masa, keadaan ujian dan masalah yang belum selesai. Paparan status hijau atau satu kejayaan membuka halaman utama tidak mencukupi sebagai bukti penerimaan.
Tetapkan pencetus pemulihan sebelum masalah berlaku
Pelan kembali kepada keadaan asal perlu menyatakan nilai DNS terdahulu, persekitaran pelayan lama, salinan data konsisten terakhir dan orang yang berkuasa membatalkan perubahan. Tetapkan pencetus yang boleh diperiksa seperti transaksi penting gagal, ralat sijil meluas atau rekod pelanggan hilang, bersama masa akhir untuk membuat keputusan. Mengembalikan DNS sahaja mungkin tidak memulihkan perubahan pangkalan data yang berlaku pada laman baharu; aplikasi dinamik memerlukan strategi penyelarasan. Uji sama ada persekitaran lama masih mampu melayani pengguna sepanjang peralihan. Bezakan arahan pemulihan sebenar daripada janji belum diuji bahawa semuanya boleh dipulihkan dalam beberapa minit.
Tutup migrasi hanya selepas serahan operasi
Pertukaran teknikal yang selesai tidak semestinya bermaksud serahan operasi telah lengkap. Rekod pembekal baharu, pemilik pembaharuan, hubungan bil, pentadbir, jadual sandaran, tanggungjawab pembaharuan sijil dan lokasi inventori konfigurasi terkini. Dapatkan bukti halaman penting serta integrasi yang dibenarkan telah lulus semakan penerimaan. Pastikan kakitangan tahu cara melaporkan masalah dan pembekal yang bertanggungjawab bagi setiap lapisan. Tamatkan perkhidmatan lama hanya selepas trafik, penyimpanan data, kebergantungan e-mel dan syarat notis kontrak diperiksa. Untuk pertanyaan kepada OnHypp, minta penilaian berskop berdasarkan laman dan kekangan sebenar; jangan anggap migrasi, pemantauan atau penjagaan berterusan termasuk dalam pelan hosting lain.
Pindahkan aplikasi tanpa mengganggu e-mel perniagaan
Perniagaan boleh memindahkan laman web daripada akaun berkongsi berfokuskan e-mel ke hosting awan terurus sambil mengekalkan semua peti mel di perkhidmatan e-mel semasa. Pelan migrasi mesti menyenaraikan rekod A/AAAA dan CNAME secara berasingan daripada rekod MX serta TXT pengesahan e-mel. Tetapkan masa penukaran khusus laman web, kekalkan sandaran aplikasi terdahulu dan uji borang, pembayaran, log masuk serta kemas kini pangkalan data sebelum menutup kerja. Halaman utama yang terbuka bukan bukti semua transaksi berfungsi.
Sahkan sama ada domain sedia ada harus kekal di pendaftar semasa dan elakkan membayar dua kali bagi pendaftaran yang sama. Bagi semua pelan, rekodkan folder pemasangan, skop deployment SSH, kaedah pemulihan sandaran dan syarat pengunduran sebelum menukar DNS.
Sumber & bacaan lanjut
Bersedia melihat perkhidmatan berkaitan?
Lihat perkhidmatan OnHypp yang berkaitan dan tentukan sama ada ia sesuai dengan keperluan perniagaan anda.
E-mel & hostingDomainReka bentuk web