BitTitan MigrationWiz: corregir fechas de email

¿Qué hace BitTitan MigrationWiz con las fechas de email?

La migración terminó el viernes pasado. 47 buzones movidos de Exchange local a Microsoft 365, todo en verde en el panel de MigrationWiz. Llega el lunes por la mañana y aparece el primer ticket: "Todos mis emails muestran el 28 de marzo de 2026."

Cada mensaje sin excepción. Años de correspondencia, propuestas de clientes de 2019, facturas de 2021, todo sellado con la fecha de migración. El registro de MigrationWiz dice que todo se transfirió correctamente (y técnicamente es verdad). Pero las fechas desaparecieron.

BitTitan MigrationWiz es una de las herramientas más utilizadas para la migración de correo electrónico cloud-to-cloud. Gestiona migraciones de Exchange a Microsoft 365, Google Workspace a Exchange, movimientos cross-tenant y mucho más. La herramienta en sí funciona bien para lo que hace. El problema de fechas no es un error de MigrationWiz. Es una consecuencia de cómo funciona el protocolo IMAP a nivel de transporte, y MigrationWiz lo desencadena de una manera específica.

¿Cómo gestiona MigrationWiz los encabezados Received?

Cuando MigrationWiz transfiere un email del origen al destino, utiliza el protocolo IMAP (o Exchange Web Services, según el tipo de endpoint). Durante este proceso, el servidor de correo de destino estampa el mensaje con un nuevo encabezado Received: que contiene la marca de tiempo actual, exactamente como lo haría con cualquier email entrante.

Así es como se ve una cadena típica de encabezados Received después de una migración con MigrationWiz:

Received: from mx.migrationwiz.com (processing-node-7.bittitan.com)
    by outlook.office365.com; Fri, 28 Mar 2026 14:23:17 +0000
Received: from original-server.company.com
    by mail.company.com; Tue, 15 Jan 2019 09:41:33 +0100

El encabezado Received: original de 2019 sigue ahí. Igual que el encabezado Date: original. Pero los clientes de correo como Outlook no usan esos. Outlook lee el encabezado Received: más reciente para determinar cuándo mostrar el mensaje, y ese encabezado ahora dice 28 de marzo de 2026.

El valor INTERNALDATE (la marca de tiempo que los servidores IMAP usan para ordenar) también se sobrescribe durante la transferencia. MigrationWiz intenta preservar las fechas cuando el destino lo soporta, pero el resultado depende en gran medida del comportamiento del servidor de destino. La cadena de transporte de Microsoft 365, por ejemplo, sobrescribe el INTERNALDATE con su propia marca de tiempo de entrega, sin importar lo que MigrationWiz solicite.

¿Por qué el "Date Mapping" de MigrationWiz no funciona?

BitTitan ofrece una función de "Date Mapping" en las Opciones Avanzadas de MigrationWiz. Sobre el papel, parece la solución. En la práctica, controla qué rango de fechas de mensajes se migra, no cómo se preservan las fechas en el destino.

La confusión es comprensible. La configuración lleva la palabra "date" en el nombre. Pero lo que realmente hace es filtrar los mensajes de origen por rango de fechas antes de la migración. Un mensaje de 2018 sigue llegando al destino con la marca de tiempo de migración.

También está la cuestión de los endpoints IMAP frente a Exchange. Cuando MigrationWiz migra entre dos servidores Exchange mediante EWS (Exchange Web Services), la preservación de fechas funciona mejor porque EWS ofrece más control sobre los metadatos del mensaje. Pero en el momento en que IMAP está involucrado en cualquiera de los dos lados, la operación IMAP APPEND toma el control y el servidor de destino decide qué marca de tiempo usar.

Algunos administradores han intentado volver a ejecutar la migración con configuraciones de endpoint diferentes, con la esperanza de que cambiar de IMAP a EWS corrigiera las fechas retroactivamente. No funciona. Los mensajes ya están en el destino con fechas incorrectas. Ejecutar MigrationWiz de nuevo solo crearía duplicados.

Escenarios de MigrationWiz que rompen las fechas

No todas las migraciones con MigrationWiz causan problemas de fechas. El problema depende de la combinación de endpoints:

• Exchange (local) a Microsoft 365 vía IMAP: Las fechas se rompen. La cadena de transporte de M365 estampa nuevos encabezados Received y sobrescribe INTERNALDATE.
• Google Workspace a Microsoft 365: Las fechas se rompen. MigrationWiz usa IMAP para leer de Google y escribe en M365, que añade sus encabezados de transporte.
• Exchange a Exchange (EWS a EWS): Las fechas normalmente se preservan. EWS evita la cadena de transporte en ambos lados.
• Cualquier origen a Google Workspace vía IMAP: Las fechas se rompen. La implementación IMAP de Google añade un encabezado Received con la marca de tiempo de inserción.
• Cross-tenant Microsoft 365: Depende del método. La ruta IMAP rompe las fechas. EWS directo puede preservarlas.

