GSMMO Merusak Tanggal Email? Cara Memperbaikinya

GSMMO dan Masalah Tanggal yang Tidak Diperingatkan Siapa pun

Google Workspace Migration for Microsoft Outlook (GSMMO) adalah tool desktop yang disediakan Google untuk memigrasi file PST, profil Outlook, dan arsip email lokal ke Gmail. Tool ini gratis, didukung secara resmi, dan merupakan jalur migrasi yang direkomendasikan Google saat Anda memindahkan tim kecil atau beberapa kotak surat individual dari Outlook ke Google Workspace.

Tool ini berfungsi. Email tiba di Gmail, struktur folder terpetakan ke label, kontak berpindah dengan baik. Tapi buka Gmail setelahnya dan urutkan berdasarkan tanggal. Setiap email menampilkan tanggal hari ini. Proposal yang Anda kirim pada Januari 2021? April 2026. Faktur dari akuntan Anda pada Maret 2023? Juga April 2026.

GSMMO tidak memperingatkan Anda bahwa ini akan terjadi. Log migrasi menampilkan keberhasilan untuk setiap pesan. Dokumentasi Google sendiri tidak menyebutkannya sebagai keterbatasan yang diketahui. Anda hanya menyadarinya ketika seseorang mencari email lama berdasarkan rentang tanggal dan mendapatkan nol hasil.

Bagaimana GSMMO Sebenarnya Mengunggah Email Anda

GSMMO membaca pesan dari file PST (atau langsung dari profil Outlook) dan mengunggahnya ke Gmail melalui API Gmail (catatan rilis resmi Google untuk tool ini menyatakan hal itu). Di sinilah masalah tanggal bermula, dan penting untuk memahami mekanismenya karena hal ini menjelaskan mengapa perbaikannya tidak sesederhana "impor ulang saja".

Ketika GSMMO mengunggah pesan melalui API Gmail, Gmail menambahkan header Received: baru dengan tanggal saat unggahan dilakukan. Dan ketika tanggal asli tidak turut disertakan bersama pesan, INTERNALDATE, yaitu timestamp yang digunakan Gmail secara internal untuk pengurutan dan tampilan, diatur ke momen unggahan alih-alih tanggal pengiriman asli.

Berikut tampilan rantai header setelah migrasi GSMMO:

Received: by 2002:a05:6512:3ca2:0:0:0:0 with SMTP id
    bi34csp1847206lfb; Sun, 5 Apr 2026 03:17:42 -0700 (PDT)
Received: from [127.0.0.1] (localhost [127.0.0.1])
    by gmailapi.google.com; Sun, 05 Apr 2026 10:17:41 +0000
Date: Wed, 18 Sep 2019 14:33:07 +0200

Lihat header Date: asli dari September 2019 itu? Masih ada, tidak diubah. GSMMO tidak memodifikasi konten pesan atau header asli. Tapi Gmail mengabaikannya untuk keperluan tampilan dan menggunakan INTERNALDATE, yang sekarang menunjukkan April 2026.

GSMMO vs. Tool Migrasi Sisi Admin

Di sinilah kebingungan sering dimulai. Google memiliki beberapa tool migrasi, dan tidak semuanya berperilaku sama.

GSMMO (aplikasi desktop) berjalan di komputer pengguna. Tool ini membaca dari Outlook atau file PST dan mengunggah email melalui API Gmail. Pengguna memerlukan akun Google Workspace dan plugin GSMMO yang terpasang di Outlook. Ini adalah tool sisi klien.

Google Workspace Migration Service (tool konsol admin) berjalan di sisi server. Administrator mengonfigurasinya di Google Admin Console, mengarahkannya ke server Exchange atau tenant Google Workspace lain, dan migrasi berjalan di infrastruktur Google. Tool ini memiliki penanganan tanggal yang sedikit lebih baik pada beberapa konfigurasi karena bisa mengatur INTERNALDATE berdasarkan metadata sumber. Tapi "sedikit lebih baik" tidak berarti "andal", dan banyak administrator melaporkan masalah tanggal yang sama dengan tool ini juga.

