Migración IMAP a Microsoft 365: guía para empresas

Qué resuelve una migración IMAP a Microsoft 365

Una migración IMAP a Microsoft 365 traslada correo que está disponible en el servidor de origen. Antes de elegir este método hay que comprobar si ese es todo el contenido que necesita la empresa. Los contactos, calendarios, reglas y datos guardados únicamente en equipos locales requieren una revisión separada. De lo contrario, el usuario puede encontrar sus mensajes en destino y seguir echando en falta información importante para trabajar.

El inventario debe registrar las direcciones reales, los accesos de origen, el volumen y la estructura de carpetas. También conviene identificar cuentas compartidas y aplicaciones que envían correo. Una dirección utilizada por varios empleados puede necesitar una configuración distinta de la de un buzón individual. Esa decisión pertenece al diseño de Exchange Online y no se obtiene simplemente al copiar mensajes.

El piloto compara una muestra que incluya correo reciente, antiguo, enviado y organizado en carpetas. Se revisan adjuntos y elementos que el informe identifique como omitidos o erróneos. Las diferencias de recuento necesitan explicación, porque filtros de fecha, carpetas excluidas o contenido no admitido pueden afectar al resultado. El informe debe permitir localizar la causa y decidir si hace falta una corrección.

Qué comprobar cuando se cambia la recepción del correo

La copia y el cambio de recepción son trabajos distintos. Antes de actualizar el servicio del dominio deben estar preparados los destinatarios, las direcciones alternativas y el acceso de los usuarios. El plan debe indicar qué entorno recibe los mensajes nuevos en cada fase y cómo se recogerá el correo que todavía haya llegado al sistema anterior durante la transición.

Después del cambio se prueba envío y recepción interna y externa con destinatarios representativos. Se revisan también formularios web, impresoras y aplicaciones que dependen del correo. Si estos sistemas siguen apuntando a una configuración anterior, el usuario puede trabajar con normalidad en Outlook mientras una parte del proceso empresarial deja de enviar notificaciones. Esas pruebas deben figurar en la aceptación del proyecto.

Qué es IMAP y por qué se utiliza para migrar correo

IMAP —Internet Message Access Protocol— permite que un cliente de correo acceda a los mensajes almacenados en un servidor. A diferencia de un modelo POP3 tradicional, en el que los mensajes pueden descargarse al equipo y desaparecer posteriormente del servidor, IMAP está pensado para mantener la información de correo en el servidor y sincronizar su estado con los clientes. Eso hace que sea relativamente adecuado como protocolo de extracción de mensajes durante una migración.

Microsoft puede conectarse al servidor IMAP origen, leer las carpetas disponibles y copiar sus mensajes dentro del buzón Exchange Online correspondiente. Pero IMAP sigue siendo un protocolo de correo. No conoce el modelo completo de Exchange. Por ejemplo, IMAP no representa directamente: un calendario Exchange, permisos Full Access, Send As, salas, recursos, delegados, políticas de retención o grupos Microsoft 365.

Por eso utilizar IMAP para migrar desde una plataforma más rica puede reducir considerablemente la fidelidad del proyecto.

IMAP, POP3 y Exchange Online: diferencias importantes

Cuándo tiene sentido una migración IMAP

IMAP es especialmente útil cuando el sistema origen proporciona esencialmente correo y no dispone de una API o método de migración más completo.

La pregunta no es solo “¿tiene IMAP?”. También debemos preguntarnos: ¿qué información necesitamos conservar? Si solo necesitamos correo y carpetas, IMAP puede ser suficiente. Si necesitamos además calendarios, contactos, reglas, delegaciones o recursos, deberíamos comprobar si existe una ruta más completa.

Cuándo IMAP no debería ser nuestra primera opción

Exchange Server. Si el origen es un Exchange Server al que tenemos acceso suficiente, normalmente deberíamos evaluar las rutas de migración propias de Exchange. Utilizar IMAP implicaría tratar un buzón Exchange como un simple repositorio de correo y perder capacidad para trasladar otros elementos. Google Workspace. Microsoft dispone actualmente de un procedimiento específico de migración de Google Workspace capaz de abordar: correo, calendario y contactos y determinadas capacidades adicionales.