El panel de MigrationWiz no marca los problemas de fechas. Todo aparece como "Completed" porque los mensajes se transfirieron con éxito. El contenido está intacto, los archivos adjuntos están bien, la estructura de carpetas se preservó. Solo las fechas cambiaron, y MigrationWiz no lo registra como un error de migración.

El coste real de las fechas incorrectas tras MigrationWiz

Las fechas incorrectas en los emails no son solo molestas. Para las organizaciones que migraron con BitTitan, las consecuencias van más allá de un buzón desordenado.

Los equipos legales no pueden usar emails como prueba cuando cada mensaje muestra la fecha de migración en lugar de la fecha real de envío. Las auditorías fiscales requieren pruebas cronológicas de las comunicaciones. Los marcos de cumplimiento como el RGPD y la LOPD exigen un registro preciso, y los emails con marcas de tiempo fabricadas no cumplen ese requisito.

Y luego está el lado práctico. Intente encontrar aquella discusión contractual de noviembre de 2022 cuando todo su buzón muestra marzo de 2026. ¿Ordenar por fecha? Inútil. ¿Buscar por rango de fechas? Devuelve todo o nada.

Para los MSP que usaron MigrationWiz en entornos de clientes, esto crea un problema de responsabilidad. El cliente pagó por una migración. La obtuvo, pero su archivo de correo electrónico está efectivamente roto para cualquier flujo de trabajo basado en fechas.

La verdad es que un MSP del que se tuvo noticia había migrado unas 380 buzones para un bufete de abogados. Tres meses después, el equipo de litigios del bufete descubrió el problema de fechas durante el proceso de discovery. Cada email que necesitaban presentar como prueba mostraba la fecha de migración. El MSP tuvo que explicar por qué 6 años de correspondencia con marcas de tiempo mostraban todos junio de 2025.

Corregir las fechas de BitTitan MigrationWiz

El encabezado Date: original sigue dentro de cada email. MigrationWiz no toca el cuerpo del mensaje ni los encabezados originales. Son el encabezado Received: adicional y el INTERNALDATE sobrescrito los que causan el problema de visualización.

Redate.io se conecta al buzón (Google Workspace, Microsoft 365 o IMAP), analiza los emails afectados por la migración de MigrationWiz y corrige los metadatos de fecha mediante un pipeline de análisis propietario de múltiples etapas. La corrección apunta específicamente a la capa de metadatos, haciendo coincidencia de patrones contra firmas conocidas de encabezados MigrationWiz, incluyendo los identificadores característicos mx.migrationwiz.com y bittitan.com en la cadena Received.

Cada email corregido se verifica individualmente contra el original. La verificación comprueba la integridad del mensaje, la preservación de archivos adjuntos, la ubicación en carpetas y el threading. Los emails originales se conservan en una carpeta visible Redate.io - Originals durante 30 días por si se necesita revertir.

Entender el problema es una cosa. Corregir 15.000 emails sin perder un solo archivo adjunto, romper firmas S/MIME o corromper fronteras MIME multipart es otra. Un script que funciona con 10 mensajes de prueba en laboratorio no manejará los casos límite de un buzón en producción con 7 años de correspondencia, mensajes cifrados con PGP y encabezados non-ASCII RFC 2047.

¿Cómo se verifica que cada mensaje corregido está intacto? ¿Que el threading sigue funcionando, que las invitaciones de calendario siguen resolviéndose, que el archivo adjunto de 47 MB de ese email de 2020 no se corrompió? Redate.io hace esto automáticamente, para cada mensaje individual. Y si algo parece incorrecto, el original está ahí en la carpeta de respaldo.

El análisis gratuito tarda unos dos minutos. Se conecta al buzón, identifica cada email sellado con la fecha de migración de MigrationWiz y muestra el número exacto y el coste antes de pagar nada. Sin tarjeta de crédito, sin compromiso.

Guías de corrección por plataforma para BitTitan

El proceso de corrección varía según dónde MigrationWiz movió sus emails. Redate.io gestiona las particularidades de cada plataforma automáticamente, pero si desea detalles sobre su configuración específica:

• Corregir fechas de BitTitan en Outlook
• Corregir fechas de BitTitan en Microsoft 365
• Corregir fechas de BitTitan en Google Workspace
• Corregir fechas de BitTitan en Exchange Online

Redate.io también funciona para migraciones completadas hace meses o años. El encabezado Date original no caduca.

¿Migró con BitTitan MigrationWiz y tiene fechas incorrectas? Ejecute un análisis gratuito para ver exactamente cuántos emails están afectados antes de comprometerse con nada.