Migración GWS a GWS: fechas de emails rotas

El escenario que nadie sospecha

Acaba de finalizar la migración de un tenant de Google Workspace a otro. Una adquisición, un cambio de dominio, la fusión de dos entidades que convivían bajo cuentas de G Suite separadas desde hace años. La operación salió bien, los buzones están en su sitio, los usuarios se conectan. El lunes por la mañana llega el primer ticket: "Todos mis correos tienen la misma fecha." Luego otro. Luego diez.

De entrada, piensa: tiene que ser un problema IMAP, una herramienta mal configurada, algo puntual. No una migración de Google a Google. Y sin embargo, es exactamente ahí donde ocurre.

Este escenario es probablemente el menos documentado del sector. La mayoría de administradores IT que lo encuentran pierden varias horas buscando una explicación en el cliente de correo, en Outlook, en la configuración de la cuenta, antes de darse cuenta de que el problema está en las cabeceras de los propios mensajes.

Por qué una migración de Google a Google rompe las fechas

Para entender qué ocurre, hay que volver a la mecánica de las cabeceras de correo. Cada mensaje RFC 2822 contiene un campo Date: original, añadido por el cliente o el servidor remitente en el momento del envío. Es la fecha "real" del email, la que corresponde a cuándo se redactó y envió el mensaje.

Pero existe otro mecanismo: el INTERNALDATE de IMAP. Es un metadato almacenado en el servidor que indica cuándo se depositó el mensaje en el buzón. Y aquí es donde la cosa se pone interesante.

Cuando una herramienta de migración transfiere un correo de un tenant de Google Workspace a otro, utiliza el protocolo IMAP (aunque los dos servidores sean de Google). El mensaje se lee desde el origen y se reinserta en el destino. En ese momento, el servidor de destino añade automáticamente una cabecera Received: con la marca de tiempo de la operación, es decir, la fecha de la migración.

El problema es que clientes de correo como Outlook utilizan el primer Received: de la cadena para mostrar la fecha de un mensaje, no necesariamente el campo Date: original. Resultado: todos los correos muestran la fecha del día de la migración.

Qué herramientas provocan el problema

Prácticamente todas las herramientas utilizadas para migraciones entre tenants de Google Workspace están afectadas. Sin excepciones notables:

• GSMMO (Google Workspace Migration for Microsoft Outlook): concebido originalmente para migrar desde Exchange, pero usado en algunos flujos de GWS a GWS.
• CloudM Migrate: muy extendido entre los MSPs para migraciones inter-Google, añade sistemáticamente una cabecera Received: de migración. Consulte el análisis detallado de CloudM.
• BitTitan MigrationWiz: igual, el comportamiento está documentado en este artículo sobre BitTitan.
• imapsync: la herramienta de código abierto que permite automatizar migraciones IMAP, también entre dos tenants de Google.
• Las exportaciones e importaciones manuales mediante Takeout + reimportación IMAP: menos habituales, pero producen exactamente el mismo efecto.

La razón es sencilla: todas estas herramientas funcionan como clientes IMAP estándar. No tienen acceso a una vía "nativa" de Google que preservaría los metadatos. Aunque los dos tenants estén en Google, la transferencia pasa por la capa IMAP, y esa capa no sabe que está hablando consigo misma.

La mecánica de las cabeceras Received en detalle

(Por cierto, si alguna vez ha intentado leer las cabeceras en bruto de un correo desde Gmail o Outlook, sabe que no es exactamente una lectura placentera. Pero es ahí donde se esconde toda la verdad.)

Un email que ha viajado con normalidad contiene una cadena de cabeceras Received: en orden inverso al recorrido: el último servidor que tocó el mensaje aparece en la parte superior. Tras una migración, la cabecera de migración queda en lo alto de la pila.

Así es como se ve en un mensaje migrado con CloudM de un tenant GWS a otro:

Received: from mail-migration.cloudm.io (mail-migration.cloudm.io [203.0.113.42])
        by mx.google.com with ESMTPS id xyz123
        for <usuario@nuevo-dominio.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

El campo Date: dice 2019. El primer Received: dice octubre de 2024. Outlook lee el primer Received:. El usuario ve octubre de 2024 para un correo de 2019.

El campo Date: original está intacto. No se ha movido. Esa es la buena noticia: el dato está ahí, esperando simplemente a ser utilizado correctamente.

Outlook y Gmail no se comportan igual

Es una distinción importante. Los usuarios que acceden a sus correos a través de la interfaz web de Gmail suelen ver las fechas correctas, porque Gmail prioriza el campo Date: RFC 2822 para mostrar los mensajes. El problema es menos visible en el lado web.

En cambio, los usuarios que configuran su buzón de Google Workspace en Outlook mediante IMAP (o mediante la sincronización Exchange ActiveSync) sufren de lleno la fecha incorrecta, porque Outlook utiliza el INTERNALDATE IMAP, que refleja la fecha del primer Received: añadido durante la migración.

Aclaración: para ser precisos, el comportamiento de Outlook varía según la versión y el modo de conexión. Outlook 2019 y Microsoft 365 (las versiones recientes) utilizan el INTERNALDATE cuando se conectan por IMAP. Las versiones más antiguas pueden tener comportamientos ligeramente distintos. Pero en todos los casos observados en producción, la migración de GWS a GWS por IMAP produce fechas incorrectas en Outlook.

