Migración POP3 a Microsoft 365: correo, PST e IMAP

En un entorno POP3, la ubicación del histórico decide la migración

La migración POP3 a Microsoft 365 empieza averiguando dónde están realmente los mensajes. POP3 es un protocolo de descarga y su configuración puede haber dejado parte del correo solo en los equipos. El servidor podría conservar una copia incompleta respecto a lo que cada empleado ve en Outlook. Por eso una migración desde el servidor no debe aprobarse sin revisar los datos locales.

Imaginemos que un empleado conserva varios años de correo en un archivo PST y otro equipo del departamento guarda mensajes más recientes de la misma dirección. Copiar ambas fuentes sin analizarlas puede duplicar información; copiar solo una puede dejar histórico fuera. El inventario debe relacionar persona, buzón, equipo y archivo, y acordar qué fuente se utilizará para cada periodo o conjunto de carpetas.

El usuario puede ayudar a localizar el contenido, pero la identificación necesita una comprobación técnica. Debe verificarse que los archivos se abren, qué carpetas contienen y si hay información personal o fuera del alcance acordado. Antes de intervenir se conserva una copia protegida de las fuentes que se vayan a utilizar y se registra el procedimiento de importación, para que una incidencia no obligue a reconstruir el inventario.

Cómo comprobar el histórico sin convertir la revisión en un simple recuento

El criterio de aceptación combina periodos, carpetas y ejemplos que el usuario pueda reconocer. Se prueban mensajes antiguos, enviados, adjuntos relevantes y la búsqueda de conversaciones. Las cantidades orientan, pero no bastan para resolver si dos fuentes contenían elementos repetidos o si una carpeta se había archivado fuera del buzón principal.

Después de la importación se configura el nuevo acceso a Exchange Online y se comprueba que los mensajes nuevos se guardan donde corresponde. Mantener varios perfiles sin explicar cuál debe usarse puede hacer que continúe acumulándose información en una ubicación anterior. El cierre debe incluir instrucciones de uso y una decisión documentada sobre la conservación de los archivos locales de origen.

Qué es POP3 y por qué complica una migración

POP3 —Post Office Protocol version 3— es un protocolo histórico utilizado para descargar correo desde un servidor hacia un cliente. Durante muchos años fue una solución habitual para pequeñas empresas: cada trabajador configuraba su cuenta en Outlook, Thunderbird u otro cliente y descargaba los mensajes al ordenador. El problema no es necesariamente que POP3 deje de funcionar. El problema aparece cuando necesitamos trasladar todos los datos acumulados durante años a otra plataforma.

El servidor puede no contener todo el histórico

Dependiendo de la configuración, Outlook puede descargar los mensajes y eliminarlos posteriormente del servidor. Podemos encontrarnos con:

Por eso una cuenta que ocupa 700 MB en el hosting puede acabar teniendo 15 GB de información relevante después de revisar todos los PST del usuario. POP3 tampoco almacena el calendario. POP3 es un protocolo de correo. No proporciona por sí mismo sincronización de: calendarios, contactos, tareas, delegaciones o configuración de Outlook. Esos elementos pueden estar guardados en el cliente local y deben incluirse expresamente en el assessment si queremos conservarlos.

POP3, IMAP y Exchange Online: tres modelos diferentes

La migración no consiste en convertir POP3 en Exchange. Lo que hacemos realmente es: recuperar los datos disponibles desde las diferentes ubicaciones y cargarlos en un nuevo buzón Exchange Online. Una vez terminado el proyecto, el usuario deja de depender del modelo POP3 para trabajar con el correo.

El problema real: identificar el origen maestro de cada dato

Antes de seleccionar herramienta necesitamos responder una pregunta por usuario: ¿cuál es la copia más completa de su correo? Caso 1: servidor más completo que Outlook. Puede ocurrir si POP3 estaba configurado para conservar todos los mensajes en servidor. Si además existe IMAP, el servidor puede ser la mejor fuente para la migración. Caso 2: Outlook es más completo. Muy habitual.

El servidor conserva poco histórico y el usuario tiene un PST que contiene años de correo. Caso 3: servidor y Outlook tienen información diferente. Este es uno de los casos más delicados. Puede haber: mensajes recientes en servidor, históricos locales, enviados únicamente en Outlook, carpetas locales adicionales. Caso 4: hay varios ordenadores. Si el mismo buzón se configuró por POP en varios equipos, pueden existir mensajes distintos en cada máquina.

