Software de migración de correo: lo que no puede garantizar

El software de migración de correo se vende como una red de seguridad. Compras la licencia, introduces dos contraseñas, esperas la marca verde y listo.

Las migraciones reales no funcionan así. Tanto si trasladas 20 buzones como 500, el software opera entre dos servidores, dos sistemas de autenticación, la propagación de DNS, las particularidades de los buzones y un comportamiento de los usuarios que cambia durante el proyecto. Si lo tratas como una copiadora mágica, perderás mensajes sin saber por qué.

La solución es sencilla: deja de comprar promesas y aplica un proceso. Esta guía explica qué controla realmente el software, qué queda fuera de su alcance y cómo verificar una migración antes de desconectar el proveedor antiguo. Si primero necesitas decidir la plataforma, empieza por el correo empresarial.

El enfoque de TrekMail es práctico. La plataforma incluye una herramienta integrada de migración IMAP en los planes de pago, almacenamiento compartido, gestión multidominio y ninguna tarifa por usuario. Puedes consultar la descripción general de la migración IMAP, comparar los planes en precios de TrekMail y afrontar el traslado con pleno conocimiento.

¿Qué es realmente el software de migración de correo?

Es una capa de automatización que inicia sesión en un servidor de correo, lee los datos de los mensajes mediante IMAP y los escribe en otro buzón. Puede acelerar el trabajo repetitivo y reducir errores del administrador, pero no puede eludir los límites del servidor, las reglas del protocolo ni los datos defectuosos del origen.

Al eliminar el discurso comercial, la mayoría de estos programas realiza unas pocas tareas rutinarias pero esenciales:

• Iniciar sesión en el buzón de origen
• Enumerar carpetas y mensajes
• Obtener el contenido y los indicadores de los mensajes
• Añadir esos mensajes al buzón de destino
• Volver a intentarlo cuando el origen o el destino imponen límites
• Crear registros que permitan demostrar qué ocurrió

Es útil, pero no sobrenatural.

El propio protocolo IMAP deja claro su alcance. Sirve para acceder a buzones de un servidor y manipularlos, no para reproducir cada elemento del entorno anterior de un usuario. Esta diferencia importa porque muchos compradores esperan que el software traslade calendarios, contactos, firmas, reglas de Outlook, permisos compartidos y perfiles de escritorio. IMAP no hace nada de eso. El estándar básico abarca buzones y mensajes, nada más. Consulta RFC 3501.

Qué puede garantizar el software de migración

Un buen software puede garantizar el proceso que ejecuta: intentos de conexión, reintentos, correspondencia de carpetas, tratamiento de duplicados y registros. No puede garantizar que el servidor de origen se comporte correctamente, que el destino acepte cada elemento ni que el calendario de transición sea razonable.

Este es el ámbito bajo su control. Si merece la pena pagar por una herramienta, debe garantizar estos elementos.

1. Un registro de auditoría útil

El producto real no es la barra de progreso, sino el registro.

Si falla un elemento, necesitas saber en qué buzón y carpeta estaba, qué mensaje era y qué error se recibió. Sin esos datos, la frase «migración completada» no significa nada. Un software serio debe mostrar el estado de cada buzón, los motivos de los fallos y suficiente detalle para repetir solo lo necesario.

Resultado deficiente: «Completado con advertencias».

Resultado útil: «Se omitieron 4 mensajes de Sales/Inbox debido a MIME mal formado o al rechazo del destino».

2. Lógica de reintentos cuando los servidores imponen límites

Los servidores limitan el tráfico. Es normal. Un buen software reduce el ritmo, espera y reanuda el trabajo, en vez de insistir y agravar el bloqueo.

# Example: careful IMAP copy with duplicate protection
imapsync \
  --host1 imap.source.example \
  --user1 old@example.com \
  --password1 'SOURCE_APP_PASSWORD' \
  --host2 imap.trekmail.net \
  --user2 new@example.com \
  --password2 'TREKMAIL_PASSWORD' \
  --ssl1 --ssl2 \
  --skipsize --useuid \
  --nofoldersizes --subscribe

El comando no es lo importante, sino su comportamiento: reducir el ritmo, conservar los UID cuando sea posible y evitar importaciones duplicadas.

3. Reglas de correspondencia de carpetas

El software debe permitir traducir las carpetas con precisión. Así se evita el clásico desastre de encontrar vacía la carpeta Enviados después del cambio.

Cada sistema denomina las carpetas del sistema de forma distinta:

Si trasladas el correo a TrekMail, consulta primero la documentación, en especial migrar desde Gmail y migrar desde cPanel. Así evitarás repetir trabajo después.

