English
Francais
Deutsch
Espanol
Portugues
Italiano
Nederlands
Dansk
Svenska
Norsk
Suomi
Turkce
Ellinika
Russkij
Polski
Cestina
Ukrajinska
Magyar
Romana
Bulgarski
Hrvatski
Srpski
Slovencina
Slovenscina
Lietuviu
Latviesu
Eesti
日本語
한국어
العربية
Bahasa Indonesia
Mengapa checklist migrasi itu penting
Migrasi email adalah salah satu operasi IT paling berisiko yang bisa dilakukan sebuah organisasi. Anda memindahkan bertahun-tahun komunikasi profesional antar platform, dan satu langkah yang terlewat bisa merusak metadata seluruh kotak surat. Korban paling sering? Tanggal email. Setelah migrasi, setiap email berisiko menampilkan tanggal migrasi, bukan tanggal pengiriman atau penerimaan aslinya.
Checklist ini mencakup setiap fase proses migrasi. Ikuti langkah-langkah ini untuk meminimalkan risiko kerusakan tanggal dan masalah metadata lainnya. Dan jika migrasi sudah selesai dan masalah tanggal sudah muncul, teruslah membaca.
Fase 1: perencanaan pra-migrasi
Inventarisasi kotak surat
Sebelum menyentuh alat migrasi apa pun, dokumentasikan setiap kotak surat yang akan dimigrasikan. Catat jumlah total kotak surat, perkiraan jumlah email per kotak, rentang tanggal email paling lama, serta kotak surat bersama atau grup distribusi. Inventaris ini menentukan alat migrasi yang tepat, berapa lama migrasi akan berlangsung, dan tarif yang berlaku untuk koreksi pasca-migrasi jika diperlukan.
Memilih alat migrasi yang tepat
Tidak semua alat migrasi menangani tanggal dengan cara yang sama. Cari tahu bagaimana setiap alat mengelola preservasi IMAP INTERNALDATE dan apakah alat tersebut menambahkan header "Received" selama proses APPEND. Alat-alat populer meliputi BitTitan MigrationWiz, CloudM Migrate, imapsync, GSMMO, dan impor native dari Exchange Admin Center. Masing-masing alat ini bisa menyebabkan masalah tanggal karena protokol IMAP sendiri mengharuskan server tujuan menambahkan header "Received" saat penyisipan pesan. Namun beberapa alat lebih baik dalam mempreservasi INTERNALDATE dibanding yang lain. Untuk memahami lebih dalam cara kerja INTERNALDATE, lihat IMAP INTERNALDATE: mengapa tanggal bisa rusak.
Backup segalanya
Buat backup lengkap setiap kotak surat sebelum migrasi. Backup ini berfungsi sebagai jaring pengaman sekaligus titik referensi untuk memverifikasi tanggal setelahnya. Untuk Google Workspace, gunakan Google Takeout atau alat backup pihak ketiga. Untuk Microsoft 365, gunakan backup Exchange Online atau ekspor ke PST. Untuk server IMAP, gunakan imapsync untuk membuat salinan lokal.
Simpan backup di lokasi yang benar-benar terpisah dari server sumber dan tujuan.
Mendokumentasikan tanggal asli
Pilih 10 hingga 20 email per kotak surat yang tersebar di berbagai rentang tanggal (yang paling lama, yang paling baru, dan beberapa di antaranya). Catat tanggal "Diterima", tanggal "Dikirim", dan header mentah setiap email. Email referensi ini menjadi basis verifikasi Anda setelah migrasi. Ambil screenshot kotak surat yang diurutkan berdasarkan tanggal untuk mendokumentasikan urutan kronologis asli secara visual.
Fase 2: migrasi uji coba
Migrasikan kotak surat uji coba terlebih dahulu
Jangan pernah memulai migrasi penuh tanpa pengujian terlebih dahulu.
Buat kotak surat uji coba dengan sampel email yang representatif (minimal 100, mencakup beberapa tahun). Jalankan migrasi pada kotak surat itu saja dan periksa hasilnya secara mendalam sebelum melanjutkan. Pengujian ini mengungkap masalah tanggal, kesalahan encoding, bug penanganan lampiran, dan perbedaan struktur folder sebelum berdampak pada kotak surat produksi.
Verifikasi tanggal pada kotak surat uji coba
Setelah memigrasikan kotak surat uji coba, verifikasi tanggalnya segera. Buka kotak surat di klien email yang benar-benar akan digunakan pengguna akhir (Outlook, Apple Mail, Thunderbird, atau antarmuka webmail). Bandingkan tanggal yang ditampilkan dengan email referensi yang didokumentasikan di Fase 1. Periksa tanggal "Diterima" maupun tanggal "Dikirim". Buka header mentah beberapa email dan cari header "Received" yang baru ditambahkan dengan timestamp migrasi.
Jika tanggal salah pada kotak surat uji coba, tanggal akan salah di semua kotak surat. Hentikan semuanya dan selesaikan masalah sebelum melanjutkan ke migrasi penuh.
Uji dengan berbagai klien email
Klien email yang berbeda menampilkan tanggal secara berbeda. Antarmuka web Gmail mungkin menampilkan tanggal yang benar (karena menggunakan header "Date"), sementara Outlook menampilkan tanggal migrasi (karena mengutamakan header "Received"). Uji dengan setiap klien yang digunakan pengguna organisasi, termasuk Outlook desktop, Outlook di web, Apple Mail, Thunderbird, dan aplikasi email mobile apa pun.
Fase 3: pelaksanaan migrasi
Konfigurasi alat migrasi
Konfigurasikan alat migrasi untuk mempreservasi INTERNALDATE sebisa mungkin. Di imapsync, gunakan flag yang tepat untuk mengatur INTERNALDATE pada tujuan. Di BitTitan MigrationWiz, periksa pengaturan lanjutan untuk opsi penanganan tanggal. Pengaturan ini tidak akan sepenuhnya mencegah masalah header "Received", tetapi mengurangi tingkat keparahan masalah tanggal di beberapa klien. Dokumentasikan setiap pengaturan konfigurasi yang digunakan agar migrasi bisa diulang jika diperlukan.
Migrasikan secara bertahap
Jangan migrasikan semua kotak surat sekaligus. Migrasikan dalam kelompok 10 hingga 20 kotak surat, lalu verifikasi tanggal setelah setiap kelompok. Jika satu kelompok menunjukkan masalah tanggal, Anda mendeteksinya sebelum seluruh organisasi terpengaruh. Selain itu, migrasi bertahap juga mengurangi beban pada server sumber dan tujuan, meminimalkan risiko timeout atau kesalahan koneksi yang bisa menyebabkan migrasi parsial.
Pantau progres
Lacak progres migrasi untuk setiap kotak surat. Catat waktu mulai, waktu selesai, jumlah email yang dimigrasikan, dan error yang mungkin terjadi. Alat migrasi biasanya menyediakan log, simpan log tersebut untuk setiap kotak surat. Jika masalah tanggal ditemukan belakangan, log membantu mengidentifikasi dengan tepat kelompok migrasi dan parameter apa yang digunakan.
Fase 4: verifikasi pasca-migrasi
Verifikasi tanggal segera
Verifikasi tanggal email dalam 24 jam setelah migrasi. Untuk setiap kelompok, buka 5 hingga 10 kotak surat dan bandingkan tanggalnya dengan referensi pra-migrasi. Jika tanggal salah, dokumentasikan cakupan masalah (berapa banyak kotak surat yang terpengaruh, berapa email per kotak) selagi informasinya masih segar.
Periksa semua jenis folder
Masalah tanggal bisa mempengaruhi folder tertentu secara berbeda. Periksa tanggal di Kotak Masuk, Item Terkirim, Draf, dan setiap folder atau label kustom. Beberapa alat migrasi memproses folder secara berurutan, dan error di satu folder belum tentu berarti ada error di folder lain.
Verifikasi pencarian dan pengurutan
Buka kotak surat yang dimigrasikan, urutkan berdasarkan tanggal, dan konfirmasi bahwa urutan kronologisnya sesuai dengan aslinya. Cari email berdasarkan rentang tanggal dan verifikasi bahwa hasilnya akurat. Uji setiap aturan otomatis atau filter yang bergantung pada tanggal penerimaan. Jika organisasi menggunakan alat kepatuhan atau eDiscovery, pastikan kueri berbasis tanggal mengembalikan hasil yang benar.
Kesalahan umum yang menyebabkan masalah tanggal
Melewati migrasi uji coba
Kesalahan paling umum adalah memigrasikan semua kotak surat tanpa pengujian terlebih dahulu. Ketika masalah tanggal ditemukan, semua kotak surat sudah terpengaruh dan server sumber mungkin sudah dinonaktifkan. Migrasi uji coba selama 30 menit bisa mencegah berminggu-minggu remediasi. Mengapa melewatinya?
Mengabaikan penambahan header "Received"
Administrator sering berfokus pada preservasi INTERNALDATE dan mengabaikan masalah header "Received". Bahkan ketika INTERNALDATE sudah diatur dengan benar, header "Received" dari migrasi membuat Outlook dan klien lain menampilkan tanggal yang salah. Ini adalah sumber keluhan pasca-migrasi yang paling sering terjadi. Baca mengapa email menampilkan tanggal salah setelah migrasi untuk penjelasan teknis lengkapnya.
Menonaktifkan server sumber terlalu cepat
Jika masalah tanggal ditemukan setelah server sumber dimatikan, opsi re-migrasi pun hilang. Pertahankan akses ke server sumber (meskipun hanya baca saja) selama minimal 30 hari setelah migrasi. Ini memberikan solusi cadangan jika masalah serius muncul belakangan.
Apa yang harus dilakukan jika tanggal sudah salah
Jika migrasi sudah selesai dan tanggalnya salah, masalah ini masih bisa diperbaiki. Header "Date" asli tetap tersimpan di setiap email, yang berarti informasi tanggal yang benar masih ada. Tanggal email bisa diperbaiki setelah migrasi, bahkan berbulan-bulan atau bertahun-tahun kemudian.
Engine koreksi proprietary Redate.io terhubung ke kotak surat dan mencari email dengan metadata tanggal yang rusak. Pipeline analisis multi-tahap mengidentifikasi tanda tangan alat migrasi, menerapkan koreksi yang ditargetkan sambil mempertahankan integritas pesan (termasuk tanda tangan S/MIME, struktur multipart, dan header non-ASCII), lalu menjalankan pemeriksaan integritas pada setiap email yang dikoreksi. Analisisnya gratis dan menunjukkan secara persis berapa email yang terdampak. File asli disimpan di folder backup yang terlihat selama 30 hari.
Mencoba koreksi semacam ini secara manual atau dengan skrip kustom memang menggoda, tapi berisiko. Kasus-kasus khusus seperti pesan terenkripsi PGP, batas MIME yang rusak, struktur multipart bersarang, dan ketidaksesuaian Content-Transfer-Encoding bisa merusak email secara diam-diam tanpa Anda sadari sampai terlambat. Dan bagaimana cara memverifikasi bahwa 10.000 email yang dikoreksi semuanya utuh?
Siap memeriksa apakah kotak surat Anda memiliki masalah tanggal? Jalankan analisis gratis dengan Redate.io - tidak perlu pembayaran untuk melihat berapa banyak email yang terdampak.