No deberíamos elegir arbitrariamente uno y eliminar el resto. Caso 5: existen PST de archivo. Además del PST asociado a la cuenta actual pueden existir archivos creados mediante: AutoArchive, exportaciones manuales, backups o migraciones anteriores.

Inventario previo por usuario

La fase de discovery debería crear una ficha sencilla para cada buzón.

No es necesario inspeccionar manualmente cada correo. El objetivo no es leer los buzones. Necesitamos determinar: qué fuentes existen, cuánto ocupa cada una, hasta qué fecha llega y si existen diferencias evidentes.

Qué revisar en el servidor de correo actual

Incluso si los usuarios trabajan mediante POP3, el proveedor puede ofrecer también IMAP. Datos básicos.

Webmail como comprobación rápida. Una forma sencilla de entender qué conserva el servidor es entrar mediante webmail. Si en webmail únicamente aparecen mensajes desde 2025 pero Outlook contiene correo desde 2014, sabemos inmediatamente que una migración basada solo en IMAP será insuficiente.

Cómo localizar y clasificar los PST

Un Outlook Data File (.pst) puede contener correo, contactos, calendario, tareas y otros elementos de Outlook. En entornos POP pueden existir varios por usuario. No asumir que existe un solo PST. Podemos encontrar nombres como: correo.pst archivo.pst archive2019.pst backup-outlook.pst usuario-antiguo.pst Qué registrar.

No mover los PST originales hasta saber qué son. Durante el assessment conviene mantener una copia segura y evitar reorganizaciones improvisadas. El objetivo es poder volver a la fuente original si durante la carga detectamos cualquier problema.

Qué puede migrarse realmente

Los cuatro escenarios habituales de migración POP3

Escenario A: el servidor conserva el correo. El usuario trabaja por POP3, pero el proveedor también dispone de IMAP y el histórico continúa en servidor. Este es el escenario más sencillo. Podemos utilizar: migración IMAP hacia Exchange Online y tratar únicamente por separado calendarios, contactos u otros datos locales cuando sea necesario. Escenario B: el servidor prácticamente está vacío. Los mensajes se descargaron históricamente a Outlook.

Aquí una migración IMAP tendría poco valor. Necesitamos trabajar principalmente con: PST → Exchange Online. Escenario C: servidor, PST. Es posiblemente el escenario más frecuente. Por ejemplo:

Si importamos todo sin diseñar el solapamiento podemos introducir duplicados. Más adelante explicamos cómo abordarlo. Escenario D: migración selectiva. No todas las empresas quieren introducir quince años de correo dentro del buzón principal. Podemos decidir:

Migración IMAP hacia Microsoft 365

Microsoft dispone de una migración nativa para sistemas compatibles con IMAP. El procedimiento puede ejecutarse mediante Exchange Admin Center o Exchange Online PowerShell. Qué mueve. La migración IMAP está diseñada para trasladar: mensajes y carpetas de correo. No migra: contactos, calendarios ni tareas.

Flujo general

Referencia oficial: Microsoft – IMAP mailbox migration to Microsoft 365.

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

A fecha de actualización de esta guía, Microsoft documenta dos límites especialmente importantes.

Los mensajes se procesan del más reciente al más antiguo. Esto es relevante cuando un buzón supera el máximo de elementos. No deberíamos descubrirlo después del cutover. Mensaje de más de 35 MB. Si existe un mensaje que supera el límite de la migración IMAP de Microsoft, no debemos asumir que aparecerá automáticamente en Exchange Online. Podemos necesitar otro método de traslado para ese contenido.

El servidor origen también puede limitar la migración. Microsoft puede permitir una determinada concurrencia, pero el hosting puede imponer límites de: conexiones simultáneas, sesiones por usuario, conexiones por IP o throttling. Por eso el rendimiento debe medirse mediante un piloto. Políticas de archivo durante la migración. Microsoft recomienda evitar que las políticas de archivado o MRM interfieran mientras se está validando una migración IMAP, porque los elementos que se mueven automáticamente pueden aparecer como faltantes durante la comparación.