Perbedaan utamanya? Dengan GSMMO, tidak ada kecerdasan sisi server yang membuat keputusan tentang pelestarian tanggal. Setiap pesan yang diunggahnya mendapat perlakuan yang sama, baik itu email baru atau pesan arsip berumur 10 tahun: header Received: dengan tanggal hari unggahan. Titik.

Mengapa Pelestarian Tanggal GSMMO Tidak Berhasil

Jika Anda melihat pengaturan GSMMO, Anda mungkin memperhatikan bahwa sebenarnya tidak ada opsi "pertahankan tanggal". Itu bukan kelalaian. GSMMO bergantung pada cara Gmail menangani pesan yang diunggah melalui API-nya, dan tidak bisa menimpanya.

Berikut rangkaian teknis peristiwanya:

1. GSMMO membaca pesan dari file PST, termasuk timestamp aslinya
2. GSMMO mengunggah data pesan melalui API Gmail
3. Gmail menerima unggahan dan menyimpan pesan di kotak surat
4. Gmail menambahkan header Received: baru dengan tanggal saat unggahan dilakukan (baris gmailapi.google.com dalam contoh di atas)
5. Ketika tanggal asli tidak turut disertakan, Gmail mengatur INTERNALDATE ke timestamp unggahan
6. Pesan mendarat di Gmail dengan tanggal hari ini

Langkah 4 dan 5 adalah yang paling penting. Gmail menambahkan header itu ke setiap pesan yang diunggah melalui API-nya, apa pun yang dikirim oleh tool, dan GSMMO tidak memiliki setelan untuk meneruskan atau mempertahankan tanggal asli. Hasilnya, semua email lama Anda terlihat seperti baru tiba hari ini.

Beberapa administrator telah mencoba menjalankan GSMMO dengan setelan Google Workspace tertentu diaktifkan atau menyesuaikan setelan profil GSMMO. Tidak satu pun dari ini memengaruhi perilaku tanggal. Header Received: ditambahkan di sisi Google, dan tidak ada konfigurasi sisi klien yang mengubahnya.

Skenario GSMMO Spesifik yang Merusak Tanggal

Tidak setiap migrasi GSMMO berujung pada kekacauan tanggal, meskipun sebagian besar begitu. Berikut situasi yang penting:

• File PST ke Gmail: Tanggal rusak. Ini adalah kasus penggunaan GSMMO paling umum dan paling terdampak.
• Profil Outlook ke Gmail: Tanggal rusak. Unggahan API Gmail yang sama seperti impor PST.
• Exchange Online (Microsoft 365) ke Gmail via GSMMO: Tanggal rusak. GSMMO membaca dari server Exchange dan mengunggah melalui API Gmail.
• Exchange on-premises ke Gmail via GSMMO: Tanggal rusak. Mekanisme yang sama.
• Gmail ke Gmail (impor ulang ekspor PST): Tanggal rusak. Bahkan jika email asli memiliki tanggal yang benar di PST, impor ulang memberikan cap tanggal baru.

Polanya jelas. Setiap pesan yang diunggah melalui API Gmail mendapat header Received: dengan tanggal hari unggahan. GSMMO selalu menggunakan jalur ini.

Yang membuat ini sangat membuat frustrasi adalah laporan migrasi GSMMO menampilkan semuanya sebagai berhasil. Tidak ada peringatan tentang tanggal, tidak ada error, tidak ada tanda. Anda harus membandingkan timestamp secara manual sebelum dan sesudah migrasi untuk menemukannya, dan sebagian besar administrator tidak melakukan itu sampai ada pengguna yang mengeluh.

Dampaknya Melampaui Pengurutan

Tanggal yang salah setelah migrasi GSMMO menciptakan masalah nyata yang melampaui kotak masuk yang berantakan.

Bayangkan Anda seorang akuntan yang baru pindah ke Google Workspace. Anda perlu menemukan semua korespondensi klien dari Q3 2024 untuk pelaporan pajak. Anda mencari di Gmail berdasarkan rentang tanggal: Juli sampai September 2024. Nol hasil. Setiap email dari periode itu sekarang menunjukkan tanggal migrasi, jadi filter tanggal Gmail tidak dapat menemukannya. Anda terjebak menggulir ribuan pesan atau mencari berdasarkan kata kunci sambil berharap Anda mengingat istilah yang tepat.

