Pasos para migrar el correo: calendario diario seguro

Pasos para migrar el correo: un calendario diario que reduce las interrupciones

Estos pasos no consisten en copiar archivos. Sirven para gestionar una transición de estado entre dos bases de datos activas mientras los usuarios modifican información en ambos extremos. Si la capa de datos (IMAP) se desincroniza de la capa de enrutamiento (DNS), se crea un enrutamiento dividido: parte de la organización recibe el correo en el servidor antiguo y el resto en el nuevo.

Este procedimiento detalla los pasos de cada día, desde T-7 hasta T+1. Sin teoría, solo la secuencia de ejecución. Para profundizar en la arquitectura, consulte la guía completa de configuración del correo.

Las tres capas que debe gestionar

Toda migración de correo abarca tres capas. Un fallo en cualquiera de ellas puede causar una interrupción.

1. Capa de datos: los mensajes históricos (IMAP)
2. Capa de enrutamiento: los registros DNS (MX) que indican dónde llega el correo nuevo
3. Capa de identidad: la configuración de los clientes (Outlook y aplicaciones móviles) con los que se accede al correo

T-7 días: descubrimiento y limpieza

No puede migrar aquello cuya existencia desconoce. Una lista de usuarios no es un inventario. Estos primeros pasos sirven para obtener una visión completa.

Haga un inventario completo

• Registre todos los tipos de objeto: buzones, alias, listas de distribución y carpetas públicas
• Identifique los buzones gigantes: busque los que superen los 20 GB. Google limita las descargas IMAP a unos 2,500 MB/día. Un buzón de 50 GB puede tardar semanas, no horas. La guía de migración de datos de Google Workspace documenta estos límites de transferencia.
• Limpie los datos inactivos: los exempleados no necesitan buzones activos. Expórtelos a archivos locales.

Si migra desde Exchange, use PowerShell para obtener el número real de elementos, ya que el tamaño en GB no es fiable debido a la compresión:

T-2 días: sincronización de precarga

No espere hasta el viernes por la noche. Traslade el 90% de los datos históricos mientras los usuarios siguen trabajando. Esta precarga reduce de forma considerable el riesgo durante el cambio.

Inicie la sincronización

Configure la herramienta de migración, o imapsync, para trasladar los mensajes con más de 30 días. Vigile los errores HTTP 429 (demasiadas solicitudes) o Google 11001.

Límites de transferencia que debe conocer

Advertencia para Gmail: no migre «Todos» junto con cada etiqueta como si fueran carpetas independientes. Las etiquetas de Gmail hacen referencia a los mismos mensajes, por lo que una correspondencia incorrecta puede crear duplicados en el destino. Asigne las etiquetas con cuidado y excluya Gmail/All Mail en esta configuración.

T-1 día: reducción del TTL (la regla de los 300 segundos)

Los registros DNS suelen almacenarse en caché durante 24 horas (TTL 86,400). La reducción del TTL es uno de los pasos que más se omiten y más se lamentan. Si cambia los MX sin reducir antes el TTL, algunos resolvedores pueden seguir enviando correo al servidor antiguo hasta que caduque su caché.

1. Inicie sesión en su proveedor DNS (Cloudflare, Route53, etc.)
2. Localice los registros MX
3. Cambie el TTL a 300 segundos (5 minutos)
4. No elimine todavía los registros antiguos; limítese a actualizar el TTL

Compruébelo con dig:

T-0 (viernes por la tarde): el cambio

Los usuarios han dejado de trabajar. Ejecute el cambio. Estos son los pasos más delicados de la migración.

Paso 1: congele la actividad

Pida a los usuarios que dejen de enviar correo. Si es posible, bloquee las cuentas en el origen para evitar mensajes huérfanos.

Paso 2: sincronización diferencial

Ejecute de nuevo la herramienta de migración. Esta pasada recoge los últimos 30 días y todos los elementos nuevos. Como el grueso de los datos ya se ha trasladado, normalmente debería tardar menos que la precarga, aunque el tiempo real depende del volumen y de los límites del proveedor.