En entornos con requisitos legales o de compliance, cualquier modificación de políticas debe revisarse previamente y nunca utilizarse para eliminar obligaciones de conservación. Referencia oficial: Microsoft – IMAP migration limitations.

Sincronización incremental IMAP

Una ventaja importante del procedimiento nativo de Microsoft es que no necesitamos realizar necesariamente una copia única justo el día del cambio. Initial Sync. Primero se migra el contenido existente. Incremental Sync. Mientras el lote continúa activo, Microsoft documenta actualmente una sincronización incremental aproximadamente cada 24 horas. Los mensajes nuevos que sigan entrando en el servidor origen pueden copiarse en esas pasadas.

Esto permite una premigración. En este caso se contemplan: miércoles: iniciar migración, jueves-viernes: revisar progreso, fin de semana: cambiar MX, días posteriores: mantener temporalmente el lote, confirmar flujo y cerrar sincronización. El MX y la sincronización son conceptos diferentes. Cambiar el MX decide dónde entra el correo nuevo. El lote IMAP se encarga de copiar contenido existente o cambios detectados en origen.

Por eso la estrategia debe coordinar ambos elementos. Referencia oficial: Microsoft – IMAP migration with Exchange Online PowerShell.

Importar PST con Microsoft Purview

Cuando los mensajes ya no están en el servidor, el método IMAP deja de ser suficiente. Si la información existe en archivos PST podemos utilizar el servicio de importación de Microsoft 365 desde Microsoft Purview. Dos métodos oficiales. Microsoft documenta actualmente:

Network Upload suele ser el escenario más práctico. Para una migración POP3 empresarial en la que se han centralizado los PST, normalmente evaluaremos Network Upload antes que una carga manual usuario por usuario. No se necesita una suscripción Azure independiente. Microsoft proporciona el almacenamiento temporal necesario como parte del procedimiento de importación. Permisos. Microsoft recomienda aplicar el principio de mínimo privilegio.

El procedimiento actual utiliza roles como: Mailbox Import Export y Mail Recipients en Exchange Online, o permisos administrativos equivalentes según el procedimiento. Referencia oficial: Microsoft – Import PST files to Microsoft 365.

Cómo funciona una importación PST mediante Network Upload

El proceso tiene más control que copiar el archivo manualmente dentro de Outlook. 1. Obtener la URL SAS y AzCopy. Desde Microsoft Purview se obtiene la información necesaria para acceder al almacenamiento temporal. La URL SAS contiene credenciales de acceso y debe protegerse como cualquier otro secreto administrativo. 2. Cargar PST. Microsoft exige utilizar la versión de AzCopy indicada en su procedimiento para la carga soportada.

Microsoft señala expresamente que Azure Storage Explorer no debe sustituir este proceso para realizar la carga PST documentada. 3. Crear el mapping CSV. Debemos indicar qué archivo corresponde a qué buzón.

4. Crear el Import Job. El trabajo se crea actualmente desde: Microsoft Purview → Data Lifecycle Management → Microsoft 365 → Import. 5. Analizar PST. Microsoft analiza los datos antes de importarlos. 6. Aplicar filtros si interesa. Podemos decidir no importar necesariamente todo el contenido. Microsoft permite aplicar determinados filtros relacionados con: antigüedad y tipos de mensaje. 7. Importar. El job procesa los PST y los introduce en los buzones definidos en el mapping.

8. Revisar resultados. Debemos comprobar: estado, elementos omitidos, corrupción, buzón de destino y volumen esperado. Referencia oficial: Microsoft – Use network upload to import PST files.

Tamaño y rendimiento de PST

Una importación de 200 GB repartida entre 20 usuarios no se comporta igual que un único PST de 200 GB. Microsoft recomienda PST de aproximadamente 20 GB o menos. La documentación actual de troubleshooting de Microsoft recomienda evitar PST excesivamente grandes. Si un PST supera aproximadamente los 20 GB, Microsoft indica que el procesamiento puede ralentizarse y recomienda considerar dividirlo.

Rendimiento típico. Microsoft documenta actualmente una tasa típica aproximada de 24 GB por día para importar un PST a un buzón. No es un SLA. El servicio funciona sobre una infraestructura compartida y el rendimiento real puede variar. Múltiples PST hacia el mismo buzón. Si importamos varios archivos simultáneamente al mismo buzón, no debemos multiplicar linealmente esa tasa. Microsoft procesa importaciones hacia el mismo destino de forma que pueden afectarse entre sí.

