GSMMO cambió las fechas de sus correos? Así se corrige

GSMMO y el problema de fechas del que nadie advierte

Google Workspace Migration for Microsoft Outlook (GSMMO) es la herramienta de escritorio que Google ofrece para migrar archivos PST, perfiles de Outlook y archivos de correo locales a Gmail. Es gratuita, oficialmente soportada, y es la ruta de migración que Google recomienda cuando se traslada un equipo pequeño o unos pocos buzones individuales de Outlook a Google Workspace.

La herramienta funciona. Los correos llegan a Gmail, la estructura de carpetas se convierte en etiquetas, los contactos se transfieren. Pero abra Gmail después y ordene por fecha. Cada correo muestra la fecha de hoy. esa propuesta que envió en enero de 2021? Abril de 2026. La factura de su contador de marzo de 2023? También abril de 2026.

GSMMO no avisa de que esto va a ocurrir. El registro de migración muestra éxito para cada mensaje. La propia documentación de Google no lo menciona como limitación conocida. Solo se descubre cuando alguien busca un correo antiguo por rango de fechas y obtiene cero resultados.

Cómo GSMMO sube realmente sus correos

GSMMO lee los mensajes del archivo PST (o directamente del perfil de Outlook) y los sube a Gmail a través de la API de Gmail (las propias notas de la versión de la herramienta de Google lo confirman). Aquí es donde se origina el problema de fechas, y vale la pena entender la mecánica porque explica por qué la solución no es tan simple como "reimportar".

Cuando GSMMO sube un mensaje a través de la API de Gmail, Gmail añade un nuevo encabezado Received: con la fecha del momento de la subida. Y cuando la fecha original no se transmite junto con el mensaje, el INTERNALDATE, la marca de tiempo que Gmail usa internamente para ordenar y mostrar, se establece en el momento de la subida en lugar de la fecha de envío original.

Así se ve la cadena de encabezados después de una migración 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

?Ve ese encabezado Date: original de septiembre de 2019? Sigue ahí, intacto. GSMMO no modifica el cuerpo del mensaje ni los encabezados originales. Pero Gmail lo ignora para la visualización y usa el INTERNALDATE, que ahora dice abril de 2026.

GSMMO vs. herramientas de migración para administradores

Aquí es donde suele empezar la confusión. Google tiene varias herramientas de migración, y no todas se comportan igual.

GSMMO (la aplicación de escritorio) se ejecuta en la máquina del usuario. Lee de Outlook o de un archivo PST y sube los correos a través de la API de Gmail. El usuario necesita una cuenta de Google Workspace y el plugin GSMMO instalado en Outlook. Es una herramienta del lado del cliente.

Google Workspace Migration Service (la herramienta de la consola de administración) funciona del lado del servidor. Un administrador la configura en la Consola de Administración de Google, la apunta a un servidor Exchange u otro tenant de Google Workspace, y la migración se ejecuta en la infraestructura de Google. Esta herramienta maneja las fechas algo mejor en algunas configuraciones porque puede establecer el INTERNALDATE a partir de los metadatos de origen. Pero "algo mejor" no significa "fiable", y muchos administradores reportan el mismo problema de fechas con esta herramienta también.

¿La diferencia clave? Con GSMMO, no hay inteligencia del lado del servidor para preservar las fechas. Cada mensaje que sube recibe el mismo trato, ya sea un correo reciente o un mensaje archivado de hace 10 años: un encabezado Received: con la fecha del día de la subida. Punto.

Por qué la preservación de fechas de GSMMO no funciona

Si ha revisado la configuración de GSMMO, tal vez haya notado que no existe una opción "preservar fechas". No es un descuido. GSMMO depende de cómo Gmail maneja los mensajes subidos a través de su API y no puede anularlo.

Esta es la cadena técnica de eventos:

1. GSMMO lee el mensaje del archivo PST, incluyendo sus marcas de tiempo originales
2. GSMMO sube los datos del mensaje a través de la API de Gmail
3. Gmail recibe la subida y almacena el mensaje en el buzón
4. Gmail añade un nuevo encabezado Received: con la fecha del momento de la subida (la línea gmailapi.google.com del ejemplo anterior)
5. Cuando la fecha original no se transmite, Gmail establece el INTERNALDATE a la marca de tiempo de subida
6. El mensaje llega a Gmail con la fecha de hoy

Los pasos 4 y 5 son los que importan. Gmail añade ese encabezado a cada mensaje subido a través de su API, sea lo que sea que envíe la herramienta, y GSMMO no tiene ninguna opción para transmitir o conservar la fecha original. El resultado: todos sus correos históricos parecen haber llegado hoy.

Algunos administradores han intentado ejecutar GSMMO con configuraciones específicas de Google Workspace o ajustando los parámetros del perfil GSMMO. Nada de eso afecta el comportamiento de las fechas. El encabezado Received: se añade del lado de Google, y ninguna configuración del lado del cliente cambia eso.

Escenarios GSMMO que corrompen las fechas

