Migración de correo: los 7 fallos que provocan pérdidas

La migración de correo parece una tarea de copia hasta que los mensajes empiezan a llegar a dos sitios, los usuarios responden a hilos antiguos y reciben rebotes, y alguien descubre que el buzón del director general supera en 85GB el plan contratado. Si te interesa el aspecto de las herramientas, empieza por esta guía de imapsync para operadores. Este artículo es el procedimiento para gestionar todo lo que rodea la migración: DNS, asignación de carpetas, limitaciones de velocidad, cuotas de buzones y casos extremos que convierten un trabajo rutinario en una interrupción de fin de semana.

El problema es sencillo: las personas tratan el correo como si fueran archivos. La parte más incómoda es que los buzones siguen cambiando mientras los trasladas, las cachés DNS ofrecen una imagen engañosa y los servidores IMAP no se ponen de acuerdo sobre las carpetas. La solución no requiere heroicidades. Exige preparación, verificación y negarse a tomar atajos que parecen inofensivos a las 6 PM y resultan catastróficos a las 9 AM del lunes.

Por qué falla una migración de correo en producción

La migración falla cuando los operadores la tratan como un único acontecimiento en vez de una secuencia controlada: inventario, preparación, cambio, sincronización incremental y validación. El correo contiene datos activos. El DNS se guarda en caché. Los clientes se comportan de forma desigual. Si omites una sola capa, no obtendrás un traslado limpio, sino entregas parciales, duplicados o pérdidas silenciosas.

1. El DNS dividido provoca la primera interrupción

El primer fallo de una migración no suele ser la copia, sino el enrutamiento. Algunos remitentes usan el MX nuevo en pocos minutos. Otros mantienen el anterior en caché durante horas. En esa ventana, el correo puede llegar a ambos sistemas. Si el host antiguo ya está apagado, habrá rebotes. Si sigue activo, los mensajes quedarán aislados.

Microsoft recomienda acortar el TTL de MX antes de un cambio IMAP para que los registros actualizados se propaguen más rápido. Es un consejo aburrido, pero salva migraciones. Si el TTL actual es de 86,400 segundos y cambias MX la noche del traslado, ya has perdido el control del calendario.

;; T-48 hours: inspect current MX TTL
example.com.  86400  IN MX 10 oldmail.example.com.

;; T-48 hours: lower it before cutover
example.com.    300  IN MX 10 oldmail.example.com.

;; T-0: switch to new provider
example.com.    300  IN MX 10 mail.trekmail.net.

Si te trasladas a TrekMail, obtén los registros exactos en Añadir un dominio a TrekMail y confirma que el dominio figure como activo antes de anunciar el cambio. TrekMail también comprueba el DNS en directo, lo que ayuda a detectar el error clásico de dejar registros MX antiguos.

Mal cambio: modificar MX a las 10 PM, apagar el host anterior a las 10:05 PM y descubrir el lunes que la puerta de enlace de un proveedor guardó el registro antiguo durante todo el fin de semana.

Otra trampa es SPF. Si la recepción apunta al sistema nuevo pero la autenticación de salida sigue mal configurada, las respuestas empiezan a llegar a spam. Las reglas de Google para remitentes ya no son opcionales. Usa un único registro SPF, alinea DKIM y publica DMARC.

2. Los límites destruyen la fantasía de migrar en un fin de semana

El segundo fallo es una cuestión física. El cuello de botella casi nunca es el ancho de banda local. Es el proveedor de origen, que decide que ya has copiado suficiente por ahora. Google, Microsoft y otros sistemas alojados limitan el tráfico IMAP agresivo. Cuando ocurre, las estimaciones dejan de ser reales y la tarea se ralentiza o se detiene.

Por eso una migración de golpe es un mal plan para cualquier equipo que no sea diminuto. Un buzón de 10GB copiado desde un entorno que solo permite una fracción al día no terminará porque tú lo desees. Los límites no respetan tu ventana de mantenimiento.

La solución es una migración por etapas:

1. Precargar primero el correo antiguo, normalmente todo lo anterior a 60 o 90 días.
2. Permitir que la herramienta reintente y aplique pausas durante la semana.
3. Cambiar MX solo cuando el grueso histórico ya esté en el destino.
4. Ejecutar una pasada incremental del correo reciente durante el cambio.

La importación IMAP en el servidor de TrekMail está diseñada para este proceso. La documentación vigente de Iniciar una migración en el panel confirma que la herramienta extrae correo de un servidor IMAP externo hacia el buzón elegido en TrekMail y ofrece la opción Omitir duplicados. Esto importa porque repetir pasadas es normal en una migración segura, no una señal de avería.

