Cómo migrar el correo de la empresa a Microsoft 365 sin perder ningún email
TL;DR
- Cambiar el MX antes de migrar el historial es el error más frecuente y el que causa pérdida de correo.
- La migración de historial se hace en paralelo mientras el correo sigue llegando al servidor antiguo.
- Reduce el TTL del DNS a 300 segundos con 24-48h de antelación para acelerar la propagación del MX.
- Configura reenvío en el servidor antiguo durante la propagación para no perder correo en el período de transición.
- Los ficheros PST locales requieren un proceso separado de importación que no ocurre automáticamente.
La migración de correo corporativo a Microsoft 365 parece sencilla hasta que pierdes tres años de historial de un buzón o descubres que el equipo lleva dos días sin recibir correos de clientes porque el DNS se cambió antes de que la migración estuviera completa. El proceso técnico no es especialmente complejo si se hace en el orden correcto, pero ese orden importa más de lo que parece. Un error de secuencia en la migración de correo tiene consecuencias que pueden ser muy difíciles de revertir, y el coste de recuperarse de una migración mal ejecutada casi siempre supera el coste de haberla planificado bien desde el principio.
1. Planificación previa: lo que hay que resolver antes de tocar nada
Antes de crear el primer buzón en Microsoft 365, necesitas tener clara una serie de información que condiciona todo lo demás:
- Inventario completo de buzones: cuántas cuentas hay, qué tamaño tiene cada una, si hay buzones compartidos (para recursos como una sala de reuniones o una impresora que envía escaneados por correo), distribuciones (alias que redirigen a múltiples destinatarios) o buzones de servicios (noreply@, facturas@, contacto@).
- Historial a migrar: ¿cuántos años de correo hay que llevar a Microsoft 365? ¿Hay correo en ficheros PST locales en los ordenadores de los usuarios que no está en el servidor IMAP? Estos ficheros PST requieren un proceso separado de importación.
- Dependencias de correo: formularios de la web, sistemas de facturación o ERP, herramientas de marketing automation que envían correo usando las credenciales SMTP actuales. Después de la migración, estas aplicaciones necesitarán nuevas credenciales SMTP de Microsoft 365 para seguir funcionando.
- TTL del registro MX: cuánto tiempo tiene configurado el DNS actual. Si el TTL es de 24 horas, hay que reducirlo a 300-600 segundos al menos 24 horas antes de hacer el cambio para que la propagación sea más rápida.
- Ventana de migración: cuándo ejecutar el cambio de MX para minimizar el impacto. Un domingo por la noche o un viernes por la tarde minimizan la afectación al equipo.
Una gestoría de 8 personas en Zaragoza migró el correo a Microsoft 365 sin planificación previa. El técnico cambió el MX el primer día, antes de migrar el historial. El correo de los últimos 5 años quedó atrapado en el servidor antiguo mientras el nuevo ya recibía correo nuevo en Microsoft 365. La recuperación del historial tomó 3 días adicionales y requirió mantener el servidor antiguo activo durante semanas extra con coste adicional.
2. El orden correcto de la migración: la secuencia que no se puede invertir
El flujo de trabajo para una migración sin pérdida de correo tiene siempre el mismo orden:
Paso 1: Crear los buzones en Microsoft 365. Para cada usuario que tiene una cuenta de correo, crea el buzón correspondiente en Microsoft 365. Configura los alias adicionales que tiene cada cuenta (si juan.garcia@tuempresa.com también recibe en jgarcia@tuempresa.com, ese alias tiene que estar creado en Microsoft 365 antes de cambiar el MX).
Paso 2: Migrar el historial con el MX sin cambiar. Mientras el correo sigue llegando normalmente al servidor antiguo, usa una herramienta de migración para copiar el historial de correo al nuevo Microsoft 365. BitTitan MigrationWiz es la herramienta de terceros más usada por su fiabilidad y soporte para múltiples fuentes. Si vienes de Exchange, la migración nativa de Exchange Online es más directa. Si vienes de IMAP (la mayoría de servidores de hosting), el asistente de migración de IMAP en el centro de administración de Microsoft 365 es suficiente para historiales de hasta 10-15 GB por buzón.
La migración de historial puede ejecutarse durante la noche para no consumir ancho de banda durante el horario de trabajo. Con conexión de fibra de oficina y buzones de 5-10 GB por usuario, la migración de 10 buzones puede completarse en una noche.
Paso 3: Verificar que el historial está completo. Antes de cambiar el MX, pide a varios usuarios que verifiquen que su historial de correo está completo en el nuevo buzón de Microsoft 365. Que puedan encontrar correos específicos de meses o años anteriores.
Paso 4: Cambiar el MX. Solo en este momento, una vez verificado el historial, cambia el registro MX del dominio para que apunte a los servidores de Microsoft 365. El nuevo MX de Microsoft 365 tiene el formato tudominio-com.mail.protection.outlook.com (el punto en el dominio se sustituye por un guión).
3. Gestión de la propagación del MX: el período crítico
Después de cambiar el MX, hay un período de propagación durante el cual algunos servidores de correo del mundo siguen viendo el MX antiguo y envían correos al servidor antiguo, mientras otros ya ven el nuevo y envían a Microsoft 365. Esta propagación puede durar entre 1 hora (si el TTL era bajo) y 48 horas (si el TTL era alto y no lo redujiste antes).
Para no perder ningún correo durante este período, configura una regla de reenvío en el servidor antiguo que reenvíe a Microsoft 365 cualquier correo que reciba después del cambio de MX. Esto garantiza que, independientemente de a cuál de los dos servidores llegue el correo durante la propagación, acabará en Microsoft 365.
Una vez verificado que el MX ha propagado completamente (lo puedes verificar con MXToolbox viendo que todos los servidores DNS del mundo devuelven el nuevo MX), el servidor antiguo puede desactivarse o mantenerse en modo solo lectura durante 2-4 semanas como red de seguridad.
4. Configuración post-migración: lo que hay que hacer después del cambio de MX
La migración del correo es solo el principio. Después del cambio de MX hay una lista de configuraciones en Microsoft 365 que deben hacerse para que el servicio funcione correctamente y con las protecciones adecuadas:
- SPF, DKIM y DMARC: actualizar el registro SPF para incluir los servidores de Microsoft 365, activar DKIM en el centro de administración de Defender y configurar DMARC. Consulta nuestro artículo sobre SPF, DKIM y DMARC explicados para pymes para el proceso completo.
- Configuración de los clientes de correo: Outlook, Mail de Mac, clientes móviles en Android e iOS necesitan reconfiguración para apuntar a Microsoft 365. En entornos con Microsoft Intune, esto puede hacerse automáticamente. Sin Intune, hay que guiar a cada usuario.
- MFA activado para todos los usuarios: la migración a Microsoft 365 es el momento ideal para activar el doble factor de autenticación en todas las cuentas. Con el correo comprometido, un atacante puede resetear cualquier otra contraseña de la empresa.
- Actualización de aplicaciones que usan SMTP: formularios web, ERP, software de facturación. Necesitan nuevas credenciales SMTP de Microsoft 365. Microsoft 365 tiene opciones de relay SMTP que simplifican esta configuración para dispositivos y aplicaciones heredadas.
- Políticas de retención y archivado: si la empresa tiene requisitos de retención de correo por normativa (legal, fiscal), configura las políticas de retención en el Compliance Center de Microsoft 365.
5. Validación final: antes de dar por cerrada la migración
Antes de comunicar al equipo que la migración está completa y de desconectar el servidor antiguo, verifica esta lista:
- Los correos enviados desde Microsoft 365 llegan correctamente a destinos externos (Gmail, Outlook personal, servidores de clientes).
- Los correos externos llegan a Microsoft 365 (envía una prueba desde un correo personal).
- SPF, DKIM y DMARC están configurados y verificados (MXToolbox o mail-tester.com).
- El historial migrado es completo y accesible por los usuarios.
- Los calendarios y contactos están migrados si se incluyeron en la migración.
- Las reglas de correo del servidor antiguo que hay que recrear en Microsoft 365 están configuradas.
- Los buzones compartidos y distribuciones funcionan correctamente.
- MFA está activo para todos los usuarios.
6. El plan de rollback: qué hacer si algo sale mal
Si algo sale muy mal después del cambio de MX, el rollback es cambiar el MX de vuelta al servidor original. Esto es posible durante las primeras 48-72 horas si el servidor antiguo sigue activo y el correo que llegó a Microsoft 365 durante ese tiempo se puede migrar de vuelta (complicado pero posible).
Pasadas 72 horas, el rollback se complica significativamente. Por eso es importante mantener el servidor antiguo activo y no eliminarlo hasta que la migración esté completamente verificada y el equipo lleva al menos 2 semanas operando en Microsoft 365 sin problemas.
El servicio de hosting y mantenimiento gestionado de NetGoos incluye la gestión completa de migraciones de correo, desde la planificación inicial hasta la verificación post-migración y la actualización de todos los sistemas dependientes.
Comparativa de métodos de migración a Microsoft 365
| Método | Origen | Complejidad | Coste herramienta | Ideal para |
|---|---|---|---|---|
| IMAP nativo M365 | Cualquier IMAP | Baja | Incluido en M365 | Pymes <20 buzones, historial <10 GB |
| BitTitan MigrationWiz | IMAP, Exchange, Google | Media | ~10€/buzón | Migraciones complejas o grandes |
| Migración nativa Exchange | Exchange On-Premises | Alta | Incluido en M365 | Migración desde Exchange Server |
| Asistente migración Google | Google Workspace | Media | Incluido en M365 | Migración desde Google Workspace |
Por dónde empezar mañana
- Haz el inventario de buzones: lista de cuentas activas, tamaño aproximado de cada buzón, buzones compartidos y distribuciones, y si hay ficheros PST locales que migrar.
- Verifica el TTL del registro MX en tu registradora DNS. Si es mayor de 3600 segundos, redúcelo a 300 segundos para cuando llegue el momento del cambio.
- Crea los buzones en Microsoft 365 (puedes hacerlo durante el período de prueba gratuito de 30 días) y verifica que funcionan correctamente enviando correo de prueba entre ellos.
- Inicia la migración del historial usando la herramienta de migración IMAP nativa de Microsoft 365 o BitTitan. Planifica que se ejecute en las noches para no consumir ancho de banda durante el horario laboral.
Preguntas frecuentes
¿Cuánto tiempo lleva una migración de correo a Microsoft 365 para una empresa de 10 usuarios?
Para 10 usuarios con historiales de 1-3 años, el proceso completo lleva entre 1 y 3 días. La migración del historial puede hacerse en paralelo durante noches mientras el correo sigue llegando al servidor antiguo. El tiempo de corte de servicio real es de entre 5 y 60 minutos para el cambio de MX.
¿Qué pasa con el correo enviado durante la propagación del MX?
Durante la propagación, algunos servidores enviarán al servidor antiguo y otros al nuevo. La solución es configurar un reenvío automático en el servidor antiguo hacia Microsoft 365 durante ese período. Así no se pierde ningún correo.
¿Se puede migrar correo desde Gmail o Google Workspace a Microsoft 365?
Sí. Microsoft ofrece un asistente de migración específico para Google Workspace en el centro de administración de Microsoft 365. BitTitan MigrationWiz ofrece más control para migraciones complejas.
¿Qué pasa con los ficheros PST de Outlook que tienen correo antiguo?
Los ficheros PST requieren un proceso separado de importación usando el Import Service de Microsoft 365 o BitTitan. No migran automáticamente con la migración IMAP del servidor.
¿La migración afecta a las reglas y filtros de correo existentes?
Las reglas del cliente de Outlook migran con el perfil. Las reglas del servidor no migran automáticamente y hay que recrearlas en Microsoft 365. Haz un inventario de las reglas existentes antes de la migración.
¿Cuándo debo cambiar el MX: al principio o al final de la migración?
Al final. El error más frecuente es cambiar el MX antes de que el historial esté completo en Microsoft 365. El flujo correcto: crear buzones, migrar historial, verificar, ENTONCES cambiar el MX.
¿Necesito tener contratado Microsoft 365 antes de empezar la migración?
Sí. Necesitas las licencias activas y los buzones creados antes de migrar el historial. Microsoft ofrece un período de prueba de 30 días que puede usarse para validar la migración antes de comprometerse.