No todas las migraciones GSMMO terminan en caos de fechas, aunque la mayoría sí. Estos son los casos afectados:

• Archivo PST a Gmail: Las fechas se corrompen. Es el caso de uso más común de GSMMO y el más afectado.
• Perfil de Outlook a Gmail: Las fechas se corrompen. Misma subida a través de la API de Gmail que la importación PST.
• Exchange Online (Microsoft 365) a Gmail vía GSMMO: Las fechas se corrompen. GSMMO lee del servidor Exchange y sube a través de la API de Gmail.
• Exchange local a Gmail vía GSMMO: Las fechas se corrompen. Mismo mecanismo.
• Gmail a Gmail (reimportación de exportación PST): Las fechas se corrompen. Incluso si los correos originales tenían fechas correctas en el PST, la reimportación los reestampa.

El patrón es claro. Todo mensaje subido a través de la API de Gmail recibe un encabezado Received: con la fecha del día de la subida. GSMMO siempre usa esta ruta.

Lo que hace esto particularmente frustrante es que el informe de migración GSMMO muestra todo como exitoso. Sin advertencias sobre fechas, sin errores, sin alertas. Habría que comparar manualmente las marcas de tiempo antes y después de la migración para detectarlo, y la mayoría de los administradores no hacen eso hasta que un usuario se queja.

El impacto va mucho más allá de ordenar

Las fechas incorrectas después de una migración GSMMO crean problemas reales que van más allá de una bandeja de entrada desordenada.

Imagine que es contable y acaba de migrar a Google Workspace. Necesita encontrar toda la correspondencia de clientes del T3 de 2024 para una declaración fiscal. Busca en Gmail por rango de fechas: julio a septiembre de 2024. Cero resultados. Cada correo de ese periodo ahora muestra la fecha de migración, así que el filtro de fechas de Gmail no puede encontrarlos. Le toca recorrer miles de mensajes o buscar por palabra clave esperando recordar los términos correctos.

Para sectores regulados, esto es peor que molesto. Las marcas de tiempo de correo electrónico sirven como evidencia legal. Un asesor financiero que necesita demostrar que envió una divulgación antes de una fecha de transacción no puede hacerlo cuando el correo muestra abril de 2026 en lugar de febrero de 2023. Las auditorías de cumplimiento bajo el RGPD o la LOPD dependen de marcas de tiempo de comunicación precisas, y fechas incorrectas significan auditorías fallidas.

Y luego está el problema del threading. Gmail agrupa las conversaciones por fecha y asunto. Cuando cada mensaje de un hilo muestra la misma fecha, la vista de conversación se desordena. Las respuestas aparecen antes del mensaje original. Toda la estructura del hilo se derrumba en un montón de correos con la misma fecha.

Corregir las fechas GSMMO con Redate.io

La buena noticia: ese encabezado Date: original sigue intacto dentro de cada correo migrado. GSMMO no modifica el contenido del mensaje. La fecha correcta está ahí, simplemente Gmail la ignora para la visualización porque el INTERNALDATE y el encabezado Received superior apuntan a la fecha de migración.

Redate.io se conecta al buzón de Google Workspace, escanea los correos afectados por la migración GSMMO, y corrige los metadatos de fecha mediante un motor propietario de análisis de cadena de encabezados y reconstrucción de fechas. Redate.io no necesita saber qué herramienta hizo la migración: encuentra los correos cuya fecha visible no coincide con su fecha original, y los corrige sin alterar el contenido del mensaje, los archivos adjuntos ni el threading.

Cada correo corregido pasa por una verificación individual: integridad del mensaje, preservación de adjuntos, mapeo de etiquetas y consistencia de hilos. Los originales permanecen en una carpeta visible Redate.io - Originals hasta que usted mismo los elimine.

?Podría corregir esto usted mismo con un script? Entender el problema es una cosa. Corregir 12.000 correos sin romper firmas S/MIME, corromper partes MIME anidadas o destrozar encabezados codificados RFC 2047 en un buzón de producción es otra completamente distinta. ?Cómo maneja el correo con un adjunto de 38 MB y un límite MIME corrupto que GSMMO importó pero apenas logró mantener? Un script que funciona con 20 mensajes de prueba en laboratorio no sobrevivirá a un buzón real con 8 años de correspondencia.

Guías de corrección por plataforma para GSMMO

Dado que GSMMO migra específicamente a Google Workspace, la corrección se aplica a nivel de Gmail. Pero los correos afectados son visibles en cada cliente conectado a esa cuenta de Gmail:

• Corregir fechas de migración GSMMO en Gmail
• Corregir fechas de migración GSMMO en Outlook (conectado a Google Workspace)
• Corregir fechas de migración GSMMO en Apple Mail

?Migró hace meses? El encabezado Date original no se degrada con el tiempo. Redate.io puede corregir correos afectados por GSMMO ya sea que la migración haya ocurrido la semana pasada o hace tres años.

?GSMMO dejó sus correos con fechas incorrectas? Ejecute un escaneo gratuito para ver el número exacto de correos afectados y el coste de la corrección, antes de comprometerse.