Untuk industri yang diatur secara ketat, ini lebih buruk daripada sekadar tidak nyaman. Timestamp email berfungsi sebagai bukti hukum. Seorang penasihat keuangan yang perlu membuktikan bahwa ia mengirim pengungkapan sebelum tanggal transaksi tidak dapat melakukannya ketika email menunjukkan April 2026 dan bukan Februari 2023. Audit kepatuhan menurut SOX atau HIPAA bergantung pada timestamp komunikasi yang akurat, dan tanggal yang salah berarti audit yang gagal.

Lalu ada masalah threading. Gmail mengelompokkan percakapan berdasarkan tanggal dan subjek. Ketika setiap pesan dalam sebuah thread menunjukkan tanggal yang sama, tampilan percakapan menjadi berantakan. Balasan muncul sebelum pesan asli. Seluruh struktur thread runtuh menjadi kumpulan email dengan tanggal yang identik.

Memperbaiki Tanggal GSMMO dengan Redate.io

Kabar baiknya: header Date: asli itu masih utuh di dalam setiap email yang dimigrasikan. GSMMO tidak memodifikasi konten pesan. Tanggal yang benar ada di sana, hanya saja diabaikan oleh logika tampilan Gmail karena INTERNALDATE dan header Received teratas menunjuk ke tanggal migrasi.

Redate.io terhubung ke kotak surat Google Workspace, memindai email yang terdampak migrasi GSMMO, dan memperbaiki metadata tanggal menggunakan mesin analisis rantai header dan rekonstruksi tanggal miliknya sendiri. Redate tidak perlu mengetahui tool mana yang melakukan migrasi: Redate menemukan email yang tanggal tampilannya tidak sesuai dengan tanggal aslinya, dan memperbaikinya tanpa mengubah konten pesan, lampiran, atau threading.

Setiap email yang diperbaiki menjalani verifikasi individual: integritas pesan, pelestarian lampiran, pemetaan label, dan konsistensi thread. Email asli disimpan di folder cadangan Redate.io - Originals yang terlihat di kotak surat Anda sendiri sampai Anda menghapusnya sendiri.

Bisakah Anda memperbaikinya sendiri dengan skrip? Memahami masalahnya adalah satu hal. Memperbaiki 12.000 email tanpa merusak tanda tangan S/MIME, membuat bagian MIME bersarang rusak, atau mengacak header berenkode RFC 2047 di seluruh kotak surat produksi adalah hal yang sama sekali berbeda. Bagaimana Anda menangani email dengan lampiran 38 MB dan batas MIME rusak yang diimpor GSMMO tapi hampir saja tidak tetap utuh? Bagaimana Anda memverifikasi bahwa setiap pesan tunggal masuk dengan utuh? Skrip yang berfungsi pada 20 pesan uji di laboratorium tidak akan bertahan di kotak surat sungguhan dengan 8 tahun korespondensi.

Panduan Khusus Platform untuk GSMMO

Karena GSMMO memigrasikan secara khusus ke Google Workspace, perbaikan terjadi di tingkat Gmail. Tapi email yang terdampak terlihat di setiap klien yang terhubung ke akun Gmail itu:

• Perbaiki tanggal migrasi GSMMO di Gmail
• Perbaiki tanggal migrasi GSMMO di Outlook (terhubung ke Google Workspace)
• Perbaiki tanggal migrasi GSMMO di Apple Mail

Sudah bermigrasi beberapa bulan yang lalu? Header Date asli tidak menurun kualitasnya seiring waktu. Redate.io dapat memperbaiki email yang terdampak GSMMO, baik migrasi terjadi minggu lalu atau tiga tahun lalu.

Migrasi GSMMO membuat email Anda memiliki tanggal yang salah? Jalankan pemindaian gratis untuk melihat jumlah pasti email yang terdampak dan biaya perbaikannya, sebelum berkomitmen pada apa pun.