La migración IMAP puede descontrolar un proyecto de correo rápidamente. Una asignación de carpetas incorrecta, una caché DNS obsoleta o una particularidad de Gmail puede provocar una interrupción de fin de semana. Si estás preparando un traslado, lee primero esta guía y ten a mano este manual de imapsync para operadores. El objetivo es sencillo: mover el correo sin duplicados ni pérdidas silenciosas y evitar costes por usuario que no sean necesarios para tu proyecto.
Parece evidente, pero no lo es. El correo electrónico no es un archivo zip. Es un sistema activo con estados, clientes, DNS, límites de velocidad y usuarios que siguen enviando mensajes mientras intentas trasladarlo todo. Por eso una migración IMAP rigurosa comienza por los límites del protocolo y no por las promesas de un proveedor.
La solución es separar la velocidad de la presión del cambio. Método anterior: comprar licencias con antelación, apresurar el traslado y esperar que el fin de semana alcance. Método nuevo: preparar primero el destino, migrar en varias pasadas y usar almacenamiento compartido para que un buzón enorme no comprometa el presupuesto. TrekMail ofrece alojamiento multidominio con tarifa fija, almacenamiento compartido e importación integrada del lado del servidor. Comprueba que las cuotas y funciones del plan elegido permiten preparar el entorno que necesitas.
Por qué fallan las migraciones IMAP en la práctica
Una migración IMAP puede fallar al copiar el estado de los mensajes entre servidores que no representan las carpetas, los identificadores y las etiquetas del mismo modo. El protocolo permite mover correo, pero no fue diseñado como un sistema perfecto de réplica masiva. A gran escala, las diferencias pueden producir duplicados, jerarquías de carpetas aplanadas, limitaciones de velocidad y mensajes nuevos que permanecen en el origen.
La primera trampa es la lógica de UID. IMAP identifica los mensajes dentro de un buzón mediante los UID junto con UIDVALIDITY. Si cambia UIDVALIDITY, el cliente debe descartar las correspondencias de UID anteriores, según RFC 9051. Reconstruir o restaurar un buzón puede crear una nueva generación de UID; cambiar su nombre no necesariamente lo hace. Si la herramienta pierde sus correspondencias, puede empezar a copiar mensajes de nuevo.
La segunda trampa es la diferencia entre espacios de nombres de carpetas. Un host puede interpretar `INBOX.Sent` como una carpeta anidada, mientras que otro espera `INBOX/Sent`. Gmail añade otra capa al mostrar etiquetas como carpetas mediante IMAP. Si no examinas las carpetas y su asignación antes de la ejecución completa, los usuarios pueden creer que parte del archivo de la empresa ha desaparecido.
La tercera trampa es el modelo de etiquetas de Gmail. Un mensaje puede aparecer bajo varias etiquetas, pero un destino IMAP normal almacena carpetas, no etiquetas. Según la asignación, un único mensaje lógico puede convertirse en varias copias. Sin embargo, excluir All Mail de forma general también puede omitir mensajes archivados que no aparecen bajo ninguna otra etiqueta seleccionada. Identifica primero qué combinación de carpetas cubre todo el correo que quieres conservar.
Preparación: examina el desorden antes de trasladarlo
Una migración IMAP segura comienza por el inventario, no por las credenciales. Necesitas cantidades y tamaños de buzones, cuentas de servicio atípicas, reglas de reenvío antiguas y una lista breve de usuarios con necesidades críticas. Omitir el análisis no ahorra tiempo, solo traslada la incertidumbre al día del cambio.
Empieza por los buzones gigantes: fundadores que apenas borran mensajes, buzones de finanzas con años de archivos PDF y bandejas de soporte convertidas en archivos históricos. Estos buzones marcan el calendario y pueden revelar inconvenientes de los precios por usuario. Un solo buzón de 60 GB puede exigir un nivel de licencia más costoso en ciertas plataformas. El almacenamiento compartido de TrekMail puede facilitar la distribución, siempre que el plan tenga suficiente capacidad total libre y cuotas de buzón compatibles.
Después localiza los datos ocultos: direcciones compartidas, cuentas de escáneres, bandejas de alertas y sustitutos antiguos de listas de distribución que en realidad tienen accesos y contraseñas propios. Si olvidas uno, el correo importante puede dejar de llegar sin un fallo evidente. Registra quién es responsable y qué acceso necesita cada cuenta.
Por último, acuerda cómo tratar los elementos defectuosos antes de la primera sincronización. Las partes MIME dañadas, cabeceras rotas y adjuntos que superan el límite son habituales en almacenes antiguos. Si la herramienta se detiene ante el primer objeto defectuoso, la migración puede quedar bloqueada por un mensaje de 2009. Permite continuar solo según la política aprobada, registra los elementos omitidos y revisa el informe para recuperarlos o documentar excepciones expresamente autorizadas.
| Elemento que debes identificar | Por qué importa | Qué registrar |
|---|---|---|
| Tamaño del buzón | Determina el calendario y el orden de preparación | Total de GB y cantidad de elementos |
| Buzones gigantes | Revelan riesgos de cuota y limitación | Todo lo que supere 15-20 GB |
| Cuentas de servicio | Pueden fallar silenciosamente después del cambio | Propietario, aplicación y método de autenticación |
| Carpetas y etiquetas compartidas | Provocan errores de asignación y duplicados | Nombres de carpetas, separadores y etiquetas de Gmail |
| Elementos defectuosos | Pueden detener todo el trabajo | Cantidad, tipo y política de omisión |
Cambio total frente a preparación previa
Las estrategias básicas son mover todo durante el cambio o preparar primero el correo antiguo y terminar con una pasada incremental. Un cambio total puede servir para entornos pequeños; los proyectos más grandes suelen beneficiarse de la preparación previa.
El cambio total parece ordenado. Modificas los MX el viernes, migras todo el fin de semana y llegas el lunes esperando que los contadores coincidan. Puede funcionar con equipos pequeños y poco correo, pero el plazo puede resultar insuficiente si el origen limita las descargas o un buzón tarda más de lo previsto.
La preparación previa reduce la presión. Copia, por ejemplo, lo anterior a 30 días mientras los usuarios permanecen en el sistema antiguo. Reduce el TTL del DNS con antelación, modifica los MX y ejecuta una sincronización incremental del correo reciente y recién entregado. Así distribuyes un riesgo enorme entre tres trabajos más manejables.
Aquí importa el modelo de precios de TrekMail. En Google Workspace o Microsoft 365, el solapamiento puede requerir licencias tanto en el origen como en el destino. TrekMail permite aprovisionar el destino antes sin licenciar cada buzón por separado dentro de los límites contratados. La página de precios presenta planes de pago desde $3.50 al mes con facturación anual; revisa las condiciones actuales. La prueba de 14 días depende de los requisitos y condiciones vigentes. Nano es un plan gratuito independiente sujeto a sus condiciones actuales y por ahora no requiere tarjeta; para cualquier envío, incluidas las respuestas, necesita un servicio SMTP propio.
| Estrategia | Ideal para | Riesgo principal | Conclusión |
|---|---|---|---|
| Cambio total | Menos de 10 usuarios y poco volumen de datos | Exceder el fin de semana | Más adecuado para tareas pequeñas |
| Preparación previa | Equipos, pymes, agencias y MSP | Exige disciplina de planificación | En general, la opción preferible |
Procedimiento seguro de migración IMAP
Un procedimiento repetible de migración IMAP consta de cinco partes: crear el destino, probar la estructura de carpetas, copiar el correo antiguo, cambiar el DNS y ejecutar una pasada incremental. Cada paso ayuda a reducir el impacto posible antes de avanzar al siguiente.
- Crea primero los dominios y buzones de destino. La documentación de TrekMail para añadir un dominio y la configuración IMAP explica los valores de DNS y conexión. No improvises el destino MX. La documentación indica `mail.trekmail.net` con prioridad `10`; utiliza los valores actuales que se muestran para tu dominio.
- Ejecuta una pasada de estructura. Crea las carpetas antes de copiar grandes volúmenes. Así aparecen los problemas de puntos frente a barras cuando todavía es fácil corregirlos.
- Ejecuta la pasada masiva para el correo antiguo. Antes de excluir `[Gmail]/All Mail` y Trash en Gmail, revisa las etiquetas y su asignación. Excluye solo las carpetas cuyo contenido deseado esté cubierto por otras o que hayas decidido no trasladar.
- Un TTL de MX de 300 segundos y una antelación de al menos 24 horas son un ejemplo de planificación, no una garantía de propagación. Ten en cuenta el TTL mayor que se aplicaba antes y las cachés de respuestas positivas y negativas; supervisa ambos sistemas durante el cambio.
- Modifica los MX, comprueba las respuestas DNS y ejecuta pasadas incrementales con la omisión de duplicados activada. El flujo de importación de TrekMail permite omitir duplicados detectados en ejecuciones repetidas. Verifica también los resultados: la asignación de carpetas y la identificación de mensajes no siempre evitan todas las copias repetidas.
Para verificar el DNS, usa comandos y no suposiciones:
dig MX example.com +short
dig TXT example.com +short
dig TXT _dmarc.example.com +shortSi haces una ejecución manual con imapsync, mantenla sencilla. El ejemplo siguiente no sirve para todos los orígenes: revisa las exclusiones de Gmail y la autenticación necesaria. Las contraseñas son marcadores de ejemplo; utiliza archivos de credenciales protegidos o tokens compatibles para evitar exponer secretos en el historial del shell o en la lista de procesos.
imapsync \
--host1 old.mailhost.tld --user1 user@example.com --password1 'SOURCE_PASS' \
--host2 imap.trekmail.net --user2 user@example.com --password2 'DEST_PASS' \
--ssl1 --ssl2 \
--exclude '\[Gmail\]/All Mail|\[Gmail\]/Trash' \
--syncinternaldates \
--useheader 'Message-Id' \
--skipsizeUn ejemplo de registro para el cambio de DNS:
example.com. 300 IN MX 10 mail.trekmail.net.Gmail, Microsoft 365 y otros casos especiales
No todos los orígenes de una migración IMAP se comportan igual. Gmail presenta posibles duplicados por etiquetas y límites de ancho de banda. En Microsoft 365, Exchange Online ha retirado Basic Auth para IMAP, por lo que hay que preparar la autenticación correspondiente. Las instalaciones antiguas de Exchange pueden fallar por incompatibilidades de TLS. Trata cada tipo de origen según su propio perfil de riesgo.
Google publica un límite diario de descarga IMAP de 2500 MB por cuenta para los entornos Workspace; consulta las indicaciones actuales antes de comenzar. Al alcanzar el límite, la migración puede ralentizarse o fallar. No programes una cuenta de Gmail de 20 GB como una copia rápida y continua. Regula el ritmo, prepara varias pasadas y reserva tiempo para reintentos; según el origen, pueden hacer falta varios días en lugar de unas horas.
En Microsoft 365, un nombre de usuario y una contraseña no bastan para IMAP en Exchange Online. Hace falta una herramienta compatible con OAuth y los permisos apropiados. El ejemplo con contraseñas de esta guía no cubre ese caso. Comprueba la herramienta y la configuración de las cuentas antes del primer lote, y prepara un procedimiento alternativo adecuado.
Ejemplo conceptual: un buzón de Gmail de 12 GB con Inbox, Project, Important y All Mail visibles mediante IMAP no se comporta como un árbol ordenado de carpetas de 12 GB. Es un grafo de etiquetas presentado como carpetas, que puede producir almacenamiento duplicado si la asignación no es adecuada.
Si el proyecto incluye incorporar muchos usuarios después del traslado, coordina esa tarea con la creación de buzones y el control de acceso antes del cambio. TrekMail publica procedimientos para crear cuentas de correo de forma masiva y gestionar el correo de clientes. Utilízalos y revisa los posibles errores de aprovisionamiento, no solo el motor de copia.
Verificación: cuenta elementos, no gigabytes
La cantidad de elementos por carpeta y buzón es un indicador importante. Los proveedores calculan de manera distinta la sobrecarga MIME, la compresión y la deduplicación, por lo que los gigabytes no prueban por sí solos el éxito. Tampoco basta con que coincidan los contadores: revisa la asignación de carpetas, los identificadores de mensajes y muestras con cabeceras, fechas, indicadores de estado y contenido.
Después de cada pasada, compara las cantidades del origen y el destino. Si el origen indica 14,200 elementos y el destino 14,195, cinco mensajes dañados registrados pueden explicar la diferencia, pero no demuestran que el traslado esté completo. Intenta recuperarlos u obtén aprobación explícita para las excepciones y comprueba también el resto del correo. Si el destino indica 10,000, detente e investiga. Un gráfico de almacenamiento parecido no basta.
Supervisa el servidor antiguo después de cambiar los MX; al menos 48 horas pueden ser un punto de partida para el plan, pero no siempre bastan. Los dispositivos con valores fijos, las impresoras, los CRM y los formularios antiguos pueden seguir depositando correo allí. Localiza esos accesos y repite las pasadas incrementales hasta verificar las rutas de entrega y recoger todo el correo nuevo que deba conservarse.
Si el traslado forma parte de una reorganización tecnológica más amplia, piensa también en el siguiente modelo operativo: dónde reside el correo y cuántos dominios, buzones y clientes necesitas controlar. TrekMail puede encajar en la gestión centralizada de ese conjunto; compara las necesidades concretas y los planes con las grandes suites. Es el mismo tema que aborda el alojamiento de correo multidominio y el razonamiento económico de correo empresarial.
Conclusión: reduce el riesgo, no el ritmo del proyecto
La migración IMAP recompensa la paciencia, el orden y la verificación. No ganas por ir más rápido de lo que el origen tolera. Reduce las incógnitas antes del cambio, examina las carpetas antes de excluirlas, contempla las cachés DNS y comprueba mensajes y correspondencias además de las cantidades.
TrekMail reúne control multidominio, almacenamiento compartido, importación del lado del servidor y acceso IMAP estándar. Si los límites del plan y el flujo de trabajo se ajustan al proyecto, puedes migrar pronto el correo antiguo y revisar las pasadas incrementales sin concentrar todo el traslado en un único fin de semana.
Empieza por la documentación, prepara el destino y avanza según tu calendario. Consulta los precios fijos y los límites actuales de TrekMail en trekmail.net.