Importaciones a buzones diferentes. La paralelización suele ser más favorable cuando los PST tienen destinos distintos. Planificar con el piloto. No deberíamos decir: “tenemos 500 GB y por tanto tardará exactamente X horas”. Es preferible realizar una carga inicial representativa y utilizar el resultado para ajustar el calendario.

Cómo evitar duplicados cuando combinamos IMAP y PST

Este es uno de los puntos más importantes de una migración POP3. Ejemplo. Supongamos:

Si migramos ambos completos, los años 2023–2026 podrían aparecer en las dos fuentes. Purview tiene su propio mecanismo de detección de duplicados. Microsoft documenta que el servicio PST utiliza información SourceEntryId para identificar duplicados dentro del proceso de importación. Pero no deberíamos interpretar eso como una garantía universal de deduplicación entre datos que llegan mediante mecanismos distintos. Un mensaje copiado previamente mediante IMAP y el mismo mensaje contenido en un PST pueden haber llegado al destino por rutas técnicamente diferentes.

Diseñar el periodo de solapamiento. Tenemos varias estrategias posibles.

No buscar el “cero duplicados” mediante eliminación agresiva. En una migración real es preferible tolerar alguna excepción controlada antes que eliminar correo válido basándonos en una deduplicación poco fiable. Los criterios deben definirse antes del cutover. Referencia oficial: Microsoft – PST Import FAQ.

Importación PST mediante Outlook

Para pocos usuarios y volúmenes razonables, también puede utilizarse Outlook para trasladar información desde un PST hacia un buzón Exchange Online. Outlook clásico. Microsoft mantiene el procedimiento de: File → Open & Export → Import/Export → Outlook Data File (.pst). El contenido puede importarse dentro del buzón Microsoft 365. Cuándo puede tener sentido.

El PST puede contener más que correo. Outlook clásico puede importar: correo, contactos y calendario contenidos en PST, dentro de las capacidades soportadas. Pero ciertas propiedades y configuraciones no se exportan/importan. Microsoft señala, por ejemplo, que las propiedades de carpetas, determinadas configuraciones, reglas y listas de remitentes bloqueados no deben darse por trasladadas mediante el PST. Referencia oficial: Microsoft – Import email, contacts and calendar from a PST.

PST y el nuevo Outlook en 2026

Este punto ha cambiado y conviene evitar información antigua. El nuevo Outlook ya puede abrir PST. Microsoft permite actualmente: abrir archivos PST, leer y buscar correos y mover mensajes entre PST y buzón mediante drag-and-drop. Pero todavía no equivale al soporte de Outlook clásico. A fecha de actualización de esta guía, Microsoft indica que la importación completa en bloque desde un PST hacia el buzón no está disponible todavía en el nuevo Outlook.

Calendarios y contactos dentro del PST. Microsoft también indica que los elementos de calendario y contactos guardados en PST no están disponibles actualmente en el nuevo Outlook de la misma manera.

Para una migración empresarial no deberíamos depender del cliente del usuario. Si tenemos decenas de PST, el procedimiento de Purview u otra herramienta centralizada proporciona un modelo mucho más controlable que abrirlos manualmente uno por uno. Referencia oficial: Microsoft – PST support in Outlook.

Qué ocurre con los contactos

POP3 e IMAP no migran los contactos como parte del correo. Posibles ubicaciones. Los contactos pueden encontrarse en: PST, Outlook, CSV, agenda del dispositivo móvil u otra plataforma. PST. Si están dentro de un PST, Outlook clásico puede importarlos dentro del buzón correspondiente. CSV. También pueden utilizarse procedimientos de importación CSV dependiendo del origen. Contactos corporativos frente a contactos personales.

No deberíamos confundir: los contactos personales de Outlook con usuarios y contactos del directorio corporativo Microsoft 365.

Qué ocurre con los calendarios

El calendario tampoco forma parte de POP3 ni de IMAP. Puede estar dentro del PST. Si Outlook almacenó las citas y reuniones dentro de un PST, pueden formar parte de una importación mediante Outlook clásico. No asumir que todas las reuniones seguirán comportándose igual. Un calendario histórico puede contener: reuniones recurrentes, asistentes externos, eventos antiguos y citas sin organizador válido.