Por tanto, una organización que utiliza Google Workspace no debería seleccionar IMAP automáticamente solo porque Gmail también exponga ese protocolo. Otro tenant Microsoft 365. Una migración Exchange Online → Exchange Online debería analizarse como tenant-to-tenant, no como IMAP. Microsoft dispone de Cross-Tenant Mailbox Migration y también existen plataformas especializadas. PST como fuente real. Si el servidor IMAP conserva solo los últimos meses, pero los usuarios disponen de años de información en PST, la fuente correcta puede no ser IMAP.

En ese caso habrá que combinar procedimientos.

Qué se migra mediante IMAP

La migración IMAP nativa de Microsoft está diseñada para copiar los elementos existentes dentro de las carpetas de correo del usuario.

No todas las carpetas tienen el mismo nombre. Dependiendo del servidor podemos encontrar: Sent Sent Items INBOX.Sent Enviados Trash Deleted Items Por eso el piloto debería revisar especialmente las carpetas especiales.

Qué no se migra mediante IMAP

Esta diferencia debería aparecer expresamente en el alcance del proyecto para evitar que el usuario interprete que “migrar su correo” significa trasladar absolutamente toda la configuración que observa en Outlook.

Assessment: qué analizar antes de crear el primer batch

Un assessment IMAP no tiene por qué ser complicado, pero sí debería responder las preguntas que condicionan la migración.

No basta con medir gigabytes. Un buzón de 20 GB con 30.000 mensajes puede comportarse de forma distinta de otro buzón de 8 GB con 400.000 elementos pequeños. En IMAP importa: volumen, número de elementos, tamaño de los mensajes, número de carpetas, rendimiento del servidor origen.

Analizar el servidor IMAP origen

Antes de crear el migration endpoint deberíamos comprobar los parámetros técnicos del servidor.

Probar el endpoint antes de migrar cientos de usuarios. Uno de los objetivos del piloto es confirmar que Microsoft 365 puede establecer sesiones de forma consistente y que el servidor origen no comienza a bloquear conexiones al incrementar la concurrencia.

Credenciales: un aspecto crítico de la migración IMAP

Microsoft necesita poder autenticarse contra cada buzón origen para copiar sus mensajes.

CSV nativo de Microsoft

El formato básico contiene actualmente:

EmailAddress,UserName,Password
usuario1@empresa.com,usuario1@empresa.com,ContraseñaOrigen
usuario2@empresa.com,usuario2@empresa.com,ContraseñaOrigen

EmailAddress identifica el buzón destino de Microsoft 365. UserName identifica la cuenta en el servidor IMAP. Password contiene la credencial que permite al servicio acceder al buzón origen. ¿Hace falta conocer las contraseñas de todos los usuarios?. Depende del servidor. Algunos sistemas permiten utilizar una cuenta administrativa con capacidad de acceso a los buzones. Otros requieren credenciales individuales. Si el proveedor no proporciona un mecanismo administrativo compatible y tampoco disponemos de las credenciales de usuario, ese punto debe resolverse antes del proyecto.

El CSV contiene información sensible. Por tanto: debe almacenarse únicamente durante el tiempo necesario, restringir su acceso y eliminarse de forma controlada cuando ya no sea necesario. Referencia oficial: Microsoft – CSV files for IMAP migration batches.

Carpetas IMAP: un detalle pequeño que genera muchas incidencias

Una migración debería revisar las carpetas antes de mover todos los buzones. Especiales. Especialmente: Inbox, Sent, Drafts, Deleted, Junk y Archive. Nombres diferentes. Dos servidores pueden representar la misma función con estructuras distintas. Además, algunos clientes han podido crear carpetas personales que se parecen a carpetas del sistema. Barra “/” en nombres de carpeta. La documentación de optimización de Microsoft advierte específicamente de problemas con carpetas cuyo nombre contiene una barra /.

Conviene detectarlas antes del proyecto y renombrarlas cuando sea necesario. No migrar basura porque sí. Antes de mover cientos de gigabytes podemos plantearnos excluir: Spam, Junk, Trash, Deleted Items o carpetas históricas sin valor cuando las políticas de la empresa lo permitan.

¿Qué ocurre si existen PST aunque el correo sea IMAP?

