CloudM Migrate: corregir fechas de email incorrectas

El problema de fechas de CloudM Migrate del que nadie le advierte

CloudM Migrate terminó el trabajo. El panel muestra 100 % completado, todos los usuarios migrados, cero errores. Se cierra el ticket del proyecto y se pasa al siguiente cliente.

Una semana después, el director de TI llama. "?Por qué cada email de mi bandeja muestra el 2 de abril?"

No algunos emails. Todos. Cinco años de correspondencia con clientes, documentos legales, registros de RRHH, órdenes de compra de 2020, todos mostrando la fecha en que CloudM ejecutó la migración. Los mensajes están ahí, el contenido está intacto, los adjuntos están bien. Pero las fechas están mal en cada uno.

Esto no es un bug de CloudM. La documentación de soporte de CloudM lo reconoce abiertamente. El problema está en la intersección entre cómo las herramientas de migración transfieren mensajes y cómo los servidores de correo destino manejan los metadatos de email entrante. Pero saber eso no ayuda a su cliente cuya bandeja de entrada se volvió imposible de ordenar cronológicamente.

Cómo CloudM transfiere los mensajes realmente

CloudM Migrate se conecta a las plataformas de origen y destino a través de sus API. Para Google Workspace, eso significa una cuenta de servicio con delegación a nivel de dominio (configurada en la Consola de Administración de Google bajo Seguridad > Controles de API). Para Microsoft 365, utiliza Exchange Web Services o la API de Microsoft Graph, dependiendo de la ruta de migración.

Cuando CloudM lee un mensaje del origen, obtiene el contenido completo RFC 2822, incluyendo todos los encabezados originales y el cuerpo del mensaje. El encabezado Date: original (el que el servidor del remitente estampó cuando el email se envió por primera vez) viene intacto. Lo mismo para todos los encabezados Received: originales que trazan la ruta de entrega del mensaje.

El problema ocurre al escribir la copia. El destino conserva la fecha que se le entrega: Microsoft 365 y Gmail mantienen la fecha original cuando la copia la lleva. Cuando no la lleva, la copia recibe como fecha el momento de la inserción. Y en Google Workspace, cada mensaje escrito mediante la API de Gmail recibe además un encabezado Received: nuevo con la fecha del momento de la inserción.

Así se ven los encabezados que conserva uno de esos correos después de una migración CloudM a Microsoft 365:

Date: Mon, 23 Sep 2019 14:06:58 +0200
Received: from mail.original-company.com
    by smtp.original-company.com; Mon, 23 Sep 2019 14:07:11 +0200

El encabezado Date: original de 2019 sigue ahí, y también la cadena Received: original. Pero en Microsoft 365, la fecha que Outlook muestra como recibida es el registro propio del buzón sobre el momento en que llegó cada correo: si CloudM no transmitió la fecha original, ese registro dice 2 de abril de 2026.

La opción "Strip Received Headers" de CloudM

CloudM ofrece una configuración para este problema. En los Ajustes Avanzados de la plataforma destino, bajo Message Options, hay un interruptor "Strip Received Headers". Cuando se activa, CloudM elimina los encabezados Received antes de insertar el mensaje y los reemplaza con un único encabezado que coincide con el encabezado Date: del email.

Suena como si resolviera todo, ?verdad? No del todo.

Primero, hay que saber de esta opción antes de ejecutar la migración. La mayoría de los administradores descubren el problema de fechas después de que la migración está completa. Para entonces, los mensajes ya están en el destino con fechas incorrectas. Volver a ejecutar CloudM con la opción activada solo crea duplicados, no corrige lo que ya está ahí.

Segundo, esta configuración tiene una limitación fuerte cuando Google Workspace es el destino. La propia documentación de Google lo confirma: Gmail siempre reescribe los encabezados Received: en mensajes insertados via API, estampándolos con la marca de tiempo de inserción. Esta es una restricción a nivel de plataforma que CloudM no puede eludir. Incluso con "Strip Received Headers" activado, Google Workspace agrega su propio encabezado Received: con la fecha de migración.