Método anterior frente al nuevo: los proveedores tradicionales cobran por puesto y además obligan a comprar herramientas de migración. Con el método nuevo preparas el traslado mediante migración IMAP integrada, pagas un plan fijo que empieza en $3.50 al mes y dejas de convertir cada buzón en un nuevo coste de licencia.

3. UIDVALIDITY puede convertir una migración en tres copias del buzón

Este fallo se esconde detrás de una barra de progreso aparentemente correcta. Los mensajes IMAP tienen identificadores únicos, pero solo son fiables dentro de las reglas del buzón al que pertenecen. Cuando el servidor modifica el estado de la carpeta y reinicia UIDVALIDITY, una herramienta ingenua puede confundir los mensajes antiguos con nuevos y volver a copiarlos.

IMAP4rev1 (RFC 3501) define UIDVALIDITY por un motivo. Si cambia, los UID anteriores dejan de ser fiables. Es un comportamiento normal del protocolo, pero resulta desastroso para una herramienta que depende únicamente de esos UID.

Desencadenantes habituales:

• Un usuario cambia el nombre de una carpeta o la recrea durante el traslado.
• El servidor de origen reconstruye los índices.
• Un administrador realiza mantenimiento que modifica el estado del buzón.

La defensa práctica es sencilla. Congela las tareas de mantenimiento durante la ventana de migración. Pide a los usuarios que no cambien nombres de carpetas, arrastren miles de mensajes al archivo ni limpien Elementos enviados durante la sincronización. Usa además un destino que pueda omitir duplicados en pasadas repetidas en vez de confiar ciegamente en los UID.

Si haces una validación manual, compara los recuentos de carpetas antes y después. No te limites a la bandeja de entrada. Revisa Enviados, Papelera, carpetas de proyectos y cualquier estructura de archivo compartida. Ahí se esconden las avalanchas de duplicados.

4. La asignación de carpetas se complica con rapidez

La asignación de carpetas rompe la migración porque los servidores IMAP no coinciden en delimitadores de jerarquía, nombres de carpetas del sistema ni en el modelo de etiquetas de Gmail. Los usuarios lo perciben como carpetas ausentes o mensajes duplicados. Técnicamente el correo suele estar presente, pero una traducción incorrecta basta para causar pánico y solicitudes de soporte.

Hay dos variantes comunes. Primero, el delimitador: un servidor usa puntos en los nombres y otro usa barras. Segundo, las etiquetas de Gmail: un mensaje puede aparecer bajo varias etiquetas, que IMAP presenta como carpetas.

Así, un buzón de origen bien organizado con etiquetas de Gmail se convierte en un destino inflado con correo repetido en Enviados, carpetas personalizadas y archivos. La propia documentación de diagnóstico de Microsoft menciona expresamente la duplicación cuando hay etiquetas de Gmail y no se excluye la carpeta [Gmail].

# Example folder rules
^INBOX\.Sent$        -> Sent Items
^INBOX\.Trash$       -> Deleted Items
^\[Gmail\]/Trash$   -> Deleted Items
^\[Gmail\]/All Mail$ -> [SKIP]

Si migras desde Gmail, omite [Gmail]/All Mail salvo que tengas una excepción muy concreta. De lo contrario, provocarás duplicados. Para configurar los clientes después del traslado, TrekMail simplifica el trabajo con valores IMAP estándar en Configuración IMAP & SMTP para todos los clientes.

5. Un buzón gigante destruye el presupuesto y el calendario

Los planes suelen basarse en promedios, pero los entornos reales fallan por valores extremos. Un buzón que acumula mensajes desde 2011 puede ser mayor que diez usuarios normales juntos. Si presupuestas el trabajo, eliges el plan de destino y defines el calendario sin medir antes cada buzón, ese único caso arruinará el proyecto.

Es la trampa de reducir licencias. Los sistemas de origen, sobre todo las instalaciones locales antiguas, a menudo toleraban buzones enormes. Muchas plataformas alojadas no. Si la cuota de destino es inferior al tamaño real, la migración no falla amablemente. Suele hacerlo tarde, después de desperdiciar horas de transferencia.

Ejecuta primero un inventario, sin excepciones. Decide después si el modelo de destino permite tamaños desiguales sin obligarte a contratar ampliaciones puntuales costosas.

El almacenamiento compartido es operativamente mejor que el almacenamiento por puesto. En TrekMail, la capacidad se comparte en toda la cuenta en lugar de encerrar cada buzón en el mismo límite pequeño. Esto importa para fundadores, buzones jurídicos y bandejas compartidas de agencias. Para equipos que administran muchos dominios, el alojamiento de correo multidominio solo funciona si el almacenamiento no penaliza los casos extremos.

Si necesitas vigilar el uso después del traslado, TrekMail documenta los límites y el comportamiento de las cuotas en Cuotas de almacenamiento de buzones.

6. Los mensajes dañados son normales: gestiónalos como un operador