Que una cuenta esté configurada mediante IMAP no garantiza que todo el histórico continúe en el servidor. Los usuarios pueden haber creado: archivos PST, archivos de AutoArchive, exportaciones manuales o carpetas locales de Outlook. Ejemplo.

Una migración únicamente mediante IMAP dejaría diez años fuera del nuevo buzón. Si los PST entran en alcance. Podemos evaluar: importación mediante Outlook clásico, Microsoft Purview Import Service u otra herramienta. Evitar solapamientos. Si el PST contiene además correo que sigue en IMAP, habrá que diseñar qué parte procede de cada fuente para reducir duplicados.

Límites actuales de la migración IMAP de Microsoft

Microsoft documenta actualmente dos límites especialmente importantes.

500.000 elementos. Microsoft procesa el correo del más reciente al más antiguo. Por tanto, un buzón que supera ese número de elementos necesita análisis antes de utilizar la vía IMAP estándar. 35 MB por mensaje. Este límite pertenece al proceso de migración IMAP, no debe confundirse con todos los límites de transporte que pueda tener Exchange Online después de la migración.

Los elementos superiores deben identificarse y tratarse mediante otra vía si tienen que conservarse. Comprobar los límites justo antes del proyecto. Las cifras de servicios cloud pueden cambiar. Por tanto, esta guía refleja la documentación vigente en la fecha de actualización, pero el runbook debería volver a comprobarla antes de ejecutar una migración real. Referencia oficial: Microsoft – IMAP migration limitations.

Rendimiento, concurrencia y throttling

La velocidad de una migración IMAP no puede predecirse únicamente a partir del ancho de banda de Internet. Intervienen al menos cuatro factores.

No aumentar concurrencia sin medir. Más conexiones no significan necesariamente una migración más rápida. Podemos conseguir exactamente lo contrario si el servidor origen comienza a: rechazar conexiones, aplicar throttling o degradar el servicio para los usuarios. El piloto sirve para encontrar el punto adecuado. Microsoft recomienda utilizar batches de prueba para determinar: tiempo real, número de conexiones adecuado y tamaño óptimo de las oleadas.

No existe una velocidad garantizada. Los servicios de migración están sujetos a mecanismos de throttling y disponibilidad. Un buzón que avanza más despacio durante un periodo no implica automáticamente que exista un fallo. Referencias oficiales:

• Microsoft – Optimize IMAP migrations
• Microsoft – Migration performance and best practices

Requisitos en Microsoft 365

La migración IMAP copia datos hacia buzones que ya existen.

Verificar un dominio no cambia el correo. Podemos añadir un dominio a Microsoft 365 mediante el correspondiente TXT y preparar todos los buzones sin modificar todavía el MX. Esto permite realizar gran parte del trabajo antes del cutover.

Licencias Microsoft 365 para Exchange Online

El usuario necesita una licencia que aprovisione un buzón Exchange Online.

Tamaño del buzón destino. Actualmente Microsoft documenta, entre otros:

El buzón destino debe tener espacio suficiente. Si queremos trasladar un origen de 70 GB a una licencia cuyo buzón principal admite 50 GB, debemos definir antes: licencia diferente, Online Archive, limpieza o un diseño alternativo. Referencia oficial: Microsoft – Exchange Online Limits.

Migración IMAP desde Exchange Admin Center

La migración puede administrarse actualmente desde Exchange Admin Center. Ruta general. Dentro de Exchange Admin Center: Migration → Add migration batch → Migrate to Exchange Online → IMAP migration. El asistente solicita.

No lanzar toda la empresa en el primer batch. Aunque técnicamente podamos cargar miles de filas en un CSV, resulta más manejable dividir el proyecto en oleadas. Esto facilita: controlar errores, analizar rendimiento, comunicar usuarios y ajustar concurrencia. Referencia oficial: Microsoft – Migrate other IMAP mailboxes.

Preparar correctamente el CSV

El CSV nativo de IMAP utiliza tres columnas obligatorias.

EmailAddress,UserName,Password
maria@empresa.com,maria@empresa.com,PasswordOrigen1
carlos@empresa.com,carlos@empresa.com,PasswordOrigen2

Significado.