Así que, en las organizaciones que han migrado a un nuevo tenant y mantienen usuarios híbridos (algunos en Gmail web, otros en Outlook), los tickets son incoherentes. Los equipos IT pierden tiempo intentando entender por qué "algunos están afectados y otros no", cuando la respuesta es simple: es el cliente de correo el que marca la diferencia.

Adquisiciones, fusiones, cambios de dominio: los casos más frecuentes

Este tipo de migración no es algo anecdótico. Los escenarios que generan más tickets son estos:

Adquisición de empresa

Una empresa adquirida tenía su propio tenant de Google Workspace (dominio @antiguaempresa.com). Tras la compra, todo debe migrar al tenant de la matriz (@grupo.com). Los 250 buzones, los archivos, los 8 años de historial de correo. Se contrata BitTitan o CloudM para la operación. Resultado: 2,4 millones de correos con la fecha del fin de semana de migración.

Cambio de dominio

Una empresa que redefine su marca pasa de @nombreantiguo.es a @nombrenuevo.es. Mismo tenant de Google, pero se crea uno nuevo para empezar desde cero (una decisión habitual para evitar artefactos de configuración). Se migran los buzones con imapsync o GSMMO. Las fechas se rompen exactamente igual.

Consolidación de filiales

Un grupo con 4 filiales, cada una en su propio tenant de G Suite, decide agruparlo todo en un tenant único. Cuatro migraciones en paralelo, cuatro lotes de correos con fechas corruptas a gestionar.

En estos tres escenarios el problema es idéntico y la solución es la misma. La checklist de migración de correo permite anticipar este tipo de problema antes de lanzar la migración.

Por qué un script casero no es la respuesta

Entender el problema es una cosa. Decidir "voy a escribir un script Python que limpie las cabeceras" y aplicarlo sobre 30.000 correos de producción es otra muy distinta.

Los casos límite son numerosos. Un script que funciona sobre 50 correos de prueba en un entorno limpio encontrará inevitablemente, en un buzón de producción de tamaño real:

• Mensajes con firmas S/MIME o contenido cifrado con PGP, donde cualquier modificación de la estructura del mensaje invalida la firma criptográfica.
• Correos con estructuras MIME anidadas complejas (multipart/alternative dentro de un multipart/mixed con adjuntos de varias decenas de megabytes).
• Cabeceras codificadas en RFC 2047 (caracteres no ASCII), que los analizadores mal configurados eliminan silenciosamente.
• Errores 429 Too Many Requests de la API de Google a las 2 de la mañana, en pleno batch de corrección, dejando el proceso en un estado indeterminado.
• Correos en los que la cadena de Received: es ambigua: varias herramientas de migración sucesivas han añadido cada una su cabecera, y no es trivial determinar cuál retirar.

Y la pregunta más importante: ¿cómo verificar, correo por correo, que cada mensaje corregido está intacto y que no se ha perdido ni corrompido nada? Un script casero normalmente no hace esa verificación. Redate.io la realiza de forma automática, con conservación de los originales en una carpeta de copia de seguridad visible durante 30 días.

Qué hace Redate.io con este tipo de migración

Redate.io se conecta al tenant de Google Workspace de destino (mediante delegación de dominio, sin intervención manual buzón a buzón) y analiza los correos para identificar aquellos cujos metadatos de fecha son incoherentes con el contenido del mensaje. Esta fase de análisis es gratuita y ofrece una visión exacta del alcance del problema antes de cualquier corrección.

El motor de corrección propietario analiza la cadena de cabeceras de cada mensaje, aplica correspondencia de patrones sobre las firmas conocidas de las herramientas de migración (BitTitan, CloudM, imapsync, GSMMO y otras menos habituales), y realiza una corrección selectiva de los metadatos sin alterar el contenido del mensaje. Cada correo corregido se verifica de forma individual. Los originales se conservan.

Para las migraciones entre tenants de Google Workspace específicamente, el pipeline gestiona los casos en que se han realizado varias pasadas de migración (por ejemplo, un buzón migrado por primera vez en 2021 y de nuevo en 2024), con varias capas de cabeceras parasitarias que deshacer.

Las guías de corrección CloudM hacia Google Workspace y BitTitan hacia Google Workspace detallan los pasos de conexión para este tipo de configuración.

Detectar el problema antes de que los usuarios se quejen

El mejor momento para detectar fechas corruptas es justo después de la migración, antes del go-live. Una comprobación rápida en algunos buzones piloto con un cliente IMAP como Thunderbird permite comparar la visualización de las fechas con lo que cabría esperar. Si todos los correos importados parecen tener la misma fecha reciente, es la señal característica del problema.

Pero en la práctica, el descubrimiento suele llegar varias semanas después de la migración, cuando un usuario busca un contrato antiguo y comprueba que su buzón de Gmail está perfectamente ordenado... por fecha de migración. Miles de correos apilados con el mismo sello horario. La búsqueda por fecha deja de funcionar. Los hilos de conversación aparecen desordenados. El historial parece haber desaparecido.

Para los MSPs que gestionan regularmente migraciones entre tenants de Google Workspace, incorporar un análisis de Redate.io en la checklist post-migración (antes de la validación con el cliente) evita este tipo de sorpresas.

¿Acaba de migrar entre dos tenants de Google Workspace y las fechas de sus correos son incorrectas? Inicie un análisis gratuito en Redate.io para medir el impacto antes de cualquier corrección.