Una migración limpia no significa que literalmente todos los elementos sean válidos. Los almacenes antiguos acumulan estructuras MIME dañadas, adjuntos sin contenido e invitaciones de calendario mal formadas. Si cada elemento defectuoso detiene todo, un mensaje roto de 2014 puede bloquear una migración que por lo demás funciona.

Aquí se confunde precisión con competencia. Necesitas un rastro de auditoría, pero no quieres congelar todo el lote porque un adjunto muerto no se puede interpretar.

Define un umbral de elementos defectuosos. Registra cada omisión, revisa el informe y continúa. La mayoría son basura, duplicados de sistemas anteriores o invitaciones antiguas mal formadas que nadie necesita. Si el CSV contiene algo sensible, extrae ese mensaje manualmente. Sigue siendo más rápido que mantener como rehén toda la migración.

En TrekMail, el flujo integrado muestra el progreso y los fallos en el panel. En el lado receptor, si los mensajes no llegan donde esperas, la comprobación más rápida es No recibo correos, que explica la validación de MX y los buzones.

7. LegacyExchangeDN es la trampa exclusiva de Exchange que sobrevive

Este fallo es específico, desagradable y habitual. Los usuarios responden a un hilo interno antiguo en Outlook y reciben un rebote IMCEAEX o de destinatario inexistente aunque el buzón exista y el correo nuevo funcione. La causa no es SMTP, sino la identidad antigua de Exchange guardada en mensajes históricos y direcciones almacenadas.

Exchange conserva direcciones antiguas de estilo X.500 mediante el atributo LegacyExchangeDN. Cuando migras entre entornos Exchange, o sales de uno de forma incorrecta, las respuestas a mensajes antiguos pueden seguir haciendo referencia a esa identidad. Si el buzón de destino no contiene el valor anterior como dirección proxy X500, la respuesta falla.

# Find the old LegacyExchangeDN on source
Get-Mailbox -Identity user@example.com | Format-List LegacyExchangeDN

# Add it as an X500 proxy address on destination
Set-Mailbox -Identity user@example.com -EmailAddresses @{add="X500:/o=OldOrg/ou=Exchange Administrative Group/cn=Recipients/cn=user"}

Esto no afecta a todas las migraciones, porque un traslado IMAP simple no conserva objetos propios de Exchange como una migración completa de Exchange. Pero si los usuarios de Outlook deben responder a hilos internos antiguos sin interrupción, compruébalo antes de aprobar el proyecto. Es uno de esos problemas que solo aparece después de declarar que todo ha terminado.

Un plan de cambio más seguro

Una migración segura es escalonada, medible y deliberadamente aburrida. Ese es el objetivo. Necesitas menos sorpresas, no más automatización porque sí. Los mejores cambios parecen tranquilos porque el trabajo arriesgado se hizo antes de modificar MX, no durante ese momento.

1. Inventaría el tamaño de cada buzón y marca cualquier valor excepcional.
2. Reduce el TTL de MX entre 24 y 48 horas antes del cambio.
3. Crea primero los dominios y buzones de destino.
4. Ejecuta la sincronización IMAP histórica antes del fin de semana.
5. Congela la limpieza de carpetas y los traslados masivos durante la sincronización final.
6. Cambia MX solo cuando el destino esté listo para recibir.
7. Ejecuta una última sincronización incremental.
8. Prueba entrada, salida, recuentos de carpetas y respuestas a hilos antiguos.

Si construyes el destino desde cero, crear correo con tu dominio explica la secuencia, y crear cuentas de correo en lote ayuda cuando aprovisionas más que unos pocos usuarios.

Para TrekMail, el camino es directo: añade el dominio, verifica DNS, crea los buzones, ejecuta la migración IMAP integrada con un plan de pago y cambia el tráfico activo cuando termine la copia pesada. Los precios empiezan en $3.50 al mes. Los planes de pago incluyen una prueba gratuita de 14-day que requiere tarjeta de crédito. Nano es independiente: sin tarjeta, sin prueba y siempre gratuito.

Conclusión: la migración es una tarea operativa, no una copia

La migración funciona cuando respetas las partes incómodas: DNS en caché, fuentes limitadas, comportamiento IMAP desigual, cuotas incompatibles y residuos de Exchange. Si las ignoras, el proyecto parecerá correcto hasta que los usuarios empiecen a perder mensajes. Trátalo como infraestructura activa y se volverá previsible. Ese es el objetivo.

Si quieres un modelo de tarifa fija después del traslado, TrekMail ofrece alojamiento multidominio, almacenamiento compartido, migración IMAP integrada, reenvío de buzones, acceso por API y una configuración basada en estándares sin tarifas por usuario. Empieza en trekmail.net o compara los planes en precios de TrekMail.