El correo origen y destino no tienen por qué ser idénticos. El CSV permite que el login utilizado contra el servidor IMAP sea diferente de la identidad del nuevo buzón. Eso resulta útil en reorganizaciones de dominio. Límite del CSV. La documentación actual de Microsoft admite hasta 50.000 filas y un tamaño de 10 MB para el CSV de un batch IMAP.

Aun así, Microsoft recomienda dividir migraciones grandes en varios batches. UTF-8. Si existen caracteres especiales en los identificadores, conviene guardar el CSV con codificación Unicode/UTF-8 adecuada.

Migration Endpoint: conexión entre Microsoft 365 y el origen

El migration endpoint define cómo conectará Microsoft 365 con el servidor IMAP. Incluye. servidor, puerto, seguridad y parámetros de concurrencia.

Ejemplo

New-MigrationEndpoint `
    -IMAP `
    -Name "IMAP-Hosting" `
    -RemoteServer "imap.empresa.com" `
    -Port 993 `
    -Security Ssl

Concurrencia. También pueden configurarse valores como: MaxConcurrentMigrations y MaxConcurrentIncrementalSyncs. No utilizar valores arbitrarios. La configuración adecuada debería salir del piloto y de los límites proporcionados por el proveedor de correo. Referencia oficial: Microsoft – New-MigrationEndpoint.

Migration Batch: organizar la migración por oleadas

Una vez disponible el endpoint podemos crear uno o varios batches.

Ejemplo PowerShell

$CsvFile = "C:\Temp\IMAP-Wave01.csv"

New-MigrationBatch `
    -Name "IMAP-Wave01" `
    -SourceEndpoint "IMAP-Hosting" `
    -CSVData ([System.IO.File]::ReadAllBytes($CsvFile)) `
    -AutoStart

Comprobar el estado

Get-MigrationBatch -Identity "IMAP-Wave01" |
    Format-List Identity,Status,TotalCount,SyncedCount

Por qué dividir en oleadas.

Sincronizaciones incrementales: la gran ventaja operativa de IMAP

Después de la sincronización inicial, los batches IMAP que siguen activos pueden continuar copiando nuevos mensajes detectados en el servidor origen. Frecuencia actual. Microsoft documenta actualmente una sincronización incremental aproximadamente cada 24 horas. Esto permite premigrar. Podemos empezar a copiar buzones varios días antes del cambio definitivo.

No es replicación en tiempo real. La sincronización aproximadamente diaria significa que IMAP no debería considerarse una plataforma de coexistencia en tiempo real. El cutover sigue necesitando una ventana y un procedimiento claro. Cuándo detenerla. Después de confirmar que el correo nuevo entra en Microsoft 365 y que ya no necesitamos recuperar cambios desde el origen, podemos eliminar el batch.

Referencia oficial: Microsoft – IMAP migration with PowerShell.

Excluir o incluir carpetas

No siempre es necesario trasladar absolutamente todo lo que contiene el servidor. Exchange Online permite utilizar parámetros de inclusión y exclusión en determinados batches IMAP.

Ejemplo

$CsvFile = "C:\Temp\IMAP-Wave01.csv"

New-MigrationBatch `
    -Name "IMAP-Wave01" `
    -SourceEndpoint "IMAP-Hosting" `
    -CSVData ([System.IO.File]::ReadAllBytes($CsvFile)) `
    -ExcludeFolders "Trash/*","Spam/*" `
    -AutoStart

Casos donde puede tener sentido excluir. Junk, Spam, Trash, carpetas temporales o repositorios claramente obsoletos. No aplicar exclusiones generales sin comprobar los nombres reales. Una carpeta llamada Archive puede ser prescindible en un servidor y contener información crítica en otro. Por eso el piloto debe revisar el árbol real. Referencia oficial: Microsoft – New-MigrationBatch.

Exchange Online PowerShell útil durante la migración

Para administrar una migración tiene más sentido utilizar los cmdlets específicos de Exchange que limitarse a comprobar licencias.

Conectarse

Install-Module ExchangeOnlineManagement -Scope CurrentUser

Connect-ExchangeOnline

Ver endpoints

Get-MigrationEndpoint |
    Format-Table Identity,EndpointType,RemoteServer

Ver batches

Get-MigrationBatch |
    Format-Table Identity,Status,TotalCount,SyncedCount

Ver usuarios de un batch