Para destinos Microsoft 365, la configuración importa menos: Microsoft 365 conserva la fecha que se le entrega, así que lo que decide la fecha mostrada es si CloudM transmite la fecha original de cada correo.

?Cuáles migraciones CloudM rompen las fechas (y cuáles no)?

No toda migración CloudM produce fechas incorrectas. El resultado depende de la combinación origen-destino y la ruta API específica que CloudM utiliza:

• Google Workspace a Microsoft 365: Las fechas se rompen. CloudM lee vía la API de Gmail y escribe en Exchange, y cada correo recibe la fecha de la copia.
• Microsoft 365 a Google Workspace: Las fechas se rompen. Incluso con Strip Received Headers, la API de Google reescribe el encabezado Received con la fecha de inserción. La documentación de soporte de CloudM lo llama una "limitación estricta de la plataforma".
• Google Workspace a Google Workspace: Las fechas se rompen. Cambios de dominio, consolidaciones de tenant, fusiones por adquisición: cada mensaje escrito mediante la API de Gmail recibe un encabezado Received: con la fecha de la migración.
• Exchange local a Microsoft 365: Todo depende de la fecha que transmita CloudM, ya sea que la copia pase por IMAP o por EWS.
• Origen IMAP (genérico) a cualquier destino: Las fechas se rompen. Misma regla: cuando CloudM se conecta a un servidor IMAP genérico como origen, la copia muestra la fecha de la migración siempre que la fecha original no se transmita al destino.

?La parte complicada? El panel de migración de CloudM no señala nada de esto. La barra de progreso se llena, la columna de estado dice "Completed", los conteos de elementos coinciden. Desde la perspectiva de CloudM, la migración fue exitosa. Y técnicamente, lo fue. Los mensajes se transfirieron. Las fechas simplemente no sobrevivieron al viaje.

CloudM Managed vs. Self-Service: mismo problema de fechas

CloudM ofrece dos modelos de despliegue. La versión SaaS (CloudM Migrate alojado) se ejecuta completamente en la infraestructura de CloudM. La versión autoalojada permite desplegar servidores de migración primarios y secundarios en su propia red, Google Cloud, Azure o AWS.

Algunos MSP suponen que la opción autoalojada da más control sobre el manejo de fechas ya que se administran directamente los servidores de migración. No es así. Lo que decide la fecha es lo que el motor de migración transmite junto con cada mensaje, y ese motor es el mismo dondequiera que se ejecute. Ya sea que su granja de migración corra en la nube de CloudM o en su propia VM de Azure, el resultado para las fechas es el mismo.

CloudM también ofrece una "Serviced Migration" totalmente gestionada donde su equipo maneja el proyecto de principio a fin. Mismo resultado para las fechas. La ingeniería es idéntica, solo cambian las manos en el teclado. ?Alguna vez ha pagado por un servicio premium y recibido la misma limitación que el nivel gratuito? Eso es exactamente lo que se siente.

La complicación de los encabezados Date inválidos

Hay otro comportamiento específico de CloudM que empeora las cosas. Cuando CloudM encuentra un email de origen con un encabezado Date: que no cumple con RFC 822 (zona horaria malformada, día de la semana faltante, formato no estándar), modifica el encabezado para asegurar que el mensaje pueda ser migrado.

Esto significa que algunos emails pierden incluso su referencia de fecha original. El encabezado Date: modificado podría no coincidir en absoluto con la fecha real de envío. La documentación de soporte de CloudM menciona este comportamiento bajo "Possible Changes to Migrated Items" pero no especifica en qué se convierte la fecha modificada.

Para un buzón con 12.000 mensajes acumulados durante ocho años, podría haber cientos de emails con encabezados Date ligeramente no estándar (especialmente mensajes de servidores de correo antiguos, sistemas automatizados o remitentes internacionales con particularidades en el formato de zona horaria). Tras la modificación de CloudM, sumada a una copia que no lleva la fecha original, estos mensajes terminan con fechas que no guardan ninguna relación con la realidad.