Conviene comprobar especialmente el calendario futuro. Calendario nuevo. Una vez en Exchange Online, los usuarios dispondrán de un calendario sincronizado con el nuevo buzón y podrán utilizar capacidades de Microsoft 365 como disponibilidad, invitaciones y calendarios compartidos según configuración.

Reglas, firmas y autocompletar

Son elementos que los usuarios suelen considerar parte de “su correo”, pero técnicamente requieren un tratamiento diferente.

No convertir detalles secundarios en bloqueantes. La prioridad del cutover debería ser: correo entrante, correo saliente, histórico, calendario necesario y contactos necesarios. Las preferencias individuales pueden tratarse después cuando proceda.

Elementos enviados: uno de los grandes olvidados de POP3

En muchos entornos POP, la bandeja de enviados existe únicamente en Outlook. El servidor puede no disponer de ninguna copia. Por qué importa. Para determinados departamentos, los mensajes enviados pueden ser incluso más importantes que la bandeja de entrada. Por ejemplo: comercial, administración, legal, compras o dirección. Qué validar.

Cuentas genéricas y buzones compartidos

En entornos POP es habitual encontrar cuentas como: info@empresa.com administracion@empresa.com ventas@empresa.com con una contraseña compartida entre varias personas. Microsoft 365 permite mejorar ese diseño. Cuando corresponde, podemos crear un Shared Mailbox y conceder acceso a usuarios individuales. Así cada persona puede autenticarse con su propia identidad en lugar de compartir una contraseña genérica. Licenciamiento.

Microsoft documenta actualmente que un buzón compartido puede funcionar sin licencia propia hasta determinadas capacidades. Sin licencia propia, el límite actual estándar es de 50 GB. Para superar ese tamaño o utilizar determinadas capacidades como Archive, Litigation Hold o funcionalidades avanzadas pueden necesitarse licencias adicionales. Los usuarios que acceden sí necesitan Exchange. Las personas que acceden al Shared Mailbox deben estar correctamente licenciadas para Exchange Online.

Referencia oficial: Microsoft – Shared mailboxes.

Qué licencia necesita un usuario después de migrar

El objetivo técnico es crear un buzón Exchange Online, pero la licencia final depende de las necesidades del usuario.

Mailbox size. Los límites actuales documentados por Microsoft incluyen, por ejemplo:

Los límites y planes deben volver a comprobarse cuando se contrate el proyecto. Referencia oficial: Microsoft – Exchange Online Limits.

Dominio y DNS: el correo nuevo debe terminar en Exchange Online

La migración de datos y el cambio de flujo de correo son dos actividades diferentes. Podemos tener gran parte del histórico ya cargado en Microsoft 365 y continuar recibiendo correo en el proveedor antiguo hasta la ventana de cutover. Registros que normalmente revisamos.

Verificar el dominio no cambia el correo. Podemos añadir y verificar el dominio en Microsoft 365 antes del cutover. La entrega entrante no se redirige hasta que modificamos el MX.

Registro MX: el punto de cambio del correo entrante

Cuando actualizamos el registro MX, los nuevos remitentes comienzan a entregar correo hacia Microsoft 365 conforme se propaga la modificación DNS. No cambiarlo antes de preparar los buzones. Antes del MX necesitamos haber validado: usuarios, licencias, dominio, Exchange Online, mail flow y capacidad de envío/recepción. El histórico no se mueve con el MX. Esto es importante. El MX solo controla el correo nuevo.

Los mensajes antiguos siguen donde estaban hasta que los migramos mediante IMAP, PST u otro procedimiento. Proveedor antiguo. No deberíamos cancelar el proveedor inmediatamente después del cambio. Primero debemos confirmar que: todo el correo nuevo llega a Microsoft 365 y no existen dependencias pendientes. Referencia oficial: Microsoft – Connect your domain by adding DNS records.

SPF: no crear dos registros

SPF es especialmente importante durante una transición porque pueden coexistir temporalmente varias fuentes de envío. Una regla fundamental. Microsoft indica que un dominio debe tener un único registro SPF. Si el dominio ya tiene uno, no debemos añadir un segundo registro independiente para Microsoft 365. Durante la coexistencia. Podemos necesitar autorizar temporalmente: Microsoft 365, proveedor anterior, CRM, ERP, plataforma de marketing si todos siguen enviando legítimamente correo con el dominio.