Get-MigrationUser -BatchId "IMAP-Wave01" |
    Format-Table Identity,Status

Revisar un usuario con problemas

Get-MigrationUserStatistics `
    -Identity "usuario@empresa.com" `
    -IncludeReport |
    Format-List Status,Error,SkippedItemCount,Report

Revisar skipped items

Get-MigrationUserStatistics `
    -Identity "usuario@empresa.com" `
    -IncludeSkippedItems |
    Select-Object -ExpandProperty SkippedItems |
    Format-List DateReceived,Subject

Eliminar el batch cuando ya no necesitamos sincronización

Remove-MigrationBatch -Identity "IMAP-Wave01"

Los ejemplos son orientativos. Antes de ejecutarlos deben revisarse permisos, nombres, estado del batch y consecuencias operativas.

Monitorización: “Synced” no significa que todo esté perfecto

Exchange Admin Center muestra diferentes estados de los batches.

Qué mirar además del estado. errores, skipped items, último sync, volumen y comprobaciones del usuario. Un batch puede estar lento sin estar roto. Microsoft explica que la migración tiene menor prioridad que determinadas funciones críticas de Exchange Online como mail flow y conectividad. Por tanto, periodos de ralentización pueden formar parte del comportamiento normal. No diagnosticar únicamente mirando el porcentaje.

Cuando un usuario parece detenido conviene obtener: Get-MigrationUserStatistics, IncludeReport. Referencia oficial: Microsoft – Troubleshoot IMAP mailbox migration.

Contactos: planificarlos fuera de IMAP

Los contactos personales no forman parte de una migración IMAP. Dónde pueden estar.

No todos los contactos tienen que migrarse. Puede haber miles de contactos obsoletos o duplicados. Si la agenda tiene valor empresarial, merece una revisión separada.

Calendarios: probablemente la diferencia más visible para el usuario

Un usuario puede pensar que su calendario forma parte de “la cuenta de correo”, pero IMAP no lo sabe. Qué debemos identificar. calendario personal, eventos futuros, recurrencias, calendarios compartidos, salas y calendarios locales. Opciones. Dependiendo del origen: PST, ICS, exportación del proveedor, herramienta especializada o recreación manual. Eventos futuros primero. Cuando no podemos migrar todo con fidelidad, lo más importante suele ser evitar que el usuario pierda reuniones y citas futuras.

Sent Items: revisar antes del piloto

Los mensajes enviados suelen formar parte del IMAP si la carpeta está almacenada correctamente en servidor. Pero no deberíamos asumirlo. Problemas habituales. El cliente puede guardar los enviados en: una carpeta local, un PST o una carpeta IMAP con nombre distinto. Comprobación rápida. Entrar en webmail y comparar Sent con Outlook permite detectar rápidamente si existe contenido local.

Cuentas genéricas y Shared Mailboxes

Los hostings IMAP suelen utilizar cuentas completas para direcciones como: info@empresa.com ventas@empresa.com administracion@empresa.com y compartir la contraseña entre varias personas. Exchange Online permite otro modelo. Podemos evaluar crear un Shared Mailbox y conceder: Full Access, Send As o Send on Behalf según las necesidades. Ventaja. Cada usuario utiliza su propia identidad en lugar de compartir una contraseña genérica.

50 GB sin licencia propia. Microsoft permite actualmente un Shared Mailbox sin licencia propia hasta 50 GB dentro de las condiciones aplicables. Para superar esa capacidad o utilizar Archive, Litigation Hold o determinadas funciones avanzadas se requiere el licenciamiento correspondiente. Referencia oficial: Microsoft – About shared mailboxes.

Google Workspace: no lo reduzcas a una migración IMAP

Google Workspace expone Gmail mediante IMAP, pero eso no significa que IMAP sea actualmente la mejor ruta para una empresa que migra desde Google. Microsoft dispone de una migración específica. La ruta actual de Google Workspace puede migrar: correo, calendario y contactos y Microsoft ha seguido ampliando sus herramientas específicas para este origen.

¿Cuándo podría seguir apareciendo IMAP?

En escenarios muy concretos o como alternativa técnica, pero debería compararse con la ruta Google Workspace antes de decidir. Referencia oficial: Microsoft – Automated Google Workspace migration.