Qué no puede garantizar el software de migración

Ningún software puede garantizar datos de origen limpios, una finalización instantánea, cero interrupciones ni una reproducción completa de elementos ajenos al correo IMAP. Esas promesas se desmoronan en cuanto aparecen límites de tráfico, cambios de autenticación, retrasos de DNS o mensajes mal formados.

Aquí es donde las páginas comerciales se alejan de la realidad.

Cero interrupciones

No, al menos no en sentido literal.

Puedes reducir las molestias visibles preparando previamente el correo, bajando el TTL del MX y realizando una última pasada incremental después de cambiar el DNS. Sin embargo, durante la propagación algunos mensajes aún pueden llegar al proveedor antiguo mientras otros remitentes usan el nuevo. Ese periodo dividido es normal. El software no controla las cachés de los resolutores.

100% de fidelidad de los datos

Tampoco.

Si el origen contiene MIME mal formado, cabeceras rotas, contenido ausente o codificaciones de carpetas extrañas de un servidor antiguo, el destino puede rechazar el mensaje. El software puede informar del fallo, pero no obligar al destino a aceptar datos inválidos.

Se migra todo

Solo si «todo» significa las carpetas y los mensajes que IMAP expone.

El software no traslada mágicamente:

• Calendarios
• Contactos
• Firmas del programa de escritorio
• Reglas del cliente
• Historial de autocompletado
• Permisos de buzón ajenos al proceso de copia del correo

Si un proveedor oculta esta diferencia, guarda la cartera.

Los métodos de autenticación antiguos seguirán funcionando

Ya no. En 2025 y 2026, los principales proveedores han ido eliminando los procesos basados únicamente en contraseñas. La guía de Microsoft es clara: Exchange Online ha retirado la autenticación básica de los protocolos principales, y OAuth marca el camino para los patrones de acceso IMAP, POP y SMTP que siguen en uso. Consulta Microsoft Learn.

En otras palabras, si tu software presupone que un nombre de usuario y una contraseña bastan para cualquier origen, se ha quedado atrás.

Dónde fallan realmente las migraciones

El punto débil no suele ser el motor de copia, sino la disciplina operativa que lo rodea: mala preparación de la autenticación, correspondencia de carpetas incorrecta, errores al programar el DNS o administradores que modifican el buzón de origen durante el proceso.

Esta es la parte que los operadores aprenden por las malas.

Barreras por límites de tráfico

Los sistemas de origen y destino limitan la velocidad de lectura y escritura. Si presionas demasiado, aparecerán errores temporales, trabajos atascados o bloqueos de cuentas. Por eso los traslados de buzones grandes suelen necesitar periodos de preparación, no una única descarga masiva nocturna.

Mensajes dañados en el origen

Los servidores antiguos acumulan problemas, sobre todo los equipos cPanel y los alojamientos compartidos con muchos años.

Caso habitual: la cabecera existe, falla la obtención del contenido y el destino rechaza la incorporación porque los datos están incompletos.

No es un error del software, sino información defectuosa del origen que queda expuesta durante el traslado.

Desorden de UID e importaciones duplicadas

La mayoría de los programas registra el progreso mediante el estado del buzón y los identificadores de mensaje. Si alguien vuelve a indexar, repara o modifica el origen durante la migración, la herramienta puede perder su posición y copiar el correo dos veces. Por eso importa controlar los cambios. Inmoviliza el origen. No intentes «limpiarlo» mientras se ejecuta el trabajo.

Diferencias de borrado durante la sincronización incremental

Muchas herramientas son aditivas por diseño. Es más seguro que borrar datos de forma agresiva en el destino. Sin embargo, un usuario puede eliminar un mensaje del servidor antiguo después de la primera pasada y seguir viéndolo en el nuevo tras el cambio. Los usuarios lo llaman error. Normalmente es una política.

Errores de calendario en DNS

Si mantienes alto el TTL del MX y cambias demasiado pronto, algunos remitentes seguirán entregando mensajes al proveedor antiguo mucho después de que el equipo crea terminada la migración. Si apagas pronto el servidor anterior, esos mensajes rebotan. Si lo mantienes activo, pero nunca haces una pasada final, se quedan allí abandonados.

Para preparar DNS, la documentación de TrekMail sobre registros DNS necesarios y comprobar el estado de DNS ofrece la lista de control adecuada.

Cómo evaluar el software antes de comprarlo