Después del proyecto. Deberíamos limpiar las fuentes que ya no existen. Mantener proveedores antiguos innecesariamente dentro del SPF amplía la superficie autorizada de envío. También existe el límite de lookups DNS. Un SPF no puede crecer indefinidamente añadiendo include:. El diseño debe respetar las limitaciones del estándar y las fuentes reales. Referencia oficial: Microsoft – External DNS records for Microsoft 365.

DKIM: preparar la firma del nuevo proveedor

Cuando Exchange Online se convierte en la plataforma de envío, recomendamos configurar DKIM para el dominio. Microsoft utiliza CNAME. Los valores concretos deben obtenerse desde el tenant Microsoft 365. No conviene copiar ciegamente registros de otro tenant o de un ejemplo encontrado en Internet. Durante la transición. Google, el hosting anterior u otras plataformas pueden seguir teniendo sus propios selectores DKIM.

No existe ningún problema conceptual en que un dominio tenga distintos selectores para distintos servicios. Validar después. Una vez habilitado DKIM, deberíamos enviar mensajes de prueba y comprobar que los encabezados reflejan correctamente la firma y autenticación esperadas. Referencia oficial: Microsoft – Configure DKIM.

DMARC: no endurecerlo a ciegas durante el cutover

DMARC utiliza los resultados de SPF y DKIM junto con la alineación del dominio. Tres políticas principales.

Una migración cambia las fuentes de envío. Si aplicamos directamente p=reject sin haber inventariado: CRM, formularios web, ERP, impresoras, software contable y plataformas de marketing podemos afectar a mensajes legítimos. Enfoque más seguro. Normalmente conviene: inventariar → configurar SPF/DKIM → monitorizar → corregir → endurecer. Referencia oficial: Microsoft – Configure DMARC.

Autodiscover y configuración de Outlook

Exchange Online utiliza Autodiscover para ayudar a los clientes Outlook a localizar correctamente el servicio. Después del cambio de plataforma. Un equipo que llevaba años configurado mediante: POP3, servidor SMTP manual debe pasar a conectarse como buzón Microsoft 365 / Exchange Online. Perfil de Outlook. Dependiendo del entorno puede resultar conveniente crear un nuevo perfil en lugar de reutilizar una configuración POP histórica con varios PST y parámetros heredados.

Esto es distinto de la migración cloud. La creación y migración de buzones en Microsoft 365 no implica automáticamente intervenir individualmente sobre cada dispositivo del usuario. Conviene definir claramente qué tareas ejecutará el equipo de TI local y qué instrucciones necesitan los usuarios después del cutover.

Aplicaciones, impresoras y sistemas que envían correo

Uno de los riesgos más habituales es olvidarse de todo lo que envía correo sin ser una persona.

No copiar automáticamente usuario y contraseña antiguos. Microsoft 365 dispone de diferentes métodos para envío de correo desde dispositivos y aplicaciones. El método adecuado dependerá de: autenticación, volumen, origen, necesidad de enviar internamente/externamente y compatibilidad de la aplicación. Basic Authentication. No deberíamos diseñar una migración nueva basándonos en autenticación heredada si existe un mecanismo moderno apropiado. Inventariar antes del MX.

Estas aplicaciones deberían probarse antes o inmediatamente después del cutover según el diseño.

Aprovechar el cambio para mejorar la seguridad del correo

Pasar a Exchange Online permite incorporar una estrategia de identidad y protección más moderna, pero la seguridad depende de la configuración y licencia. MFA. Los usuarios deberían disponer de un mecanismo de autenticación adecuado y los administradores de una protección especialmente estricta. Conditional Access. Si la licencia incluye Microsoft Entra ID P1 podemos diseñar políticas de acceso más granulares. Defender for Office 365.

Las capacidades disponibles dependen del plan contratado. SPF, DKIM y DMARC. Deben formar parte de la transición del dominio y no considerarse un trabajo opcional para “más adelante”. Administradores. Conviene evitar utilizar una cuenta administrativa como buzón normal de usuario cuando podemos separar funciones.