Dominio y DNS: preparar el cutover

Una migración de correo tiene dos flujos distintos: migración del histórico y redirección del correo nuevo. Los batches IMAP resuelven el primero. El DNS determina el segundo. Registros principales.

MX: cuándo debe cambiarse

El registro MX debería modificarse cuando Exchange Online esté preparado para convertirse en el sistema productivo. Antes del cambio. Deberíamos confirmar: usuarios, licencias, aliases, Exchange Online, batches, mail flow y aplicaciones críticas. El MX no copia datos. Cambiar el MX no traslada ningún mensaje histórico. Únicamente indica a los servidores remitentes dónde deben entregar el nuevo correo. No cancelar inmediatamente el hosting.

Durante un periodo controlado puede ser conveniente mantener acceso al sistema anterior para: sincronizaciones incrementales, validaciones y excepciones. Referencia oficial: Microsoft – Connect a domain with DNS records.

SPF durante una migración IMAP

SPF debe reflejar todos los sistemas que continúan enviando correo legítimamente con nuestro dominio. Un único registro SPF. No debemos publicar un SPF para Microsoft y otro independiente para el hosting. Debe existir un único registro con las fuentes necesarias correctamente combinadas. Durante la coexistencia. Podría ser necesario autorizar temporalmente: Microsoft 365, proveedor IMAP antiguo, CRM, ERP, web y plataforma de marketing.

Después. Una vez retirado el antiguo servicio, conviene eliminar de SPF las fuentes que ya no deben enviar correo. Referencia oficial: Microsoft – Configure SPF.

DKIM para Microsoft 365

Microsoft recomienda utilizar DKIM junto con SPF y DMARC para proteger la autenticación de los dominios personalizados. Dos CNAME por dominio. Microsoft utiliza dos selectores DKIM. Los valores concretos deben obtenerse del tenant. Importante desde 2025. Microsoft introdujo un nuevo formato de CNAME DKIM para nuevos dominios personalizados. Por ese motivo resulta todavía más importante no copiar ejemplos estáticos de Internet.

Obtener los valores correctos

Podemos utilizar el portal de Microsoft Defender o Exchange Online PowerShell.