No evalúes el software por su promesa de «cero interrupciones». Júzgalo por los registros, la compatibilidad de autenticación, el tratamiento de duplicados, la correspondencia de carpetas y lo bien que encaja en tu proceso de transición.

Aplica esta lista:

1. ¿Admite autenticación moderna o contraseñas de aplicación para los orígenes que realmente utilizas?
2. ¿Puede asignar carpetas sin limpieza manual en cada buzón?
3. ¿Omite los duplicados con seguridad en las nuevas ejecuciones?
4. ¿Puedes exportar registros por buzón y por fallo?
5. ¿Puedes preparar migraciones antes del cambio de MX y ejecutar una última pasada después?
6. ¿El precio penaliza a cada usuario o permite migrar en bloque sin destruir el margen?

Esto es especialmente importante para agencias y MSP. Si ya gestionas muchos dominios de clientes, lee sobre alojamiento de correo multidominio y creación masiva de cuentas de correo. Son el mismo problema operativo con distinto aspecto.

Un protocolo práctico de verificación que supera las promesas

La única prueba honesta del éxito es verificar después de la copia: recuentos de elementos, revisión de carpetas, sincronización incremental y confirmación de DNS. Si no verificas, estás confiando en un panel y no en el propio correo.

Este es el procedimiento.

1. Cuenta elementos, no gigabytes

El tamaño del buzón engaña. La sobrecarga de MIME, la codificación de adjuntos y la compresión del servidor distorsionan las comparaciones.

Cuenta los mensajes por carpeta. Si la Bandeja de entrada difiere en 3 elementos de un total de 4,000, tienes algo que investigar. Si el tamaño difiere en 600 MB, puede no significar nada.

2. Comprueba Enviados antes de entregar

Envía un mensaje de prueba desde el nuevo buzón y revisa la carpeta Enviados. Si aparece junto al historial migrado, probablemente la asignación es correcta. Si llega a Sent Items y el historial antiguo queda aislado en Sent Messages, corrígelo antes de que el usuario inicie sesión.

Es la misma clase de problema descrita en imapsync: el software copia lo que ve; los operadores deciden dónde debe estar.

3. Cambia el MX, espera y ejecuta una última pasada

No cambies el DNS para retirar inmediatamente el origen.

example.com.   300   IN   MX   10 inbound.trekmail.net.
example.com.   300   IN   TXT  "v=spf1 include:spf.trekmail.net -all"

Reduce el TTL antes del traslado. Cambia el MX. Espera a que termine la propagación. Después ejecuta otra pasada incremental para recoger los mensajes rezagados que aún llegaron al proveedor antiguo.

4. Mantén el origen en modo de solo lectura durante la fase final

Si los usuarios siguen eliminando, moviendo y archivando mensajes en la plataforma anterior mientras intentas cerrar la migración, los resultados serán más difíciles de explicar y defender.

Cuándo TrekMail resulta más conveniente que un software separado

Si te trasladas a TrekMail, la ventaja práctica no se limita al motor de copia. También se eliminan elementos adicionales: no hay tarifa de alojamiento por usuario ni producto separado para migrar, y se incluyen control multidominio, almacenamiento compartido y migración IMAP en los planes de pago.

Esto no convierte IMAP en un milagro. La migración de TrekMail sigue limitada a IMAP y no traslada calendarios ni contactos. Sin embargo, para copiar el correo se ocupa de lo importante: mover mensajes y carpetas al nuevo buzón sin imponerte otra factura de proveedor.

El plan Starter comienza en $3.50/mo. Los planes de pago ofrecen una prueba gratuita de 14-day, y el plan Nano es siempre gratuito, sin periodo de prueba ni tarjeta. Si quieres probar primero el proceso, puedes crear el buzón de destino, preparar DNS y ejecutar una importación por etapas antes del cambio. Consulta crear un buzón si configuras el destino desde cero.

Conclusión: el software ayuda, pero el operador cierra la brecha

Merece la pena usar software de migración. No conviene copiar buzones a mano ni improvisar con scripts aleatorios cuando el proyecto es importante. Sin embargo, el software garantiza la ejecución, no el éxito. El éxito depende de la preparación, la compatibilidad de autenticación, un ritmo razonable, una correspondencia limpia, disciplina en DNS y la verificación final.

Ese es el enfoque correcto. Compra software por su automatización y sus registros, no por una falsa certeza.

Si buscas el camino más sencillo, TrekMail combina alojamiento y migración IMAP en una plataforma, con planes de precio fijo, almacenamiento compartido, migración integrada y sin una escalada de tarifas por usuario. Consulta la documentación, comprueba los precios y empieza en trekmail.net.