Migrasi Google Workspace ke GWS: Tanggal Email Rusak

Skenario yang tidak disangka siapapun

Anda baru saja menyelesaikan migrasi dari satu tenant Google Workspace ke tenant lain. Akuisisi perusahaan, pergantian domain, penggabungan dua entitas yang selama bertahun-tahun hidup berdampingan di bawah akun G Suite terpisah. Prosesnya berjalan lancar, kotak surat sudah siap, pengguna sudah bisa login. Senin pagi, tiket pertama masuk: "Semua email saya punya tanggal yang sama." Lalu satu lagi. Lalu sepuluh.

Secara naluriah, Anda berpikir: pasti ini masalah IMAP, alat yang salah konfigurasi, atau sesuatu yang tidak biasa. Bukan migrasi Google ke Google. Namun, justru di situlah masalah ini terjadi.

Skenario ini mungkin yang paling minim dokumentasinya di industri ini. Sebagian besar admin IT yang mengalaminya menghabiskan beberapa jam mencari penjelasan di sisi klien email, di Outlook, di pengaturan akun, sebelum menyadari bahwa masalahnya ada di dalam header email itu sendiri.

Mengapa migrasi Google ke Google merusak tanggal

Untuk memahami apa yang terjadi, kita perlu kembali ke mekanisme header email. Setiap pesan RFC 2822 mengandung field Date: asli, yang ditetapkan oleh klien atau server pengirim pada saat pengiriman. Inilah tanggal "sejati" dari email tersebut, yaitu kapan pesan itu ditulis dan dikirim.

Namun ada mekanisme lain: INTERNALDATE IMAP. Ini adalah metadata yang disimpan di sisi server, yang menunjukkan kapan pesan ditempatkan di kotak surat. Dan di sinilah hal ini menjadi menarik.

Ketika alat migrasi memindahkan email dari satu tenant Google Workspace ke tenant lain, proses ini melewati protokol IMAP (meskipun kedua server berada di Google). Pesan dibaca dari sumber, lalu disisipkan kembali ke tujuan. Pada saat penyisipan ini, server tujuan secara otomatis menambahkan header Received: dengan cap waktu operasi tersebut, yaitu tanggal migrasi.

Sementara itu, klien email seperti Outlook menggunakan Received: pertama dalam rantai header untuk menampilkan tanggal pesan, bukan field Date: aslinya. Hasilnya: semua email menampilkan tanggal hari migrasi dilakukan.

Alat mana yang memicu masalah ini

Hampir semua alat yang digunakan untuk migrasi antar-tenant Google Workspace terdampak. Tidak ada pengecualian yang berarti:

• GSMMO (Google Workspace Migration for Microsoft Outlook): awalnya dirancang untuk migrasi dari Exchange, tetapi digunakan dalam beberapa alur GWS ke GWS.
• CloudM Migrate: sangat umum digunakan oleh MSP untuk migrasi antar-Google, secara konsisten menambahkan Received: migrasi. Lihat analisis lengkap CloudM.
• BitTitan MigrationWiz: sama saja, perilaku ini dibahas dalam artikel tentang BitTitan.
• imapsync: alat open source untuk men-skrip migrasi IMAP, termasuk antara dua tenant Google.
• Ekspor/impor manual via Takeout + reimport IMAP: lebih jarang digunakan, tetapi menghasilkan efek yang persis sama.

Alasannya sederhana: semua alat ini beroperasi sebagai klien IMAP standar. Mereka tidak memiliki akses ke jalur "native" Google yang bisa mempertahankan metadata. Meskipun kedua tenant berada di Google, transfer tetap melewati lapisan IMAP, dan lapisan ini tidak tahu bahwa ia sedang berbicara dengan dirinya sendiri.

Mekanisme header Received secara detail

(Omong-omong, jika Anda pernah mencoba membaca header mentah sebuah email dari Gmail atau Outlook, Anda tahu bahwa itu bukan bacaan yang menyenangkan. Tapi di situlah semua kebenaran tersembunyi.)

Sebuah email yang berjalan normal mengandung rangkaian header Received: dalam urutan terbalik dari perjalanannya: server terakhir yang menyentuh pesan ada di bagian atas. Setelah migrasi, header migrasi ada di paling atas tumpukan.

