Migrar correo a Office 365: guía completa para pasar a Exchange Online
Migrar el correo a Office 365 sigue siendo una de las búsquedas más habituales de las empresas que quieren llevar su correo corporativo a Microsoft. Actualmente, el servicio de correo forma parte del ecosistema Microsoft 365 y se presta principalmente mediante Exchange Online.
El cambio puede parecer sencillo: crear los usuarios, copiar los mensajes y modificar el registro MX. En una migración empresarial real normalmente intervienen muchos más componentes: calendarios, contactos, buzones compartidos, permisos, dominios, aliases, archivos de correo, reglas, aplicaciones que envían mensajes, autenticación, DNS y los clientes que utilizarán los usuarios después del cambio.
Además, el procedimiento cambia completamente según el origen. Migrar desde Exchange Server permite conservar elementos que no existen en una migración IMAP. Google Workspace tiene sus propias APIs y herramientas. En POP3 puede ocurrir que gran parte del histórico esté almacenado únicamente en ordenadores locales. HCL Domino puede contener aplicaciones además de correo. Y una migración entre dos tenants Microsoft 365 introduce dependencias de identidad, dominios y coexistencia.
En Kloudeal ayudamos a empresas a diseñar y ejecutar migraciones de correo hacia Exchange Online partiendo del entorno real: analizamos buzones y dependencias, seleccionamos el método, configuramos la plataforma de migración, ejecutamos pruebas, coordinamos el cutover y validamos que el nuevo servicio funciona correctamente.
Esta guía explica cómo abordar una migración de correo a Microsoft 365 en 2026, qué puede migrarse desde cada plataforma, qué limitaciones existen y qué conviene preparar antes de cambiar el flujo de correo.
Qué cambia según el origen del correo
| Origen | Qué puede migrarse habitualmente | Principal consideración |
|---|---|---|
| Exchange Server | Correo, calendario, contactos, tareas y gran parte de la información de Exchange. | Versión, soporte, coexistencia, permisos, Active Directory y método de migración. |
| Google Workspace | Gmail, calendarios, contactos, reglas y otros componentes mediante procedimientos específicos. | Permisos Google, mapping, routing y validación de elementos especiales. |
| IMAP | Mensajes y carpetas de correo. | No incluye contactos, calendario ni tareas. |
| POP3 | Depende de dónde se encuentre realmente el histórico. | El correo puede estar almacenado únicamente en Outlook, PST u otros clientes. |
| HCL Domino / Notes | Correo, calendarios y contactos mediante soluciones compatibles. | Separar correo de aplicaciones y bases Domino. |
| Microsoft 365 | Buzones Exchange Online entre tenants. | Identity mapping, dominios, licencias, coexistencia y permisos. |
No existe un único procedimiento correcto para “migrar correo a Office 365”. El origen determina qué método tiene sentido y qué fidelidad podemos esperar.
¿Estás preparando una migración de correo?
Con el sistema de correo actual, número de buzones, tamaños, dominios y fecha objetivo podemos hacer una primera revisión del proyecto y determinar qué método y herramienta deberían evaluarse.
Solicitar valoración de migración de correoÍndice
- Office 365, Microsoft 365 y Exchange Online
- Qué incluye realmente una migración de correo
- Qué analizamos antes de empezar
- Exchange Server a Exchange Online
- Exchange 2016 y 2019 en 2026
- Cutover migration
- Hybrid y Minimal Hybrid
- Google Workspace a Exchange Online
- Delegaciones, salas, recursos y tareas de Google
- IMAP a Microsoft 365
- POP3 a Microsoft 365
- Zimbra, cPanel y otros servidores
- HCL Domino / Lotus Notes a Microsoft 365
- Exchange Online Tenant-to-Tenant
- Buzones compartidos, salas y recursos
- Permisos y delegaciones
- Online Archive e históricos
- Dominios y direcciones SMTP
- MX, Autodiscover, SPF, DKIM y DMARC
- Aplicaciones, impresoras y SMTP
- MFA y seguridad
- Herramientas de migración
- Piloto y premigración
- Cómo preparamos el cutover
- Cómo validamos la migración
- Outlook, móviles y puestos de usuario
- Cuánto tarda una migración
- Qué determina el coste
- Errores frecuentes
- Checklist antes de migrar
- Preguntas frecuentes
- Documentación oficial
Office 365, Microsoft 365 y Exchange Online: aclarando los nombres
Muchas empresas siguen utilizando el término Office 365 para referirse al entorno cloud de Microsoft, y por eso búsquedas como “migrar correo a Office 365” continúan siendo habituales.
En la terminología actual, Microsoft 365 es la plataforma más amplia y Exchange Online es el servicio cloud responsable del correo empresarial.
Exchange Online proporciona funciones como:
| Servicio | Ejemplo |
|---|---|
| Buzones | Correo de usuarios. |
| Calendarios | Reuniones y disponibilidad. |
| Contactos | Contactos personales y organización. |
| Shared Mailboxes | ventas@empresa.com, soporte@empresa.com. |
| Rooms / Equipment | Salas de reuniones y otros recursos. |
| Mail flow | Reglas, conectores y routing. |
| Online Archive | Archivo adicional cuando el plan lo permite. |
Por tanto, en esta guía utilizamos “migrar a Office 365” por ser un término que todavía utilizan muchos usuarios, pero técnicamente estamos hablando principalmente de migrar buzones a Exchange Online dentro de Microsoft 365.
Qué puede incluir realmente una migración de correo
Cuando una empresa pide “migrar el correo”, conviene concretar qué entiende por buzón.
Para un usuario, su correo puede incluir mensajes, carpetas, calendario, contactos, tareas, delegaciones, archivos históricos y acceso a buzones compartidos. Técnicamente esos elementos pueden necesitar mecanismos diferentes.
| Elemento | ¿Puede formar parte de la migración? | Depende principalmente de |
|---|---|---|
| Mensajes | Sí. | Origen y herramienta. |
| Carpetas | Sí. | Origen. |
| Calendario | Sí en muchos orígenes. | No disponible mediante IMAP estándar. |
| Contactos | Sí en muchos orígenes. | No disponibles mediante IMAP estándar. |
| Tareas | Según origen y método. | Especialmente relevante en Exchange y Google. |
| Rules | Según herramienta y origen. | No forman parte de IMAP. |
| Delegaciones | Según origen y procedimiento. | Necesitan mapping correcto de identidades. |
| Shared Mailboxes | Sí, cuando existen en origen o se diseñan en destino. | Contenido y permisos. |
| Archive | Según plataforma y licenciamiento. | Volumen, herramienta y plan destino. |
| Public Folders | En proyectos específicos. | Origen, estructura y método. |
No prometemos más fidelidad de la que ofrece el origen
Si la única interfaz disponible es IMAP, el servidor no nos proporciona calendario y contactos mediante ese protocolo. Una herramienta no puede obtener de IMAP información que IMAP no expone.
En cambio, Exchange Server y Google Workspace permiten utilizar mecanismos más ricos y conservar más componentes.
Assessment antes de migrar correo
El assessment de correo debería responder preguntas que afectan directamente a la arquitectura y al precio.
| Área | Qué necesitamos conocer |
|---|---|
| Buzones de usuario | Número, tamaño y usuarios activos. |
| Shared Mailboxes | Número, tamaño, propietarios y delegaciones. |
| Archives | Usuarios que los utilizan y volumen. |
| Rooms / Equipment | Recursos que deben mantenerse. |
| Dominios | SMTP primario, aliases y dominios secundarios. |
| Calendarios y contactos | Si existen y cómo accederemos a ellos. |
| Aplicaciones | Sistemas que envían o leen correo. |
| DNS | MX, Autodiscover, SPF, DKIM y DMARC actuales. |
| Identidad | Cloud-only, Active Directory o tenant Microsoft 365 existente. |
| Fecha objetivo | Ventana disponible y restricciones de negocio. |
A partir de estos datos podemos elegir el método adecuado y determinar si necesitamos una migración por lotes, una coexistencia más larga o un cutover concentrado.
Migrar Exchange Server a Exchange Online
Una migración desde Exchange Server local hacia Exchange Online permite conservar mucha más información que una migración IMAP porque ambas plataformas comparten la arquitectura Exchange.
Aun así, no existe un único procedimiento.
Microsoft mantiene diferentes rutas dependiendo de la versión de Exchange, número de buzones y necesidad de coexistencia.
| Factor | Por qué importa |
|---|---|
| Versión Exchange | Determina soporte y rutas disponibles. |
| Número de buzones | Influye en cutover frente a migración gradual. |
| Coexistencia | Puede hacer recomendable Hybrid. |
| Active Directory | Afecta identidad y administración de destinatarios. |
| Certificados | Importantes para conectividad y servicios híbridos. |
| Autodiscover | Afecta clientes y configuración. |
| Aplicaciones | Pueden depender de SMTP relay o Exchange local. |
Referencia oficial: Microsoft – Ways to migrate multiple email accounts to Microsoft 365 or Office 365.
Exchange Server 2016 y 2019 en 2026: un cambio importante
Este punto merece una actualización específica.
Exchange Server 2016 y Exchange Server 2019 finalizaron su soporte estándar el 14 de octubre de 2025.
Microsoft recomienda a las organizaciones que todavía utilizan estas versiones migrar a Microsoft 365 o evolucionar hacia Exchange Server Subscription Edition (SE).
Por tanto, una empresa que en 2026 mantiene Exchange 2016 o 2019 debería tratar la migración no solo como una mejora funcional, sino también como una decisión relacionada con ciclo de vida y seguridad.
¿Se pueden utilizar todavía para migrar?
Microsoft documenta rutas para mover buzones desde esos entornos hacia Microsoft 365, pero mantener un Exchange fuera de soporte en producción tiene implicaciones evidentes.
La estrategia concreta debe revisarse según:
build actual, actualizaciones disponibles, participación o no en programas ESU, arquitectura híbrida y ruta prevista hacia Microsoft 365 o Exchange SE.
Referencia oficial: Microsoft – Exchange Server 2016 and 2019 End of Support Roadmap.
¿Todavía utilizáis Exchange Server 2016 o 2019?
En 2026 ya están fuera de soporte general. Antes de plantear simplemente “mover buzones”, conviene revisar versión, parches, Active Directory, aplicaciones y qué componentes Exchange deberán permanecer o retirarse después.
Revisar migración de Exchange ServerMigración cutover de Exchange
En una cutover migration se traslada la organización Exchange a Microsoft 365 en una transición relativamente concentrada.
Microsoft documenta actualmente soporte técnico de cutover para hasta 2.000 buzones, aunque su propia documentación indica que por operativa y tiempos suele ser mucho más razonable utilizarla en organizaciones de alrededor de 150 buzones o menos.
Eso no significa que “menos de 150 usuarios = cutover” automáticamente.
También debemos revisar aplicaciones, calendario, Active Directory, recursos, coexistencia y otros requisitos.
Cuándo puede tener sentido
En organizaciones donde:
queremos evitar una coexistencia prolongada, el número de usuarios es asumible y todas las dependencias pueden cambiar en una ventana controlada.
Cuándo puede no ser ideal
Si necesitamos mantener usuarios locales y cloud durante semanas, disponer de free/busy entre ambos lados o mover cientos de usuarios en diferentes oleadas, normalmente conviene estudiar Hybrid.
Referencia oficial: Microsoft – Exchange cutover migration.
Hybrid Migration y Minimal Hybrid
Una configuración híbrida conecta Exchange Server con Exchange Online para permitir una transición más gradual.
Puede facilitar la convivencia entre buzones locales y cloud durante el proyecto.
Full Hybrid
Puede ser apropiado cuando la convivencia entre ambos entornos necesita mantenerse durante un periodo largo.
Minimal Hybrid
Microsoft también ofrece Minimal Hybrid para determinados escenarios donde queremos aprovechar las capacidades de Hybrid Configuration Wizard y migrar con mayor rapidez sin mantener una configuración híbrida completa a largo plazo.
Staged OutlookAnywhere ya no debe utilizarse como recomendación genérica
Microsoft retiró Staged OutlookAnywhere onboarding el 8 de mayo de 2025.
Los artículos antiguos que siguen proponiéndolo como la forma normal de migrar Exchange por lotes deberían revisarse.
Para una nueva migración gradual debemos estudiar las rutas híbridas soportadas y la versión actual del entorno.
Referencia oficial: Microsoft – Staged migration retirement information.
Migrar Google Workspace a Exchange Online
Microsoft dispone actualmente de una migración automatizada desde Google Workspace hacia Exchange Online mediante el Exchange Admin Center.
La solución puede trasladar:
| Google Workspace | Exchange Online |
|---|---|
| Gmail | Correo y carpetas. |
| Google Calendar | Calendario Exchange. |
| Google Contacts | Contactos. |
| Rules | Dentro de las capacidades documentadas del método. |
Esto diferencia enormemente esta migración de un procedimiento IMAP genérico.
Si tratásemos Gmail simplemente como un servidor IMAP perderíamos la oportunidad de utilizar mecanismos específicos para calendarios, contactos y otros componentes.
Preparación del entorno Google
Antes de empezar debemos configurar correctamente:
acceso administrativo, proyecto y permisos Google Cloud cuando correspondan, usuarios destino, dominios, routing y los prerrequisitos de Exchange Online.
Los usuarios pueden migrarse por lotes
Esto permite diseñar proyectos graduales y mantener durante un tiempo coexistencia o routing entre ambas plataformas cuando sea necesario.
Referencia oficial: Microsoft – Automated Google Workspace migration to Microsoft 365.
Delegaciones, salas, recursos y tareas desde Google Workspace
La migración de Google Workspace está evolucionando y actualmente Microsoft documenta también procedimientos para tratar elementos que históricamente podían requerir bastante trabajo manual.
Existe documentación específica para migrar o reconstruir:
| Elemento Google | Tratamiento Microsoft actual |
|---|---|
| Mailbox permissions | Procedimiento específico. |
| Delegates | Mapping hacia Exchange Online. |
| Rooms | Procedimiento documentado. |
| Resources | Procedimiento documentado. |
| Tasks | Procedimiento específico. |
Estas capacidades son específicas de Google Workspace y no deben extrapolarse automáticamente a un proveedor IMAP.
Referencia oficial: Microsoft – Migration of Permissions, Delegates, Rooms, Resources and Tasks from Google Workspace.
Migrar correo IMAP a Office 365
La migración IMAP → Exchange Online es muy habitual en proveedores de hosting y plataformas de correo que exponen sus buzones mediante Internet Message Access Protocol.
Es una solución efectiva para trasladar mensajes, pero es importante explicar sus límites antes de empezar.
| Elemento | ¿Lo migra IMAP? |
|---|---|
| Sí. | |
| Carpetas de correo | Sí. |
| Contactos | No. |
| Calendario | No. |
| Tareas | No. |
| Rules | No mediante IMAP. |
| Delegaciones | No mediante IMAP. |
Límites actuales de la migración IMAP nativa
La documentación vigente de Microsoft establece actualmente, entre otros, los siguientes límites para su procedimiento IMAP:
| Límite | Valor documentado |
|---|---|
| Elementos por buzón | Hasta 500.000 elementos. |
| Tamaño máximo de un mensaje migrado | 35 MB. |
Microsoft procesa los mensajes del más reciente al más antiguo.
Estos límites deben comprobarse de nuevo antes de cada proyecto porque Microsoft puede modificarlos.
Los buzones destino deben existir previamente
Antes de iniciar una migración IMAP debemos crear los usuarios y disponer de sus buzones Exchange Online en destino.
La concurrencia del servidor origen importa
Un hosting puede limitar conexiones por usuario, IP o servidor. Aunque Exchange Online pueda recibir información rápidamente, el origen puede convertirse en el cuello de botella.
Por eso en migraciones grandes conviene realizar pruebas de throughput antes de comprometer el calendario.
Referencia oficial: Microsoft – What you need to know about migrating IMAP mailboxes.
¿Tienes cuentas IMAP y no sabes exactamente qué se puede conservar?
Podemos revisar el proveedor, tamaños y uso de calendario/contactos antes de asumir que todos los datos del usuario están incluidos en la migración.
Valorar migración IMAP a Microsoft 365Migrar correo POP3 a Microsoft 365
POP3 necesita un análisis diferente.
El problema no es tanto el protocolo como saber dónde se encuentran los datos.
Un cliente POP tradicional puede descargar mensajes desde el servidor al ordenador y, dependiendo de su configuración, eliminarlos posteriormente del servidor.
Por tanto, una cuenta con 15 GB en Outlook podría tener únicamente 500 MB todavía disponibles en el hosting.
Antes de presupuestar una migración POP
Necesitamos identificar si:
| Situación | Posible estrategia |
|---|---|
| El proveedor soporta IMAP y conserva todo | Evaluar migración IMAP. |
| El correo está en PST | Valorar importación o tratamiento de PST. |
| El histórico está repartido entre equipos | Necesita discovery y recopilación previa. |
| Servidor y local contienen datos diferentes | Diseñar consolidación evitando duplicados. |
Por este motivo, una migración POP puede implicar más trabajo que una migración IMAP aparentemente equivalente.
Zimbra, cPanel, Dovecot y otros proveedores
Una plataforma como Zimbra puede ofrecer más capacidades que IMAP, mientras que un hosting cPanel puede limitar el acceso prácticamente a IMAP/POP.
No deberíamos definir el alcance únicamente por la marca del proveedor.
Hay que comprobar:
qué protocolos y APIs están disponibles, dónde están calendario y contactos, qué formatos pueden exportarse y qué herramienta de migración dispone de soporte específico.
Ejemplo
Si Zimbra expone únicamente IMAP para el proyecto que podemos utilizar, migraremos el correo como IMAP aunque Zimbra tenga calendario.
Si disponemos de una herramienta con acceso específico capaz de extraer calendario y contactos, el alcance puede ser diferente.
Migración desde HCL Domino / Notes
HCL Domino y HCL Notes son los nombres actuales de la plataforma que muchas organizaciones siguen conociendo como Lotus Domino, Lotus Notes o IBM Notes.
Un proyecto Domino necesita distinguir claramente entre el buzón de correo y las aplicaciones empresariales desarrolladas sobre la plataforma.
| Componente | Destino posible |
|---|---|
| Exchange Online. | |
| Calendar | Exchange Online mediante herramienta compatible. |
| Contacts | Exchange Online mediante procedimiento compatible. |
| Directory / Groups | Diseño de objetos Microsoft correspondiente. |
| Domino Applications | Proyecto independiente de modernización o sustitución. |
| NSF Databases | Depende de su contenido y función. |
Una aplicación Domino no se “migra a Outlook”
Puede requerir una nueva aplicación, Power Platform, SharePoint, Dynamics, Azure u otra solución completamente distinta.
Por eso en un proyecto Domino es recomendable crear dos inventarios:
correo y colaboración por un lado y aplicaciones/bases de datos por otro.
Migrar buzones entre tenants de Microsoft 365
Microsoft dispone actualmente de Cross-Tenant Mailbox Migration para trasladar buzones Exchange Online entre dos organizaciones Microsoft 365.
Es habitual en fusiones, adquisiciones, carve-outs y consolidaciones.
No es una copia de buzón convencional
Microsoft utiliza Exchange Online PowerShell y MRS para realizar el movimiento.
El usuario debe estar correctamente preparado en el tenant destino como MailUser y contener determinados atributos que permitan relacionarlo con el buzón de origen.
| Elemento | Consideración |
|---|---|
| MailUser destino | Debe existir y estar preparado correctamente. |
| ExchangeGUID | Necesario para el mapping. |
| Licencia cross-tenant | Obligatoria según documentación actual de Microsoft. |
| Hold | Los buzones bajo cualquier tipo de hold no pueden migrarse mediante este método. |
| Dominio | Debe planificarse independientemente del buzón. |
| Mail routing | Necesario durante coexistencia. |
Qué contenido mueve Microsoft
Microsoft documenta actualmente el movimiento del contenido visible del usuario, como:
correo, contactos, calendario, tareas y notas.
Qué ocurre en origen
Tras una migración correcta, el buzón de origen deja de estar disponible como buzón y el objeto se convierte en MailUser para facilitar determinados escenarios de coexistencia y routing.
Por este motivo debemos comprender bien la diferencia entre una herramienta que “copia” información y un procedimiento nativo que realiza un verdadero mailbox move.
Referencia oficial: Microsoft – Cross-Tenant Mailbox Migration.
Buzones compartidos, salas y recursos
Los objetos que no corresponden directamente a un usuario suelen generar más incidencias que los buzones estándar.
Shared Mailboxes
Necesitamos conocer:
| Información | Por qué importa |
|---|---|
| Tamaño | Puede afectar a licenciamiento y método. |
| Full Access | Usuarios que pueden abrir el buzón. |
| Send As | Usuarios que pueden enviar como esa dirección. |
| Send on Behalf | Delegación de envío. |
| Archive | Puede necesitar tratamiento específico. |
| Aplicaciones | CRM o ticketing pueden utilizar esa dirección. |
Rooms y Resources
Las salas de reuniones y recursos pueden tener reglas de reserva, delegados, horarios y restricciones que deberían documentarse.
Migrar el calendario sin reconstruir la configuración funcional puede dejar el objeto técnicamente presente pero inutilizable para la organización.
Permisos y delegaciones
Una migración de correo debería revisar las relaciones entre los usuarios.
Por ejemplo:
Laura tiene acceso completo al buzón Administración y Pedro puede enviar como facturacion@empresa.com.
El contenido de ambos buzones puede llegar perfectamente a Microsoft 365 y aun así la migración considerarse fallida desde el punto de vista del negocio si esas relaciones desaparecen.
| Permiso | Uso |
|---|---|
| Full Access | Abrir un buzón adicional. |
| Send As | Enviar utilizando la identidad del buzón. |
| Send on Behalf | Enviar en nombre de otra persona o buzón. |
| Calendar permissions | Acceder a calendarios con diferentes niveles. |
El grado en que una herramienta conserva o reconstruye estas relaciones depende del origen y del producto utilizado.
Online Archive, PST e históricos
El volumen histórico suele modificar notablemente un proyecto.
Online Archive en Exchange
Si un usuario dispone de Archive debemos comprobar:
volumen, licenciamiento destino, método utilizado y cómo trata la herramienta el archive mailbox.
Archivos PST
Los PST pueden aparecer en migraciones desde Exchange antiguo, POP3 o historiales locales de Outlook.
No deberían importarse automáticamente sin revisar:
| Aspecto | Motivo |
|---|---|
| Duplicados | Parte del contenido puede existir ya en servidor. |
| Propietario | Debe conocerse a qué buzón pertenece. |
| Fecha | Puede existir contenido muy antiguo sin utilidad operativa. |
| Tamaño | Afecta a tiempos y almacenamiento. |
Dominios y direcciones SMTP
La migración de buzones y el cambio del dominio son tareas relacionadas, pero no son la misma operación.
Hay que inventariar:
dominios SMTP, direcciones principales, aliases, listas, shared mailboxes y cualquier aplicación que utilice el dominio.
Ejemplo
Un usuario puede iniciar sesión actualmente como:
jperez@dominiointerno.local
y enviar correo como:
juan.perez@empresa.com
La migración debe decidir qué identidad tendrá en Microsoft 365 y qué direcciones debe conservar.
Tenant-to-Tenant
El dominio personalizado requiere una planificación especial porque no puede permanecer asignado simultáneamente de la misma manera en los dos tenants.
Antes de liberarlo del origen hay que retirar las dependencias que lo utilicen.
MX, Autodiscover, SPF, DKIM y DMARC
Una migración de correo no puede tratar DNS como una tarea secundaria.
| Registro | Función | Cuándo se revisa |
|---|---|---|
| MX | Indica dónde debe entregarse el correo. | Especialmente durante el cutover. |
| Autodiscover | Ayuda a clientes Exchange a localizar servicios. | Durante preparación y cambio. |
| SPF | Declara fuentes autorizadas para enviar. | Antes y después del cambio. |
| DKIM | Firma criptográficamente mensajes salientes. | Después de preparar el dominio y DNS correspondiente. |
| DMARC | Define política y reporting para autenticación del dominio. | Debe coordinarse con SPF y DKIM. |
SPF solo no es suficiente
Microsoft recomienda actualmente combinar SPF, DKIM y DMARC dentro de la estrategia de autenticación del correo.
No olvides otros remitentes
Antes de modificar SPF necesitamos identificar sistemas como:
ERP, CRM, páginas web, aplicaciones de nóminas, impresoras, scanners, monitorización, ticketing y servicios de marketing.
Algunos seguirán enviando directamente y otros deberán cambiar de método.
Referencias oficiales:
Aplicaciones, dispositivos y SMTP después de la migración
Uno de los mayores riesgos de una migración de correo es concentrarse en los usuarios y olvidarse de los sistemas que envían mensajes automáticamente.
Ejemplos habituales
| Sistema | Ejemplo de uso |
|---|---|
| ERP | Facturas y pedidos. |
| CRM | Notificaciones comerciales. |
| RRHH | Nóminas o avisos. |
| Web | Formularios de contacto. |
| Impresoras | Scan-to-email. |
| Monitorización | Alertas técnicas. |
| Aplicaciones internas | Mensajes transaccionales. |
No debemos trasladar automáticamente configuraciones SMTP antiguas
Exchange Online ha eliminado Basic Authentication para múltiples protocolos y Microsoft está evolucionando también el uso de SMTP AUTH hacia mecanismos modernos.
Para nuevas configuraciones debemos evaluar opciones como:
| Método | Puede encajar en |
|---|---|
| OAuth / Modern Authentication | Aplicaciones compatibles que necesitan SMTP AUTH. |
| Microsoft Graph | Aplicaciones modernas que pueden enviar mediante API. |
| SMTP Relay | Determinados escenarios de aplicaciones y dispositivos. |
| High Volume Email | Grandes volúmenes de correo interno automatizado. |
| Servicios externos | Mailing masivo o casos no adecuados para Exchange Online. |
No existe una única respuesta correcta. Depende de si el mensaje es interno, externo, volumen, autenticación disponible y arquitectura de la aplicación.
Referencias oficiales:
MFA y seguridad del nuevo entorno
El objetivo de una migración no debería ser reproducir en Exchange Online exactamente la autenticación del servidor antiguo.
Microsoft 365 está diseñado para utilizar identidad moderna y MFA.
Cuentas administrativas
Deben utilizar autenticación multifactor y tener únicamente los privilegios necesarios.
Usuarios
Dependiendo del licenciamiento podemos utilizar Security Defaults o diseñar políticas de Conditional Access.
Autenticación heredada
No deberíamos diseñar nuevas dependencias alrededor de usuario y contraseña cuando existe una alternativa moderna.
Herramientas de migración
Durante el proyecto puede ser necesario conceder permisos a aplicaciones o cuentas administrativas. Estos accesos deben revisarse al terminar y retirarse cuando ya no sean necesarios.
Herramientas para migrar correo a Microsoft 365
La herramienta adecuada depende principalmente del origen.
| Herramienta / método | Escenario principal |
|---|---|
| Exchange Admin Center | Google Workspace, IMAP y otros batches nativos soportados. |
| Exchange Hybrid | Exchange Server con coexistencia. |
| Cross-Tenant Mailbox Migration | Exchange Online → Exchange Online. |
| Quest On Demand Migration | Tenant-to-Tenant y proyectos Microsoft 365 amplios. |
| BitTitan MigrationWiz | Google, IMAP, Exchange y otros proyectos de correo. |
| CodeTwo Office 365 Migration | Migración de Exchange y buzones con interfaz guiada. |
| Cloudiway | Cross-platform y Tenant-to-Tenant. |
| AvePoint | Proyectos empresariales multiworkload. |
| PowerShell | Inventario, preparación y automatización. |
No seleccionamos herramienta únicamente por el número de buzones.
Por ejemplo, 50 buzones Exchange con Archives y delegaciones pueden justificar una tecnología distinta de 50 cuentas IMAP sencillas.
¿No sabes qué herramienta necesitas?
Podemos comparar primero el origen, datos que deben conservarse, número de buzones y calendario antes de adquirir licencias de migración.
Comparar opciones para mi migración de correoPiloto, pre-stage y sincronizaciones
Cuando el proyecto tiene cierta complejidad, el piloto es una de las mejores formas de reducir incertidumbre.
Un buen piloto debería incluir más de un usuario sencillo
| Caso | Qué comprobamos |
|---|---|
| Buzón estándar | Flujo habitual. |
| Buzón grande | Throughput y tiempos. |
| Usuario con Archive | Contenido histórico. |
| Shared Mailbox | Contenido y permisos. |
| Usuario con delegaciones | Relaciones entre buzones. |
| Calendario complejo | Resultado desde Google o Domino. |
| Usuario con aplicación relacionada | Dependencias de autenticación o SMTP. |
Pre-stage
Muchas herramientas permiten migrar la mayor parte del correo días antes mientras los usuarios continúan trabajando en el origen.
Posteriormente se realizan sincronizaciones adicionales para trasladar los cambios.
No todos los métodos funcionan igual
Una migración nativa cross-tenant puede comportarse como un mailbox move, mientras que una plataforma de terceros puede utilizar copy + delta.
Esto modifica mucho el procedimiento de cutover.
Cómo preparamos la ventana de cutover
El cutover debería documentarse como un runbook.
| Fase | Actuación |
|---|---|
| Pre-check | Comprobar usuarios, licencias, herramientas y jobs. |
| Delta | Ejecutar sincronización final cuando corresponda. |
| Mail flow | Modificar MX o routing. |
| DNS | Aplicar cambios planificados. |
| Aplicaciones | Actualizar sistemas que envían correo. |
| Validación | Probar correo interno y externo. |
| Usuarios piloto | Confirmar acceso y funcionamiento. |
Bajar TTL antes del cambio
Cuando administramos DNS y el proveedor lo permite, puede ser útil revisar previamente los TTL para facilitar determinados cambios, aunque esta decisión depende del entorno y del proveedor DNS.
Cómo validamos una migración de correo
Una migración no termina cuando el registro MX apunta a Microsoft 365.
| Prueba | Resultado esperado |
|---|---|
| Login | Usuario puede autenticarse correctamente. |
| Outlook on the web | Buzón accesible. |
| Correo interno | Entrega correcta. |
| Correo externo entrante | Entrega en Exchange Online. |
| Correo externo saliente | Entrega correcta y autenticada. |
| Calendario | Información prevista disponible. |
| Contacts | Disponibles cuando formaban parte del alcance. |
| Shared Mailboxes | Usuarios correctos tienen acceso. |
| Send As | Delegaciones validadas. |
| Rooms | Reservas funcionan correctamente. |
| Apps | Sistemas incluidos pueden enviar mensajes. |
| SPF/DKIM/DMARC | Configuración coherente con la nueva arquitectura. |
Comparación de contenido
Cuando la herramienta proporciona estadísticas, también revisamos contadores, errores y elementos omitidos.
Un pequeño número de elementos incompatibles no implica necesariamente que toda la migración sea incorrecta, pero debe documentarse y evaluarse.
Outlook, móviles y ordenadores después de la migración
Una migración del servicio Exchange y la configuración individual de cada dispositivo son trabajos distintos.
Dependiendo del origen y del método, el usuario puede necesitar:
volver a iniciar sesión, añadir la nueva cuenta, recrear un perfil, volver a registrar MFA o actualizar determinados clientes.
No todas las migraciones requieren la misma intervención
En determinados movimientos Exchange bien diseñados, Outlook puede adaptarse con poca intervención.
En una migración desde un proveedor IMAP completamente diferente puede ser necesario crear una configuración Exchange nueva.
Alcance de Kloudeal
Podemos preparar las instrucciones y coordinarnos con el departamento de TI del cliente para las actuaciones necesarias.
La intervención individual en cada ordenador o dispositivo no debe darse por incluida en un proyecto de migración salvo que aparezca expresamente en el alcance contratado.
Cuánto tarda una migración de correo
No es posible calcular el calendario únicamente a partir del número de usuarios.
| Factor | Impacto |
|---|---|
| Número de buzones | Aumenta volumen operativo. |
| GB por buzón | Incrementa tiempo de transferencia. |
| Número de elementos | Puede afectar mucho al throughput. |
| Origen | Exchange, Google e IMAP se comportan de manera distinta. |
| Límites del origen | Conexiones y throttling pueden ralentizar. |
| Archives | Añaden volumen. |
| Coexistencia | Puede ampliar duración total del proyecto. |
| Herramienta | Cambia concurrencia y modelo de delta. |
Por eso estimamos el calendario después del assessment y lo afinamos con las velocidades observadas durante el piloto.
Qué determina el precio de una migración de correo
Dos organizaciones con el mismo número de usuarios pueden necesitar presupuestos muy diferentes.
| Factor | Ejemplo |
|---|---|
| Tipo de origen | IMAP, Google, Exchange, Domino… |
| Buzones | Usuarios y shared mailboxes. |
| Archives | Necesidad de migrar archivo histórico. |
| Calendario / contactos | Especialmente fuera de Exchange. |
| Herramienta | Coste de licencias. |
| Coexistencia | Configuración adicional. |
| Dominios | Complejidad del cutover. |
| Aplicaciones | SMTP, SSO o integraciones. |
| Soporte | Hypercare y actuaciones posteriores. |
Por ejemplo, migrar diez buzones IMAP sencillos no requiere el mismo esfuerzo que migrar diez buzones POP con quince años de correo distribuido en ordenadores locales.
¿Quieres que valoremos vuestra migración?
Indícanos el proveedor actual, número aproximado de buzones, tamaños, buzones compartidos, dominios y fecha objetivo. Si conocéis además el uso de calendarios, contactos o Archives podremos ajustar mejor el alcance.
Solicitar presupuesto de migración de correoErrores frecuentes al migrar correo a Office 365
| Error | Consecuencia | Mejor enfoque |
|---|---|---|
| Tratar todos los orígenes como IMAP | Se pierde fidelidad que Google o Exchange podrían conservar. | Utilizar métodos específicos cuando existen. |
| Esperar calendario de IMAP | Datos no migrados. | Definir tratamiento separado. |
| Presupuestar POP como IMAP | El histórico puede estar fuera del servidor. | Localizar primero los datos. |
| Ignorar que Exchange 2016/2019 está fuera de soporte | Se plantea el proyecto con una plataforma obsoleta como base permanente. | Revisar lifecycle y ruta actual. |
| Usar staged migration antigua | Se sigue documentación retirada. | Evaluar Hybrid o métodos actuales. |
| No revisar shared mailboxes | Usuarios pierden acceso o capacidad de envío. | Inventariar permisos. |
| No revisar Archives | Parte del histórico queda fuera. | Incluirlo en el assessment. |
| Cambiar MX demasiado pronto | El correo llega a buzones no preparados. | Validar destino antes. |
| Modificar SPF sin inventario | Aplicaciones legítimas dejan de enviar correctamente. | Identificar todos los remitentes. |
| Reutilizar autenticación SMTP antigua | Aplicaciones incompatibles con Exchange Online actual. | Evaluar OAuth, Graph, relay u otras opciones. |
| No hacer piloto | Los problemas aparecen en producción. | Probar casos complejos. |
| Prometer impacto cero | Expectativas irreales. | Explicar la transición. |
| Dar por incluida la configuración de 300 PCs | Alcance no controlado. | Separar migración cloud y endpoint. |
| Cerrar cuando el job termina | Incidencias no detectadas. | Validación funcional. |
Checklist antes de migrar correo a Microsoft 365
| Comprobación | Estado recomendado antes del cutover |
|---|---|
| Plataforma origen identificada | Confirmado. |
| Versión Exchange si aplica | Documentada. |
| Usuarios | Inventariados. |
| Tamaño de buzones | Conocido. |
| Shared Mailboxes | Inventariados. |
| Archives | Identificados. |
| Rooms y Resources | Identificados. |
| Contactos | Tratamiento definido. |
| Calendarios | Tratamiento definido. |
| Permisos | Inventariados. |
| Aliases SMTP | Documentados. |
| Dominios | Preparados. |
| MX | Cambio preparado. |
| Autodiscover | Revisado. |
| SPF | Todos los remitentes conocidos. |
| DKIM | Configuración preparada. |
| DMARC | Estrategia revisada. |
| Aplicaciones SMTP | Inventariadas. |
| Licencias Microsoft | Preparadas. |
| Herramienta de migración | Seleccionada. |
| Piloto | Completado. |
| Runbook | Documentado. |
| Comunicación | Usuarios informados. |
| Responsable de endpoints | Definido. |
| Validación | Criterios acordados. |
| Hypercare | Planificado. |
Preguntas frecuentes sobre migrar correo a Office 365
Significa trasladar los buzones de una plataforma origen a Exchange Online, el servicio de correo empresarial de Microsoft 365.
Según el origen también pueden incluirse calendarios, contactos, Archives, shared mailboxes, permisos y otros componentes.
No exactamente.
Office 365 sigue utilizándose como denominación histórica y comercial en diferentes contextos, mientras que Microsoft 365 engloba actualmente una plataforma más amplia.
El servicio de correo que utilizaremos es Exchange Online.
Es el servicio cloud de correo y calendario empresarial de Microsoft.
Gestiona buzones, calendarios, contactos, shared mailboxes, salas, recursos, mail flow y otras funcionalidades de Exchange.
Sí.
Existen diferentes métodos dependiendo de la versión de Exchange, número de buzones y necesidad de coexistencia.
No en soporte general.
Microsoft finalizó el soporte de Exchange Server 2016 el 14 de octubre de 2025.
No en soporte general.
Exchange Server 2019 también alcanzó el fin de soporte el 14 de octubre de 2025.
Microsoft recomienda migrar a Microsoft 365 o evolucionar hacia Exchange Server Subscription Edition.
Exchange Server Subscription Edition es la versión on-premises actual de Exchange Server.
Las organizaciones que necesitan mantener Exchange local deberían revisar la ruta hacia SE y la documentación de soporte vigente.
Es una migración donde se traslada la organización Exchange en una transición relativamente concentrada, evitando una coexistencia prolongada.
Microsoft documenta actualmente soporte para hasta 2.000 buzones, aunque recomienda en la práctica utilizar este método en organizaciones mucho menores —aproximadamente 150 buzones o menos— por los tiempos y la operativa.
Es una arquitectura que conecta Exchange Server y Exchange Online.
Puede utilizarse para mantener coexistencia y mover buzones progresivamente.
No necesariamente.
La decisión depende de versión, número de usuarios, coexistencia y arquitectura.
Es una modalidad de configuración híbrida orientada a determinadas migraciones donde se quiere aprovechar Hybrid Configuration Wizard sin mantener una coexistencia híbrida completa a largo plazo.
Microsoft retiró Staged OutlookAnywhere onboarding el 8 de mayo de 2025.
Los nuevos proyectos deberían evaluar rutas actualmente soportadas, especialmente métodos híbridos cuando se necesita una transición gradual.
Sí.
Microsoft dispone de una migración automatizada desde Google Workspace capaz de tratar Gmail, calendarios y contactos, además de otras funcionalidades documentadas.
Microsoft incluye reglas dentro de las capacidades de su migración Google Workspace, aunque conviene validar el comportamiento concreto durante el piloto.
Microsoft dispone actualmente de procedimientos específicos para permisos y delegados de Google Workspace.
Deben configurarse y validarse dentro del proyecto.
Microsoft documenta procedimientos para tratar Rooms y Resources de Google Workspace dentro de proyectos de migración a Exchange Online.
Sí.
La migración IMAP permite trasladar principalmente mensajes y carpetas hacia Exchange Online.
No.
El protocolo IMAP no incluye elementos de calendario.
No.
Los contactos requieren otro método de exportación o migración.
No como parte de la migración IMAP estándar.
La documentación actual de Microsoft establece un máximo de 500.000 elementos por buzón y un tamaño máximo de mensaje migrable de 35 MB.
Estos valores deberían comprobarse de nuevo al iniciar un proyecto porque pueden cambiar.
Sí puede trasladarse la información disponible, pero primero hay que localizarla.
En sistemas POP3 el correo histórico puede estar almacenado únicamente en Outlook o archivos PST y no en el servidor.
Hay que inventariar los PST, asociarlos a sus propietarios y comprobar duplicados antes de decidir el procedimiento de importación.
Sí.
El alcance depende de versión, interfaces disponibles y herramienta utilizada.
Si se utiliza únicamente IMAP tendremos las mismas limitaciones que cualquier migración IMAP.
Sí, normalmente mediante IMAP cuando el hosting lo permite.
Calendarios y contactos no forman parte de esa migración.
Sí puede diseñarse una migración de correo, calendario y contactos mediante herramientas adecuadas.
Las aplicaciones Domino y bases de datos deben analizarse aparte.
No.
Pueden necesitar modernización, sustitución o un proyecto específico independiente de la migración de correo.
Sí.
Microsoft dispone de Cross-Tenant Mailbox Migration y también existen plataformas especializadas.
Entre otros requisitos, el usuario destino debe prepararse correctamente como MailUser con los atributos necesarios y debe existir el licenciamiento cross-tenant correspondiente.
La documentación actual de Microsoft indica que los buzones sometidos a cualquier tipo de hold quedan bloqueados para Cross-Tenant Mailbox Migration.
No debería eliminarse un hold sin validar previamente sus implicaciones legales o de cumplimiento.
En el procedimiento nativo de Microsoft, después de un movimiento correcto el buzón de origen deja de estar disponible como buzón y el objeto se mantiene como MailUser para determinados escenarios de routing y coexistencia.
Pueden formar parte de una migración.
El procedimiento concreto depende del origen y de la tecnología utilizada.
También deben revisarse Full Access, Send As y Send on Behalf.
Sí en determinados escenarios.
No basta con mover el calendario; conviene validar también su configuración de reservas y delegaciones.
Puede migrarse en muchos escenarios, pero depende del origen, herramienta y licenciamiento de Exchange Online.
Debe aparecer expresamente en el inventario.
Normalmente durante la ventana de cutover, después de confirmar que los buzones destino y Exchange Online están preparados para recibir correo.
Es recomendable revisar los tres.
Microsoft recomienda utilizarlos conjuntamente como parte de la estrategia de autenticación del correo.
Deben inventariarse y probarse.
Puede ser necesario migrar desde usuario y contraseña hacia OAuth, Microsoft Graph, SMTP relay u otra solución adecuada.
SMTP AUTH sigue existiendo para determinados escenarios y soporta OAuth, pero Microsoft recomienda deshabilitarlo cuando no es necesario y habilitarlo únicamente para los buzones que realmente lo requieran.
No debería diseñarse una nueva integración basada en autenticación básica heredada.
Muchas herramientas permiten realizar una primera carga y varias sincronizaciones posteriores.
Otros métodos, como determinados movimientos nativos, tienen un comportamiento diferente.
Es muy recomendable.
Permite conocer tiempos reales y validar calendario, permisos, Archives y otros elementos antes de afectar al resto de usuarios.
Podemos diseñar el proyecto para minimizar el impacto, pero no conviene garantizar interrupción cero.
DNS, autenticación, clientes y aplicaciones pueden necesitar una ventana de transición.
La migración de Exchange Online y la configuración individual de cada puesto son servicios distintos.
Podemos proporcionar instrucciones y coordinarnos con el equipo de TI, pero la intervención sobre cada equipo debe contratarse expresamente si se requiere.
La configuración individual de dispositivos no debe darse por incluida automáticamente en la migración.
Podemos definir los requisitos y ayudar al equipo de TI a preparar el cambio.
Depende principalmente de origen, número de buzones, volumen, número de elementos, límites del servidor, Archives, herramienta y modelo de coexistencia.
Depende del número y tipo de buzones y del origen.
Una migración IMAP sencilla puede tener un coste muy diferente de Exchange Hybrid, Google Workspace con delegaciones o un Tenant-to-Tenant con coexistencia.
Como punto de partida necesitamos saber plataforma origen, número de buzones, tamaños aproximados, shared mailboxes, Archives, calendarios, contactos, dominios, aplicaciones que envían correo y fecha objetivo.
Sí.
Podemos asumir la parte especializada de Microsoft 365 y coordinarnos con vuestro equipo para endpoints, aplicaciones, DNS, red y comunicación a usuarios.
Conclusión: una migración de correo es mucho más que cambiar el MX
Migrar correo a Office 365 o Microsoft 365 puede parecer uno de los proyectos cloud más sencillos, pero el resultado depende de entender correctamente el origen.
Una migración Exchange Server permite utilizar mecanismos nativos ricos y, cuando es necesario, establecer coexistencia híbrida. En 2026, además, cualquier proyecto que parta de Exchange Server 2016 o 2019 debe tener en cuenta que ambas versiones finalizaron su soporte general en octubre de 2025.
Google Workspace dispone de procedimientos propios de Microsoft capaces de trabajar con Gmail, calendarios, contactos y otras configuraciones, por lo que no debería tratarse como una migración IMAP genérica.
IMAP es una buena solución para mensajes y carpetas, pero no incluye calendario, contactos ni tareas. En POP3 la principal dificultad suele ser determinar dónde se encuentra realmente el histórico. Y en HCL Domino debemos separar el correo de las aplicaciones empresariales construidas sobre Domino.
En una migración Tenant-to-Tenant aparecen además dependencias de identidad, dominio, licencias, routing y cumplimiento.
A todo esto hay que añadir los elementos que con más facilidad se olvidan: shared mailboxes, permisos, Archives, salas, DNS y aplicaciones que envían correo automáticamente.
Por eso en Kloudeal comenzamos cada migración identificando qué plataforma tenemos delante, qué debe conservarse y cómo debe funcionar el entorno cuando Exchange Online pase a ser el sistema de producción.
Después seleccionamos el método, ejecutamos un piloto, realizamos premigraciones cuando la tecnología lo permite, coordinamos el cutover y validamos el resultado.
El objetivo no es únicamente que los mensajes aparezcan en el nuevo buzón. Es que los usuarios puedan enviar, recibir, consultar su calendario, utilizar los buzones compartidos y continuar trabajando desde Exchange Online con una configuración de correo coherente y administrable.
¿Necesitas migrar vuestro correo a Microsoft 365?
Podemos ayudarte a migrar desde Exchange Server, Google Workspace, IMAP, POP3, Zimbra, HCL Domino u otro tenant Microsoft 365.
Según el escenario podemos incluir assessment, Exchange Online, usuarios, buzones compartidos, calendarios, contactos, Archives, dominios, DNS, MX, SPF, DKIM, DMARC, herramienta de migración, piloto, cutover, validación y soporte posterior.
Indícanos desde qué plataforma partís, número aproximado de buzones y fecha objetivo y revisaremos qué información necesitamos para preparar una propuesta.
Solicitar valoración de migración de correoDocumentación oficial recomendada
Microsoft – migraciones de correo
- Microsoft – Ways to migrate multiple email accounts to Microsoft 365 or Office 365
- Microsoft – Exchange Cutover Migration
- Microsoft – Exchange Hybrid Deployments
- Microsoft – Minimal Hybrid Migration
Exchange Server Lifecycle
- Microsoft – Exchange Server 2016 and 2019 End of Support Roadmap
- Microsoft – Exchange Server Supportability Matrix
Google Workspace
- Microsoft – Automated Google Workspace Migration
- Microsoft – Google Workspace Migration Prerequisites
- Microsoft – Permissions, Delegates, Rooms, Resources and Tasks from Google Workspace
IMAP
- Microsoft – What You Need to Know About Migrating IMAP Mailboxes
- Microsoft – Migrate Other Types of IMAP Mailboxes
Tenant-to-Tenant
- Microsoft – Cross-Tenant Mailbox Migration
- Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration
Email Authentication
SMTP y aplicaciones
- Microsoft – Authenticated Client SMTP Submission
- Microsoft – Basic Authentication Deprecation in Exchange Online
- Microsoft – High Volume Email for Microsoft 365