Tu herramienta de migración de correo demuestra su valor cuando el trabajo falla a las 2 de la madrugada Esa es la prueba real, no la demostración en condiciones ideales ni la captura de ventas. Si trasladas correo desde Gmail, Microsoft 365 o un servidor cPanel antiguo, los fallos son normales. La pregunta es sencilla: ¿la herramienta reanuda el proceso limpiamente o crea duplicados, omite carpetas y te obliga a explicar el desastre a los usuarios? Si estás planificando un traslado más amplio, empieza por el correo empresarial para que la migración encaje con el sistema que realmente quieres construir.
Esta es la respuesta breve. Una herramienta segura necesita cuatro elementos: detección de duplicados, lógica de reintentos, correspondencia de carpetas y registros por elemento. Si falta uno, una interrupción a mitad del proceso se convierte en un proyecto de limpieza de buzones.
Te despiertas, miras el panel y ves un 68% completado. Un buzón aparece como fallido. El usuario inicia sesión y falta la mitad de su correo enviado. No es mala suerte, sino un problema de la herramienta.
Por eso los buenos administradores se fijan menos en la barra de progreso y más en el seguimiento del estado. Si la herramienta no puede demostrar qué copió, qué omitió y dónde se detuvo, no tienes una migración, sino una apuesta.
Si buscas el contexto del protocolo, la descripción general de la migración IMAP de TrekMail explica qué trasladan las importaciones IMAP y qué dejan fuera. Si utilizas la línea de comandos directamente en lugar de un flujo alojado, conviene leer también esta guía sobre imapsync antes de tocar producción.
Qué debe hacer una herramienta de migración cuando falla una ejecución
Una herramienta de migración de correo debe reanudar el trabajo tras una caída de red, un límite de tráfico o un mensaje defectuoso sin duplicar correo ni omitir carpetas. El requisito principal es la idempotencia: al ejecutar de nuevo el mismo trabajo, el destino sigue siendo correcto. Todo lo demás es secundario.
Muchas herramientas anuncian velocidad. La velocidad ayuda. Una reanudación segura es lo que te salva.
Cuando un trabajo falla, la herramienta debe hacer todo esto de forma predeterminada:
- Volver a conectarse sin empezar desde cero.
- Omitir los mensajes que ya existen en el destino.
- Registrar el elemento o la carpeta exactos que han fallado.
- Detenerse y volver a intentarlo cuando el servidor de origen pida reducir el ritmo.
- Mantener intacta la estructura de carpetas entre distintos estilos de espacio de nombres IMAP.
Si el producto no puede realizar esas cinco tareas, no le confíes una transición real.
Los fallos que detienen casi todas las migraciones grandes
La mayoría de los fallos son comportamientos normales de IMAP bajo carga. Los proveedores limitan a los clientes, los tokens caducan, los servidores reinician conexiones y los mensajes mal formados bloquean los analizadores. Una buena herramienta trata estas situaciones como condiciones de trabajo previsibles, no como excepciones infrecuentes.
Veamos los detalles.
Los límites de tráfico son el primer obstáculo. Gmail, Microsoft 365 y los servidores de alojamiento compartido antiguos se protegen. Si los presionas demasiado, reducen la velocidad o interrumpen el acceso. Una herramienta deficiente sigue insistiendo y agrava el bloqueo.
Los elementos defectuosos vienen después. Una sola cabecera MIME mal formada o un archivo adjunto demasiado grande puede bloquear una y otra vez un importador poco robusto en el mismo mensaje. Si la herramienta no puede aislar ese elemento y continuar, toda la ejecución se detiene.
La caducidad de la autenticación es otra causa habitual. Microsoft ha desactivado la autenticación básica en los entornos de Exchange Online, y los sistemas de autenticación modernos también exigen renovar los tokens durante trabajos largos. Si el motor no gestiona correctamente esa renovación, la ejecución termina a medias.
| Tipo de fallo | Qué suele significar | Qué debe hacer la herramienta |
|---|---|---|
| HTTP 429 / 503 | El proveedor limita el tráfico o está ocupado | Reducir el ritmo, esperar, reintentar y conservar el estado |
| Tiempo de espera de la conexión | Se ha interrumpido la ruta de red | Volver a conectar y verificar el último elemento copiado |
| IMAP NO | Problema de cuota, permisos o buzón | Registrar el contexto de la carpeta y continuar con seguridad |
| Comando BAD o error de análisis | Elemento mal formado o problema del protocolo | Omitir el elemento problemático y registrarlo |
| Autenticación caducada | Problema con el token o la contraseña de aplicación | Renovar o generar un fallo visible con un motivo claro |
Microsoft documenta el cierre de la autenticación básica para Exchange Online en su guía oficial sobre la retirada de la autenticación básica. En cuanto a IMAP, RFC 3501 define los UID de los buzones y UIDVALIDITY en la especificación base de IMAP4rev1. Estas dos referencias explican por qué las antiguas suposiciones fallan en 2025-2026.
La reanudación segura depende de la idempotencia, no de la esperanza
La idempotencia significa que la herramienta puede volver a ejecutarse sobre el mismo buzón y aun así producir una sola copia correcta de cada mensaje. Sin ella, cada nuevo intento puede generar duplicados, mensajes perdidos o ambos problemas. Es la característica de diseño más importante de cualquier motor de migración.
Aquí es donde fracasan las herramientas baratas.
Una herramienta ingenua solo registra el último UID visto y supone que el buzón de origen nunca cambia. Los servidores reales no se comportan con tanta limpieza. Los buzones se compactan, se reparan y se restauran. UIDVALIDITY cambia. Cuando esto sucede, la herramienta debe abandonar la reanudación rápida basada en UID y aplicar una comprobación de duplicados más lenta, como la comparación por Message-ID.
Esa es la diferencia entre un retraso y un desastre.
imapsync \
--host1 imap.oldhost.com --user1 alice@example.com --password1 'source-pass' \
--host2 imap.trekmail.net --user2 alice@example.com --password2 'dest-pass' \
--ssl1 --ssl2 \
--syncinternaldates \
--useheader 'Message-Id' \
--skipsize \
--skipcrossduplicates \
--errorsmax 50Este enfoque seguro para las diferencias explica por qué los administradores incluyen una segunda pasada en el procedimiento. La primera traslada el grueso del correo. La segunda recoge los elementos que llegaron tarde y comprueba que no se estén acumulando duplicados.
Si migras específicamente desde Gmail, la guía de migración desde Gmail de TrekMail cubre las credenciales, incluida la necesidad de usar una contraseña de aplicación cuando Google no acepta la contraseña normal de la cuenta para acceder mediante IMAP.
La pérdida silenciosa de datos se oculta en la correspondencia de carpetas
La correspondencia indica a la herramienta cómo deben aparecer en el destino los nombres de las carpetas de origen. Sin ella, el correo puede importarse correctamente, pero acabar en el lugar equivocado. Es un fallo silencioso porque los datos existen, aunque el usuario crea que han desaparecido.
Esto ocurre constantemente.
Un servidor usa puntos y otro utiliza barras. Uno llama al correo enviado Sent Messages y otro espera Sent Items. Una herramienta deficiente copia literalmente los nombres y da por terminada la ejecución. El usuario inicia sesión y encuentra un montón de carpetas desordenadas en el nivel raíz.
Estas son las correspondencias más importantes:
^Sent Messages$ -> Sent Items
^Deleted Messages$ -> Trash
^Draft Messages$ -> Drafts
INBOX\.(.+) -> INBOX/$1La última línea representa la trampa del espacio de nombres. Convierte árboles de carpetas separados por puntos, habituales en Dovecot o cPanel, en estructuras separadas por barras que los clientes IMAP y las plataformas alojadas suelen esperar.
La correspondencia también importa al ampliar la configuración de buzones entre muchos dominios. Es el mismo problema operativo que el aprovisionamiento: la coherencia evita la limpieza. Por eso crear cuentas de correo de forma masiva y el alojamiento de correo para varios dominios cobran relevancia al migrar más que unos pocos usuarios.
Los registros determinan si puedes resolver el último 2%
Una herramienta útil debe generar registros por elemento, no solo una marca verde o una X roja. Necesitas saber qué mensaje falló, en qué carpeta estaba y por qué. De lo contrario, no puedes decidir si repetirlo, ignorarlo o escalar el problema.
«Completado con errores» no aporta nada útil. Necesitas una lista.
El registro mínimo debe incluir el asunto, la carpeta de origen, la fecha del mensaje, su tamaño y el motivo del fallo. Mejor aún si permite exportar un CSV. Así podrás filtrar por tipo de error y tratar cada clase de problema de la forma adecuada.
Este es el flujo operativo que sí funciona:
- Ejecuta la primera pasada de migración.
- Exporta o revisa los registros de elementos omitidos.
- Agrupa los fallos por causa: autenticación, tiempo de espera, tamaño excesivo, elemento mal formado o cuota de destino.
- Repite el trabajo con la exclusión de duplicados activada.
- Gestiona manualmente solo las excepciones reales.
Este proceso es aburrido. Perfecto. Durante una migración, lo aburrido es justo lo que necesitas.
Antes del cambio final, verifica el dominio y la configuración de buzones en el destino. La guía de TrekMail para añadir un dominio explica la parte de DNS para que no traslades el correo correctamente y después interrumpas la entrega al cambiar el MX.
Método antiguo y nuevo: scripts, SaaS por usuario y TrekMail
El método antiguo combina un montón de scripts, tarifas de migración por usuario y supervisión manual. El nuevo integra la herramienta en la plataforma de correo, aplica el precio al plan e incorpora los reintentos y la detección de duplicados al flujo de trabajo.
Método antiguo: ejecutar imapsync por tu cuenta, gestionar contraseñas de aplicación, ajustar los reintentos, asignar carpetas manualmente, revisar los registros a mano y pagar después a otro proveedor por cada buzón.
Método nuevo: usar la migración IMAP del servidor de TrekMail dentro de la misma plataforma que alojará los buzones de destino. Introduces los datos IMAP antiguos, eliges el buzón de TrekMail y ejecutas la importación desde el panel. La documentación presenta la exclusión de duplicados como una opción estándar, y el estado aparece como en cola, procesando, completado o fallido.
Es importante porque la migración no debería convertirse en una fuente de beneficios aparte, sino formar parte de la incorporación.
TrekMail se basa en alojamiento de correo multidominio con precio fijo. Los planes comienzan en $3.50 al mes. El producto incluye dominios personalizados, buzones IMAP, direcciones comodín, SMTP propio o incluido según el plan, reenvío de buzones, una herramienta de migración y acceso por API en los niveles superiores. Existe un plan Nano por $0, y los planes de pago se pueden probar gratis durante 14 días. El plan gratuito no exige tarjeta. La prueba sí.
Para los equipos pequeños, esto permite trasladar correo sin comprar antes un complemento de migración por usuario. Para las agencias, permite integrar la migración en el mismo modelo de control que ya necesitan para la propiedad de los buzones, la incorporación de clientes y el margen recurrente.
Si la economía importa tanto como las herramientas, compara los planes directamente en precios de TrekMail.
Cómo elegir una herramienta de migración sin arrepentirse
Elige la herramienta según su recuperación ante fallos, gestión de duplicados, correspondencia de carpetas y registros. Ignora los paneles meramente estéticos. Si no resiste límites de tráfico, mensajes problemáticos y reintentos, te costará más tiempo del que ahorra.
Aplica esta lista antes de decidir:
- ¿Puede la herramienta omitir duplicados al repetir el proceso?
- ¿Puede continuar cuando falla un solo mensaje?
- ¿Puede asignar nombres de carpetas y delimitadores del espacio de nombres?
- ¿Puede mostrar errores por elemento en lugar de limitarse a un resumen?
- ¿Puede gestionar la autenticación moderna y sesiones largas?
- ¿Puede migrar mediante IMAP sin imponer después un modelo de facturación separado por usuario?
Si alguna respuesta es negativa, sigue buscando.
La mejor herramienta no es la que tiene la interfaz más atractiva. Es la que asume que habrá fallos y está diseñada para recuperarse sin dañar el buzón. Ese es el estándar. Todo lo que quede por debajo es una interrupción a punto de ocurrir.