Ini tampilan header dalam pesan yang dimigrasi via CloudM dari satu tenant GWS ke tenant lain:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <pengguna@domain-baru.com>
        ; Mon, 14 Oct 2024 09:17:32 +0000 (UTC)
Received: from mail-relay.google.com ...
        ; Tue, 5 Mar 2019 14:22:08 +0000
Date: Tue, 5 Mar 2019 14:22:08 +0000

Field Date: menunjukkan 2019. Received: pertama menunjukkan Oktober 2024. Outlook membaca Received: pertama. Pengguna melihat Oktober 2024 untuk email dari 2019.

Field Date: asli masih utuh. Tidak berubah. Ini kabar baiknya: datanya ada, hanya menunggu untuk digunakan dengan benar.

Outlook dan Gmail berperilaku berbeda

Ini adalah perbedaan yang penting untuk dipahami. Pengguna yang mengakses email melalui antarmuka web Gmail sering kali melihat tanggal yang benar, karena Gmail memprioritaskan field Date: RFC 2822 untuk menampilkan pesan. Masalah ini kurang terlihat di sisi web.

Sebaliknya, pengguna yang mengonfigurasi kotak surat Google Workspace mereka di Outlook via IMAP (atau melalui sinkronisasi Exchange ActiveSync) langsung merasakan dampak tanggal yang salah, karena Outlook mengandalkan INTERNALDATE IMAP, yang mencerminkan tanggal dari Received: pertama yang ditambahkan saat migrasi.

Untuk lebih tepatnya: perilaku Outlook bervariasi tergantung versi dan mode koneksi. Outlook 2019 dan Microsoft 365 (versi terbaru) menggunakan INTERNALDATE saat terhubung via IMAP. Versi yang lebih lama mungkin berperilaku sedikit berbeda. Namun dalam semua kasus yang diamati di lingkungan produksi, migrasi GWS ke GWS via IMAP menghasilkan tanggal yang tidak benar di Outlook.

Akibatnya, di organisasi yang telah bermigrasi ke tenant baru dan memiliki pengguna hybrid (sebagian memakai Gmail web, sebagian lagi memakai Outlook), laporan tiket menjadi tidak konsisten. Tim IT menghabiskan waktu untuk memahami mengapa "sebagian pengguna terdampak dan sebagian tidak", padahal jawabannya sederhana: klien email yang digunakan yang membuat perbedaan.

Akuisisi, merger, pergantian domain: kasus-kasus paling sering terjadi

Jenis migrasi ini bukan hal yang langka. Berikut skenario yang paling banyak menghasilkan tiket:

Akuisisi perusahaan

Sebuah perusahaan yang diakuisisi memiliki tenant Google Workspace sendiri (domain @perusahaanlama.com). Setelah akuisisi, semuanya harus dipindahkan ke tenant induk perusahaan (@grup.com). 250 kotak surat, arsip, 8 tahun riwayat email. BitTitan atau CloudM ditugaskan untuk operasi ini. Hasilnya: 2,4 juta email dengan tanggal akhir pekan migrasi.

Pergantian domain

Sebuah perusahaan yang berganti merek beralih dari @namalama.com ke @namabaru.com. Tenant Google tetap sama, tetapi dibuat tenant baru untuk memulai dengan bersih (pilihan umum untuk menghindari artefak konfigurasi). Migrasi kotak surat dilakukan via imapsync atau GSMMO. Tanggal rusak dengan cara yang persis sama.

Konsolidasi anak perusahaan

Sebuah grup dengan 4 anak perusahaan, masing-masing memiliki tenant G Suite historisnya sendiri, memutuskan untuk menggabungkan semuanya ke dalam satu tenant. Empat migrasi berjalan paralel, empat kelompok email dengan tanggal yang rusak yang harus ditangani.

Dalam ketiga skenario ini, masalahnya identik dan solusinya sama. Checklist migrasi email ini membantu Anda mengantisipasi jenis masalah ini sebelum migrasi dimulai.

Mengapa skrip buatan sendiri bukan jawabannya

Memahami masalah adalah satu hal. Memutuskan "saya akan menulis skrip Python yang membersihkan header" lalu menerapkannya pada 30.000 email produksi adalah hal lain sepenuhnya.