Por qué las correcciones manuales no escalan después de CloudM

?Se podría corregir esto manualmente? Técnicamente, el encabezado Date: original sigue incrustado en la mayoría de los mensajes (excepto los que CloudM modificó por cumplimiento RFC). Algunos administradores han intentado escribir scripts para corregir fechas después de una migración CloudM.

La realidad de ese enfoque: hablamos de conectarse a potencialmente miles de buzones, cada uno con miles de mensajes. Para cada email, se necesita parsear la cadena completa de encabezados, identificar cuáles encabezados Received: agregó CloudM o el servidor destino, manejar los casos límite (mensajes firmados con S/MIME donde la modificación de encabezados rompe la firma, contenido cifrado con PGP, estructuras MIME multiparte con límites anidados, encabezados no-ASCII codificados con RFC 2047 de remitentes japoneses o coreanos), y hacer todo esto sin perder un solo adjunto ni romper el hilo de las conversaciones.

Un script que funciona con 50 emails de prueba de un buzón limpio no sobrevivirá al contacto con un entorno de producción de 40.000 mensajes a lo largo de una década. ?Qué pasa cuando se encuentra un email de 47 MB con seis adjuntos anidados? ?Y los límites de tasa de las API (250 unidades de cuota por usuario por segundo en Google, la limitación de Microsoft a unas 10.000 solicitudes por 10 minutos)? ?Cuál es el plan de rollback cuando algo sale mal en el mensaje número 8.347?

Y la pregunta real que la mayoría de los administradores no hacen hasta que es demasiado tarde: ?cómo se verifica que cada mensaje corregido está realmente intacto?

Corregir fechas de migración CloudM con Redate.io

Redate.io se conecta directamente a los buzones afectados (Google Workspace, Microsoft 365 o IMAP) y escanea en busca de correos cuya fecha mostrada no coincide con su fecha original. El escaneo es gratuito y tarda un par de minutos por buzón, mostrando el conteo exacto de mensajes afectados antes de cualquier compromiso.

La corrección utiliza un motor propietario de análisis de cadenas de encabezados y no necesita saber qué herramienta hizo la migración. Redate.io realiza una corrección dirigida de metadatos sin alterar el contenido del mensaje, preservando adjuntos, hilos de conversación, etiquetas, carpetas y firmas digitales. Cada mensaje corregido pasa por verificación individual, comprobando la integridad del mensaje contra el original antes de que el proceso avance.

Los emails originales se conservan en una carpeta de respaldo visible Redate.io - Originals hasta que usted mismo los elimine. Si algo necesita revertirse, los originales están ahí mismo en el buzón, no enterrados en algún archivo externo.

Para MSP que usaron CloudM en entornos de clientes, Redate.io maneja correcciones de múltiples buzones a escala, con la misma verificación por mensaje ya sea que se corrija 1 buzón o 500. El problema de fechas que CloudM dejó atrás no tiene por qué convertirse en una característica permanente del entorno de correo de su cliente.

Guías de corrección por plataforma para migraciones CloudM

El proceso de corrección se adapta a la plataforma destino. Redate.io maneja las especificidades de cada plataforma automáticamente, pero para detalles sobre su configuración:

• Corregir fechas de migración CloudM en Gmail
• Corregir fechas de migración CloudM en Outlook
• Corregir fechas de migración CloudM en Google Workspace
• Corregir fechas de migración CloudM en Microsoft 365

Para una explicación detallada de por qué esto ocurre con todas las herramientas de migración (no solo CloudM), consulte por qué los emails muestran fechas incorrectas después de la migración.

?Migró con CloudM y tiene fechas incorrectas en cada email? Ejecute un escaneo gratuito para ver exactamente cuántos mensajes están afectados y cuánto cuesta corregirlos.