Fases recomendadas de una migración POP3 → Microsoft 365

Fase 1. Discovery. Revisamos: usuarios, proveedor, POP3, IMAP, webmail, PST, Outlook, calendarios, contactos, dominio, DNS y aplicaciones. Fase 2. Clasificación de usuarios. No todos tendrán el mismo método.

Fase 3. Diseño de Microsoft 365. Definimos: usuarios, licencias, Shared Mailboxes, dominio, seguridad y método de envío para aplicaciones. Fase 4. Preparación del tenant. Configuramos el entorno necesario para recibir datos y correo. Fase 5. Centralización de PST. Cuando el proyecto incluye históricos locales, recopilamos y clasificamos los PST necesarios. Fase 6. Piloto. Elegimos usuarios representativos. Fase 7. Premigración. Ejecutamos IMAP y/o cargas PST antes del corte cuando sea posible.

Fase 8. Validación de la carga inicial. Comprobamos errores y volúmenes. Fase 9. Cutover. Cambiamos MX y demás configuraciones necesarias. Fase 10. Sincronización final. Cuando el método IMAP continúa activo, dejamos que procese los cambios pendientes antes de cerrarlo. Fase 11. Validación funcional. Revisamos correo y demás elementos incluidos. Fase 12. Cierre del origen. Solo después de confirmar que ya no existe ninguna dependencia.

Cómo elegir usuarios para el piloto

Un piloto no debería incluir únicamente el buzón más sencillo.

Qué debería proporcionarnos el piloto. Velocidad, errores, tamaño real, comportamiento de carpetas, duplicados y tareas manuales necesarias.

Cutover: pasar la producción a Exchange Online

El cutover debe estar documentado.

No cancelar el hosting esa misma noche. Es recomendable mantenerlo durante una ventana controlada hasta confirmar: correo nuevo, históricos, aplicaciones y posibles excepciones.

Cómo validar la migración

Una migración POP necesita más validación que mirar el estado de un job. Validación de identidad.

Validación de mail flow.

Validación del histórico. Comprobar por muestra: mensajes antiguos, mensajes recientes, Inbox, Sent, subcarpetas y adjuntos. Validación PST. Revisar: mapping, volumen, elementos omitidos, elementos corruptos y destino Primary/Archive. Contactos y calendarios. Validarlos únicamente si formaban parte del alcance. DNS. Comprobar: MX, SPF, DKIM y DMARC. Aplicaciones. Confirmar: ERP, CRM, web, scanners y sistemas de alertas incluidos.

Qué cambia para el usuario al pasar de POP3 a Exchange Online

El cambio es mayor de lo que parece.

No toda la formación tiene que hacerse el primer día. Lo imprescindible es que el usuario sepa: cómo iniciar sesión, dónde está su correo, dónde está el histórico y dónde solicitar ayuda interna si encuentra información pendiente.

Cuánto tarda una migración POP3 a Microsoft 365

No puede calcularse solo con el número de buzones.

Una empresa con 10 usuarios puede ser compleja. Diez usuarios con: dos ordenadores cada uno, cinco PST por persona, diez años de históricos pueden requerir más trabajo que 50 buzones IMAP limpios y completamente almacenados en servidor.

Qué determina el coste de una migración POP3

La diferencia más importante: IMAP frente a POP real

Si todo el histórico puede obtenerse mediante IMAP, el proyecto suele ser bastante más predecible. Si necesitamos buscar información en ordenadores y PST locales, el trabajo aumenta porque el dato está descentralizado.

Errores frecuentes al migrar POP3 a Microsoft 365

Checklist antes de migrar POP3 a Microsoft 365

Preguntas frecuentes sobre migración POP3 a Microsoft 365

¿Se puede migrar directamente desde POP3 todo el correo histórico?

No debe asumirse que el servidor contiene todo lo que utiliza el usuario. La configuración de descarga puede haber dejado mensajes únicamente en uno o varios equipos. Antes de definir el método se revisan el servidor, los perfiles de correo y los archivos locales para identificar las fuentes que cubren el histórico necesario.

¿Un archivo PST incluye automáticamente todo lo que hay que trasladar?