Kasus-kasus tepi sangat banyak. Skrip yang bekerja baik pada 50 email uji coba di lingkungan bersih akan pasti menemui, pada kotak surat produksi berukuran nyata:

• Pesan dengan tanda tangan S/MIME atau konten terenkripsi PGP, di mana setiap modifikasi struktur pesan membatalkan tanda tangan kriptografis.
• Email dengan struktur MIME bertingkat yang kompleks (multipart/alternative di dalam multipart/mixed dengan lampiran berukuran puluhan megabyte).
• Header yang dikodekan dengan RFC 2047 (karakter non-ASCII), yang diam-diam dirusak oleh parser yang tidak dikonfigurasi dengan benar.
• Error 429 Too Many Requests dari API Google pukul 2 pagi, di tengah-tengah batch koreksi, yang membiarkan proses dalam kondisi tidak menentu.
• Email di mana rantai Received: bersifat ambigu: beberapa alat migrasi yang digunakan berurutan masing-masing telah menambahkan headernya, dan tidak mudah untuk menentukan mana yang harus dihapus.

Dan pertanyaan terpenting: bagaimana cara memverifikasi, email per email, bahwa setiap pesan yang dikoreksi masih utuh dan tidak ada yang hilang atau rusak? Skrip buatan sendiri umumnya tidak melakukan verifikasi ini. Redate.io melakukannya secara otomatis, dengan menyimpan pesan asli di folder cadangan yang dapat dilihat selama 30 hari.

Apa yang dilakukan Redate.io untuk jenis migrasi ini

Redate.io terhubung ke tenant Google Workspace tujuan (melalui delegasi domain, tanpa intervensi manual kotak per kotak) dan memindai email untuk mengidentifikasi yang metadata tanggalnya tidak konsisten dengan konten pesan. Fase pemindaian ini gratis dan memberikan gambaran tepat tentang skala masalah sebelum koreksi apa pun dilakukan.

Engine koreksi proprietary kemudian menganalisis rantai header setiap pesan, menerapkan pencocokan pola pada tanda tangan yang dikenal dari berbagai alat migrasi (BitTitan, CloudM, imapsync, GSMMO, dan lainnya yang kurang umum), serta melakukan koreksi metadata yang tepat sasaran tanpa mengubah konten pesan. Setiap email yang dikoreksi diverifikasi satu per satu. Pesan asli tetap tersimpan.

Untuk migrasi antar-tenant Google Workspace secara khusus, pipeline menangani kasus di mana beberapa kali migrasi telah dilakukan (misalnya, kotak surat yang dimigrasi pertama kali pada 2021 kemudian lagi pada 2024), dengan beberapa lapisan header parasit yang harus diurai.

Panduan koreksi spesifik untuk CloudM ke Google Workspace dan BitTitan ke Google Workspace menjelaskan langkah-langkah koneksi untuk jenis konfigurasi ini.

Mendeteksi masalah sebelum pengguna mengeluh

Waktu terbaik untuk mendeteksi tanggal yang rusak adalah tepat setelah migrasi, sebelum go-live. Pemeriksaan cepat pada beberapa kotak surat pilot via klien IMAP seperti Thunderbird memungkinkan Anda membandingkan tampilan tanggal dengan yang seharusnya. Jika semua email yang diimpor tampaknya memiliki tanggal baru yang sama, itu adalah tanda khas dari masalah ini.

Namun dalam praktiknya, masalah ini sering baru ditemukan beberapa minggu setelah migrasi, ketika seorang pengguna mencari kontrak lama dan menyadari bahwa kotak Gmail-nya tersortir dengan sempurna... berdasarkan tanggal migrasi. Ribuan email bertumpuk pada cap waktu yang sama. Pencarian berdasarkan tanggal tidak lagi berfungsi. Riwayat korespondensi tampak menghilang.

Bagi MSP yang secara rutin menangani migrasi antar-tenant Google Workspace, mengintegrasikan pemindaian Redate.io ke dalam checklist pasca-migrasi (sebelum validasi klien) mencegah kejutan seperti ini.

Anda baru saja bermigrasi antara dua tenant Google Workspace dan tanggal email Anda tidak benar? Mulai pemindaian gratis di Redate.io untuk mengukur dampaknya sebelum koreksi apa pun dilakukan.