Migración IMAP a Microsoft 365: guía completa para mover correo a Exchange Online

Una migración IMAP a Microsoft 365 es una de las formas más habituales de trasladar correo empresarial desde proveedores de hosting, servidores Linux y otras plataformas de email hacia Exchange Online.

Es un escenario frecuente en empresas que actualmente trabajan con buzones alojados en cPanel, Plesk, Zimbra, Dovecot, Courier, Kerio, hosting compartido u otros servicios compatibles con IMAP y quieren centralizar el correo dentro de Microsoft 365.

Sin embargo, una migración IMAP tiene una característica que debe entenderse desde el principio: IMAP no representa un buzón empresarial completo.

La migración nativa de Microsoft permite trasladar principalmente los mensajes y carpetas que existen en el servidor IMAP. No traslada automáticamente calendarios, contactos, tareas, reglas de Outlook, firmas, permisos delegados ni otra configuración asociada al cliente de correo.

Por eso el proyecto no debería comenzar creando un lote de migración. Primero conviene averiguar qué información existe realmente, dónde se encuentra, cuánto ocupa y qué necesita conservar la empresa.

También hay que analizar el proveedor. Dos servidores que ofrecen IMAP pueden comportarse de forma muy distinta: uno puede permitir muchas conexiones concurrentes y otro bloquear rápidamente la migración; uno puede conservar correctamente Sent Items y otro utilizar nombres de carpeta diferentes; uno puede permitir credenciales administrativas y otro obligar a disponer de la contraseña de cada usuario.

En Kloudeal planteamos estas migraciones comenzando por un assessment del entorno: usuarios, buzones, servidor IMAP, credenciales, carpetas, volumen, PST locales, dominio, DNS y sistemas que envían correo. Después preparamos Exchange Online, realizamos un piloto, ejecutamos las cargas iniciales, coordinamos el cambio de correo y validamos el resultado.

En esta guía explicamos cómo abordar una migración IMAP a Microsoft 365 en 2026, cuáles son los límites actuales de Microsoft, cómo funcionan los migration batches, qué sucede con contactos y calendarios, cómo coordinar MX, SPF, DKIM y DMARC y cuándo una herramienta especializada puede resultar más adecuada que el procedimiento nativo.

Índice

1. Qué es IMAP
2. IMAP, POP3 y Exchange Online
3. Cuándo tiene sentido una migración IMAP
4. Cuándo IMAP no es la mejor opción
5. Qué se migra realmente
6. Qué no se migra mediante IMAP
7. Assessment antes de migrar
8. Analizar el servidor IMAP origen
9. Credenciales y acceso a los buzones
10. Carpetas especiales y estructura IMAP
11. PST y archivos locales
12. Límites de la migración IMAP de Microsoft
13. Rendimiento y throttling
14. Requisitos en Microsoft 365
15. Licencias
16. Migración desde Exchange Admin Center
17. Archivo CSV
18. Migration Endpoint
19. Migration Batch
20. Sincronizaciones incrementales
21. Excluir o incluir carpetas
22. Exchange Online PowerShell
23. Monitorización y troubleshooting
24. Contactos
25. Calendarios
26. Elementos enviados
27. Cuentas genéricas y Shared Mailboxes
28. Google Workspace: mejor utilizar su ruta específica
29. Dominio y DNS
30. MX
31. SPF
32. DKIM
33. DMARC
34. Autodiscover
35. Aplicaciones que envían correo
36. Microsoft nativo o herramienta especializada
37. Fases del proyecto
38. Piloto
39. Cutover
40. Validación
41. Qué cambia para los usuarios
42. Cuánto tarda
43. Errores frecuentes
44. Checklist
45. Preguntas frecuentes
46. Documentación oficial

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

Conclusión: 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