Es una fuente que necesita revisión: puede contener solo determinados periodos, carpetas o elementos de una cuenta. Hay que comprobar su contenido, que se pueda abrir y su relación con otras copias. Esa revisión permite decidir qué se importará y evitar tanto la pérdida de histórico como duplicaciones innecesarias.

¿Cómo se evitan duplicados al reunir varias fuentes?

Se documenta qué información contiene cada fuente y se define la estrategia antes de importar. Si existen copias solapadas, se prueba cómo las trata el método elegido y se valida una muestra en destino. No conviene confiar en que toda repetición se resolverá automáticamente ni mezclar archivos sin conocer su procedencia.

¿Qué hay que entregar al usuario después de la migración?

Debe saber qué perfil utilizar, dónde encontrar el histórico y cómo guardar desde entonces los mensajes nuevos. También se explican las diferencias pendientes y qué ocurre con los archivos de origen. La aceptación incluye pruebas de envío, recepción, búsqueda y adjuntos, además de la comprobación de que no sigue trabajando en el entorno anterior.

Recomendaciones finales: en POP3 la migración empieza buscando los datos, no copiándolos

Una migración POP3 a Microsoft 365 puede parecer sencilla porque POP3 es un protocolo básico. En realidad, precisamente esa simplicidad es lo que puede convertirla en un proyecto más laborioso. Durante años los mensajes pueden haberse descargado en ordenadores, eliminado del servidor, distribuido entre diferentes PST y almacenado junto con elementos enviados, contactos y calendarios que nunca existieron en el hosting.

Por eso el primer paso no debería ser configurar una herramienta. Deberíamos determinar: qué conserva el servidor, qué tiene cada usuario en Outlook, qué PST existen y qué información debe conservar realmente la empresa. Si el proveedor mantiene el histórico y permite IMAP, Microsoft dispone de una migración nativa hacia Exchange Online. Actualmente puede mover mensajes y carpetas, mantener sincronizaciones incrementales y facilita realizar gran parte de la transferencia antes del cambio de MX.

Pero tiene límites que deben conocerse: no migra contactos, calendarios ni tareas, existe un máximo documentado de elementos por buzón y los mensajes por encima del tamaño soportado necesitan otro tratamiento. Cuando el correo reside localmente, los PST se convierten en la fuente principal. Para proyectos empresariales, Microsoft Purview permite cargar PST mediante AzCopy y mapearlos hacia buzones concretos. El proceso ofrece reporting, filtrado y una forma centralizada de trabajar con múltiples archivos, aunque el tamaño de los PST y la velocidad de ingestión deben incluirse en la planificación.

Cuando IMAP y PST contienen periodos solapados, hay que diseñar expresamente qué información procede de cada fuente. No conviene confiar en que cualquier combinación de herramientas eliminará automáticamente todos los duplicados. Después llega el cutover. El dominio debe estar preparado en Microsoft 365, los buzones creados y licenciados y Exchange Online validado antes de cambiar el MX. SPF debe mantenerse como un único registro correctamente construido, DKIM debe configurarse para el nuevo servicio y DMARC debería evolucionar de forma controlada después de comprobar todas las fuentes legítimas de envío.

También deben inventariarse ERP, CRM, formularios web, scanners y otras aplicaciones que utilicen correo. Son elementos fáciles de olvidar y pueden convertirse en la principal incidencia después de un cambio aparentemente correcto. La migración termina cuando el correo nuevo entra y sale correctamente desde Exchange Online, el histórico acordado está disponible, los datos locales incluidos se han trasladado, las aplicaciones funcionan y podemos retirar el proveedor anterior sin depender de información que todavía se encuentre únicamente allí.

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 – Perform an IMAP migration with PowerShell
• Microsoft – Manage migration batches in Exchange Online

Importación PST.

• Microsoft – Learn about importing PST files
• Microsoft – Network Upload for PST files
• Microsoft – PST Import FAQ
• Microsoft – Troubleshoot PST Import

Outlook y PST.

• Microsoft – Importar correo, contactos y calendario desde PST
• Microsoft – Abrir y buscar elementos en un PST

Exchange Online.

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

Dominio y DNS.

• Microsoft – Connect your domain by adding DNS records
• Microsoft – External DNS records for Microsoft 365

SPF, DKIM y DMARC.

• Microsoft – Configure SPF
• Microsoft – Configure DKIM
• Microsoft – Configure DMARC