Vigile los problemas de UIDVALIDITY: si el servidor de origen ha vuelto a indexar las carpetas, la herramienta podría descargar duplicados. Ejecute siempre primero una simulación. El RFC 3501 de IMAP explica en detalle la semántica de UIDVALIDITY.

Paso 3: cambie los registros MX

Actualice los registros MX para que apunten al proveedor nuevo. Para usuarios de TrekMail:

Con un TTL de 300 segundos, las cachés que lo respeten pueden actualizarse en unos 5 minutos; otros resolvedores pueden tardar más.

Paso 4: actualice SPF y DKIM

Publique y compruebe en SPF la autorización de las IP nuevas antes de que el proveedor nuevo empiece a enviar, pero mantenga las fuentes antiguas mientras todavía estén activas. Para conocer los detalles de la autenticación del correo en su dominio, consulte nuestra guía específica.

T+1 (lunes por la mañana): verificación

Los últimos pasos se centran en validar el resultado. No dé por hecho que todo ha funcionado; compruébelo.

Verificación del número de elementos

Compare el número de elementos del origen y del destino. Una diferencia inferior al 1% puede explicarse por elementos MIME dañados y debe documentarse. Una diferencia superior al 5% apunta a un problema general, como límites de profundidad de carpetas o filtros mal configurados.

Reconfiguración de los clientes

Según el cliente de correo y el cambio de servicio, los usuarios tendrán que reconfigurar la cuenta existente o retirarla y añadir la nueva.

Calendarios y contactos

TrekMail ofrece alojamiento profesional de correo para empresas con calendarios en el servidor mediante CalDAV y contactos mediante CardDAV. Sin embargo, la migración IMAP solo traslada correo, no esos datos. Exporte los calendarios (.ics) y los contactos (.vcf) desde el proveedor antiguo y después impórtelos en TrekMail. Tras configurar la sincronización, estarán disponibles en los dispositivos compatibles.

Puntos de control para continuar o detenerse

El plan de reversión

Si el sistema nuevo rechaza correo o faltan datos esenciales:

1. Restaure los MX: vuelva a dirigirlos al proveedor anterior. Con un TTL de 300s, algunas cachés pueden actualizarse en 5 minutos, pero la recuperación completa puede tardar más
2. Exporte el intervalo: mantenga accesible el proveedor nuevo y repita la conciliación; todo mensaje que llegue allí hasta que caduquen las cachés DNS debe exportarse en EML/MBOX e importarse en el servidor antiguo
3. Diagnostique: compruebe si hay errores 550 5.7.1 (Relay Access Denied) o bloqueos del firewall antes de volver a intentarlo

TrekMail automatiza estos pasos de migración

Una migración manual conlleva trabajo y riesgo. TrekMail automatiza parte de la capa de infraestructura para que pueda centrarse en sus clientes.

Para pequeñas empresas

No pague por funciones que no utiliza. La herramienta de migración integrada de TrekMail gestiona la conexión IMAP, los reintentos y la lógica de límites para los datos compatibles. Introduzca las credenciales, supervise el proceso y verifique después el resultado con el origen.

Para agencias y MSP

Aprovisionamiento masivo para más de 100 dominios. Almacenamiento compartido entre todos los clientes en lugar de límites por usuario. SMTP administrado que reduce la necesidad de gestionar el calentamiento de IP.

Todos los planes de pago incluyen una prueba gratuita de 14 días y requieren una tarjeta. El plan Nano no requiere tarjeta.

Conclusión

Estos pasos siguen un calendario estricto porque cada fase depende de la anterior. Si omite la reducción del TTL, el enrutamiento puede permanecer dividido hasta 24 horas mientras caducan las cachés. Si omite la precarga, la ventana de cambio puede prolongarse mucho más de lo previsto.

Siga el calendario, compare el número de elementos y tenga preparado un plan de reversión. Esa es la fórmula completa.

¿Quiere empezar? Cree su cuenta gratuita de TrekMail y utilice el motor de migración integrado para reducir el trabajo manual.