Get-DkimSigningConfig `
    -Identity "empresa.com" |
    Format-List Name,Enabled,Status,Selector1CNAME,Selector2CNAME

Referencia oficial: Microsoft – Configure DKIM.

DMARC: controlar la transición sin bloquear correo legítimo

DMARC utiliza la autenticación SPF/DKIM y la alineación con el dominio visible del remitente.

La migración es un mal momento para descubrir remitentes olvidados. Antes de endurecer DMARC tenemos que identificar: ERP, CRM, newsletters, web, tickets, aplicaciones SaaS y cualquier otro sender. Secuencia razonable. inventariar → autenticar → observar → corregir → endurecer. Referencia oficial: Microsoft – Configure DMARC.

Autodiscover y Outlook

Después del cutover, el usuario deja de conectarse al servidor IMAP anterior y comienza a trabajar con Exchange Online. El perfil antiguo puede contener. servidor IMAP, servidor SMTP, puertos, autenticación, PST y configuración histórica. Nuevo perfil. En algunos casos puede resultar preferible crear un perfil Outlook limpio. La decisión depende de: versión de Outlook, estado del perfil, PST existentes y procedimiento de despliegue.

Migración cloud y configuración de endpoints son alcances diferentes. La transferencia de buzones puede realizarse de forma centralizada, mientras que la configuración individual de los dispositivos debe definirse expresamente cuando sea necesaria.

Aplicaciones, webs e impresoras que envían correo

Una empresa casi nunca tiene únicamente usuarios enviando email.

Estas dependencias no se migran con IMAP. Debemos decidir cómo enviarán después del cambio. No reutilizar configuración antigua sin analizar. El servidor SMTP, puerto, autenticación y seguridad de Microsoft 365 pueden ser diferentes. Además, Microsoft está evolucionando continuamente sus métodos de autenticación y conviene utilizar la opción adecuada para cada tipo de aplicación.

Microsoft nativo o herramienta especializada

La herramienta nativa es perfectamente válida para muchos proyectos, pero no necesariamente para todos.

Qué comparar. coste, autenticación, límites, deltas, filtros, reporting, mapping, throttling, soporte y fidelidad. BitTitan. MigrationWiz mantiene actualmente una guía específica para IMAP → Microsoft 365. El fabricante explica también que su plataforma es una herramienta de migración y no una sincronización en vivo, por lo que debemos entender exactamente cómo funcionan las pasadas del proyecto. CodeTwo. CodeTwo Office 365 Migration mantiene actualmente soporte para servidores IMAP como origen y permite configurar conexiones, throttling y trabajos de migración.

La herramienta no arregla las limitaciones conceptuales de IMAP. Si el origen solo expone correo mediante IMAP, una plataforma de terceros no puede inventar automáticamente calendarios que nunca están disponibles mediante esa interfaz. Por eso el análisis del origen sigue siendo más importante que la marca del producto. Referencias:

• BitTitan – IMAP to Microsoft 365 Migration Guide
• CodeTwo – Migration from an IMAP source

Fases recomendadas de una migración IMAP a Microsoft 365

Cómo debe ser el piloto

Un buen piloto debe buscar problemas antes de que los encuentre toda la empresa.

El piloto debe dejarnos números. Al terminar deberíamos conocer: GB/hora aproximados, mensajes/hora, concurrencia tolerada, errores típicos y tareas manuales.

Cutover: pasar la producción a Exchange Online

Una vez que la mayor parte del contenido está sincronizado llega el momento de cambiar el flujo de correo.

TTL. Reducir previamente el TTL de determinados registros puede ayudar a acortar la transición DNS, aunque nunca convierte la propagación en instantánea.

La migración no termina cuando el batch está “Synced”

1. Validación cuantitativa. Revisar: usuarios, volumen, carpetas, items y errores. 2. Validación funcional.

3. Histórico. Comprobar muestras de: mensajes recientes, antiguos, Inbox, Sent, carpetas personales y adjuntos. 4. Elementos omitidos. Revisar los skipped items y determinar si: son aceptables, pueden recuperarse por otro método o deben documentarse como excepción. 5. DNS. Comprobar: MX, SPF, DKIM y DMARC. 6. Aplicaciones. Validar los sistemas que utilizan correo.

Qué cambia para los usuarios

Para una persona acostumbrada a un buzón IMAP el cambio visible puede ser considerable.

Comunicación mínima necesaria

El usuario debería saber: cuándo se produce el cambio, cómo iniciar sesión, qué ocurre con Outlook, si debe realizar alguna acción y dónde solicitar ayuda.

Cuánto tarda una migración IMAP

No existe una duración estándar por buzón.

Ejemplo. Dos empresas pueden tener 50 usuarios. La primera tiene 50 buzones de 3 GB en un servidor rápido. La segunda tiene 50 buzones de 25 GB, cientos de miles de mensajes y un hosting que permite pocas conexiones. No son proyectos equivalentes. La mejor estimación sale del piloto. Después de probar varios buzones representativos podemos calcular mejor: tamaño de oleadas, concurrencia, fechas y margen para remediación.

Errores frecuentes en una migración IMAP a Microsoft 365

Checklist antes de migrar IMAP a Microsoft 365

Preguntas frecuentes sobre migración IMAP a Microsoft 365

¿IMAP traslada los contactos y calendarios a Microsoft 365?

El método IMAP se centra en el correo del servidor. Los contactos y calendarios deben inventariarse y trasladarse con un procedimiento compatible con su ubicación y formato. Conviene confirmar este alcance antes de empezar, porque una prueba que solo revisa mensajes puede ocultar información que el usuario conserva en otra aplicación o en su equipo.

¿Qué ocurre con el correo guardado únicamente en un ordenador?

No puede darse por incluido en una copia desde el servidor IMAP. Primero hay que localizar dónde se conserva, comprobar su formato y acordar un procedimiento de traslado. El usuario debe participar en la revisión de carpetas históricas para distinguir lo que ya está en el servidor de lo que solo existe en una copia local.

¿Se puede comenzar la copia antes de cambiar el dominio?

La preparación puede separar la transferencia inicial del cambio de recepción, según la herramienta y el diseño utilizados. Debe definirse qué entorno sigue siendo el de trabajo y cómo se recogerán los mensajes posteriores. El cambio se realiza cuando el destino y las pruebas están preparados, no solo porque haya terminado una primera copia.

¿Cómo se revisan los mensajes que no se han copiado?

Se parte de los informes y del identificador de los errores para localizar causa, carpeta y usuario. Puede haber contenido fuera del alcance, restricciones de origen o elementos que requieran otro tratamiento. Las diferencias se documentan y se validan con el responsable; repetir toda la migración sin diagnóstico puede añadir duplicados sin resolver el problema.

Recomendaciones finales: IMAP funciona muy bien cuando sabemos exactamente qué estamos migrando

Una migración IMAP a Microsoft 365 puede ser una ruta sencilla y eficaz para trasladar correo desde proveedores de hosting y servidores compatibles hacia Exchange Online. Pero su simplicidad depende de entender correctamente el alcance. IMAP permite copiar mensajes y carpetas. No debemos presentar el proceso como una migración completa de todas las capacidades que el usuario asocia a su cuenta de correo.

Contactos, calendarios, tareas, reglas, firmas, delegaciones y configuraciones locales necesitan una estrategia independiente. Antes de empezar también debemos conocer el servidor origen. Las credenciales, límites de conexión, nombres de carpetas y throttling pueden tener más impacto en el calendario que el ancho de banda contratado por la empresa. La herramienta nativa de Microsoft permite organizar el trabajo mediante endpoints y batches, hacer cargas iniciales antes del corte y mantener sincronizaciones incrementales aproximadamente cada 24 horas mientras el lote continúa activo.

Eso permite reducir considerablemente la cantidad de información pendiente durante la ventana final. También debemos conocer sus límites actuales: Microsoft documenta un máximo de 500.000 elementos por buzón y un tamaño máximo de 35 MB por mensaje para la migración IMAP. Estos valores, junto con el número de carpetas y el comportamiento del servidor origen, deberían revisarse durante el assessment.

Hay además escenarios donde IMAP no debería ser nuestra primera elección. Google Workspace dispone actualmente de una ruta específica de Microsoft que puede migrar correo, calendario y contactos. Exchange Server cuenta con mecanismos propios que ofrecen mayor fidelidad. Y una migración entre tenants Microsoft 365 debe tratarse como un proyecto cross-tenant. Una vez elegido IMAP, el procedimiento debería seguir una secuencia clara: discovery → preparación del tenant → endpoint → piloto → premigración → corrección de errores → cutover → incremental sync → validación → retirada del origen.

El cambio de MX debe producirse únicamente cuando Exchange Online está preparado. SPF debe reflejar todas las fuentes legítimas, DKIM debe configurarse utilizando los valores reales del tenant y DMARC debería evolucionar de forma controlada después de verificar la autenticación. Finalmente, no deberíamos dar el proyecto por terminado simplemente porque el panel muestre Synced. La migración termina cuando los usuarios reciben y envían correctamente desde Exchange Online, el histórico incluido está disponible, las excepciones están documentadas, las aplicaciones siguen enviando correo y podemos retirar el proveedor anterior sin depender de él.

Documentación oficial recomendada

Migración IMAP.

• Microsoft – What you need to know about migrating IMAP mailboxes
• Microsoft – Migrate other types of IMAP mailboxes
• Microsoft – CSV files for IMAP migration batches
• Microsoft – Optimize IMAP migrations
• Microsoft – Troubleshoot IMAP migration

Migration Batches y PowerShell.

• Microsoft – Manage migration batches in Exchange Online
• Microsoft – IMAP migration with Exchange Online PowerShell
• Microsoft – New-MigrationEndpoint
• Microsoft – New-MigrationBatch
• Microsoft – Get-MigrationUserStatistics

Rendimiento.

• Microsoft – Microsoft 365 migration performance and best practices

Exchange Online.

• Microsoft – Ways to migrate email to Microsoft 365
• Microsoft – Exchange Online Limits
• Microsoft – Shared Mailboxes

Google Workspace.

• Microsoft – Automated Google Workspace Migration
• Microsoft – Migrate Google Workspace email, contacts and calendar

DNS y autenticación de correo.

• Microsoft – Connect your domain by adding DNS records
• Microsoft – Configure SPF
• Microsoft – Configure DKIM
• Microsoft – Configure DMARC