Cómo migrar correo con IMAPSync entre servidores sin perder mensajes
Aprende a migrar correo con IMAPSync entre servidores IMAP preservando carpetas, flags y fechas. Procedimiento probado en producción.
Migrar buzones entre servidores IMAP es uno de los procedimientos más delicados en administración de correo. Los mensajes son heterogéneos (tamaños que varían de 2 KB a 50 MB+), las flags importan (leído/no leído, marcado, respondido), y cualquier interrupción en el MX deja mensajes en tránsito flotando entre los dos lados. IMAPSync resuelve esto con sincronización incremental — puedes ejecutarlo varias veces sin duplicar mensajes y hacer el cutover real en una ventana corta.
Este tutorial es para sysadmins que necesitan mover una o varias cuentas IMAP entre proveedores sin perder mensajes. Cubre el ciclo completo: instalación, dry-run, sincronización en dos fases, cambio de DNS y validación final. Persona típica: alguien migrando desde cPanel/Plesk/Zimbra a otro proveedor, o consolidando cuentas de un Microsoft 365 antiguo hacia infraestructura propia en VPS.
Tiempo estimado: 30-45 minutos para el setup y primera sincronización de una cuenta de 5-10 GB. Cuentas más grandes tardan horas y pueden dejarse corriendo en background. El cutover final (la segunda ejecución incremental) suele tardar 2-5 minutos por cuenta.
Prerrequisitos
Necesitas una máquina Linux con acceso a internet — puede ser la VPS de destino, una VPS auxiliar o tu propio escritorio. Recomiendo ejecutar IMAPSync en una VPS en el mismo datacenter del servidor de destino: la latencia baja marca una diferencia real en cuentas grandes.
Ubuntu 22.04/24.04 LTS o Debian 12 con acceso sudo, Perl 5.30+ instalado (por defecto en el sistema), 2 GB libres en disco para caché temporal de IMAPSync, y puerto 993 (IMAPS) liberado para tráfico saliente. Credenciales IMAP de origen y destino — con contraseña de aplicación si 2FA está activo.
993 143 ~/.imapsync/ LOG_imapsync/ Instalación de IMAPSync
La versión de los repositorios Debian/Ubuntu es antigua (generalmente 1.7xx). Recomiendo compilar desde el código fuente — la versión 2.x tiene fixes importantes para Microsoft 365 y Gmail y mejor manejo de errores transitorios.
Instala las dependencias Perl y herramientas de build:
sudo apt update
sudo apt install -y \
git make cpanminus libio-socket-ssl-perl libnet-ssleay-perl \
libcrypt-ssleay-perl libmail-imapclient-perl libdigest-md5-file-perl \
libdist-checkconflicts-perl libfile-copy-recursive-perl \
libio-tee-perl libjson-webtoken-perl libreadonly-perl \
libregexp-common-perl libsys-meminfo-perl libterm-readkey-perl \
libtest-fatal-perl libtest-mockobject-perl libtest-pod-perl \
libtest-requires-perl libtest-deep-perl libunicode-string-perl \
liburi-perl libencode-imaputf7-perl libfile-tail-perl \
libdata-uniqid-perl libproc-processtable-perl libtime-hires-perlLa lista parece larga pero cada módulo cubre un caso real — SSL, encoding UTF-7 IMAP, parsing de IDs únicos, tail de logs en vivo. Saltar cualquiera resultará en un error críptico en medio de la migración.
Clona e instala IMAPSync:
git clone https://github.com/imapsync/imapsync.git
cd imapsync
sudo make install
imapsync --versionEl comando final debe devolver algo como Imapsync 2.255 o superior.
Si aparece “Can’t locate … in @INC”, falta algún módulo Perl —
identifica el nombre por el error e instálalo vía
sudo cpanm Nombre::Modulo.
Dry-run para validar credenciales y mapeo de carpetas
Antes de copiar cualquier mensaje, ejecuta en modo dry-run. Esto lista las carpetas de los dos lados, valida el login y muestra cuántos mensajes existen sin transferir nada.
Crea un archivo migracion.sh con las variables de la cuenta:
#!/bin/bash
imapsync \
--host1 mail.origen.com \
--port1 993 \
--ssl1 \
--user1 [email protected] \
--password1 'CLAVE_ORIGEN' \
--host2 mail.destino.com \
--port2 993 \
--ssl2 \
--user2 [email protected] \
--password2 'CLAVE_DESTINO' \
--dry \
--justfoldersLa combinación --dry --justfolders lista las carpetas de los dos
lados sin tocar mensajes. Es la forma más rápida de detectar un
mismatch (ej.: el origen tiene “INBOX.Sent” y el destino espera
“Sent Items”).
Ejecuta y analiza el output:
chmod +x migracion.sh
./migracion.sh 2>&1 | tee dry-run.logBusca en el log las líneas que empiezan con Host1 folders: y Host2 folders:. Si hay discrepancia (ej.: el origen usa jerarquía con punto
“INBOX.Trabajo” y el destino usa barra “INBOX/Trabajo”), necesitarás
--regextrans2 's,INBOX\.,INBOX/,g' en la ejecución real.
Si el origen o destino es Microsoft 365, Gmail o iCloud con 2FA activo, la contraseña normal NO funciona vía IMAP. Genera una “contraseña de aplicación” en el panel del proveedor antes de ejecutar. Para Gmail, activa IMAP en Configuración → Reenvío y POP/IMAP primero.
Primera sincronización (pre-cutover)
La primera ejecución es la pesada — copia todo. Puede tardar horas para cuentas grandes. Ejecuta en screen o tmux para no perder el progreso si la sesión SSH se cae.
Inicia una sesión tmux para ejecutar en background:
tmux new -s migracionSi la conexión SSH se cae, te reconectas y ejecutas
tmux attach -t migracion para seguir acompañando.
Ejecuta la sincronización completa removiendo el --dry --justfolders:
imapsync \
--host1 mail.origen.com --port1 993 --ssl1 \
--user1 [email protected] --password1 'CLAVE_ORIGEN' \
--host2 mail.destino.com --port2 993 --ssl2 \
--user2 [email protected] --password2 'CLAVE_DESTINO' \
--automap \
--syncinternaldates \
--useuid \
--addheader \
--logfile LOG_imapsync/usuario.log--automap mapea automáticamente Sent/Sent Items/INBOX.Sent entre
proveedores distintos. --syncinternaldates preserva la fecha
original. --useuid hace que la sincronización sea idempotente —
volver a ejecutarla no duplica nada. --addheader añade X-Imapsync
en los mensajes para que puedas auditar después cuáles fueron migrados.
Para cuentas con Trash o Junk gigantes, añade --exclude '^Trash$' --exclude '^Junk$' --exclude '^Spam$'. Ahorra horas y gigabytes en
cuentas antiguas. Sent y Drafts generalmente SÍ vale la pena migrarlos.
Cambio de DNS y cutover
Con la primera sincronización completa, es hora de cambiar el MX. Los mensajes nuevos llegarán al servidor de destino y el antiguo recibirá cero tráfico nuevo. La segunda ejecución de IMAPSync solo tomará los mensajes que llegaron al antiguo entre el inicio de la primera sync y el momento en que el DNS se propagó — típicamente 30-120 minutos de mensajes.
Reduce el TTL del registro MX en el proveedor de DNS a 300 segundos (5 min) ANTES de hacer cualquier cambio — idealmente 24h antes. Esto garantiza que la propagación sea rápida cuando cambies el destino. Si el TTL estaba en 3600 o 86400, todos seguirán viendo el valor antiguo hasta que ese tiempo termine.
# Verifica el TTL actual antes de cambiar
dig +short mx dominio.com
dig +nocmd +noall +answer mx dominio.comCambia el MX al nuevo servidor. En el panel DNS:
- Tipo:
MX - Prioridad:
10(o la que uses) - Valor:
mail.destino.com.(con punto final) - TTL:
300
Espera 5-10 minutos y confirma la propagación:
dig +short mx dominio.com @1.1.1.1
dig +short mx dominio.com @8.8.8.8Ambos deben devolver el nuevo MX. Si uno devuelve el antiguo, el caché del resolver aún no expiró — espera unos minutos más.
Ejecuta IMAPSync por segunda vez — comando idéntico al Step 06. Por el
--useuid, solo copiará los mensajes que llegaron al origen entre la
primera y la segunda ejecución. Típicamente es rápido (2-10 minutos).
./migracion.sh 2>&1 | tee LOG_imapsync/cutover.logAl final del log, busca Total bytes transferred. En una sync
incremental exitosa, ese valor es pequeño (algunos MB como máximo).
Verificación
La validación básica es contar mensajes de los dos lados. Si coinciden, la migración está íntegra.
Compara los conteos de origen y destino:
imapsync \
--host1 mail.origen.com --port1 993 --ssl1 \
--user1 [email protected] --password1 'CLAVE_ORIGEN' \
--host2 mail.destino.com --port2 993 --ssl2 \
--user2 [email protected] --password2 'CLAVE_DESTINO' \
--justconnectY luego ejecuta con --dry para ver el reporte final de mensajes
contados en cada carpeta de los dos lados:
./migracion.sh --dryAl final, busca Folder Host1/Host2 messages — cada par debe coincidir.
Una diferencia de ≤ 5 mensajes en carpetas de 10k+ es normal
(mensajes que llegaron entre la última sync y la verificación).
Resolución de problemas
Error “Too many connections” durante migración paralela
Cuando ejecutas IMAPSync para varias cuentas en paralelo, algunos
proveedores limitan las conexiones por IP. Reduce la concurrencia a
2-3 procesos simultáneos y añade --maxbytespersecond 5000000
(5 MB/s) para darle respiro al servidor.
Mensajes duplicados después de la segunda ejecución
Esto indica que --useuid no está funcionando — generalmente porque
el destino reescribe los UIDs al copiar los mensajes. Solución: usa
--useheader Message-Id en vez de --useuid. Más lento, pero
deduplica por header en vez de UID nativo.
La carpeta “Sent” de Gmail aparece duplicada
Gmail tiene una peculiaridad: cada mensaje aparece en “[Gmail]/All
Mail” Y en “INBOX” o “Sent”. Añade --exclude '^\[Gmail\]/All Mail$'
o terminarás migrando todo por duplicado.
Mantén el buzón de origen activo durante al menos 7-14 días después del cutover. Pueden aparecer mensajes con retraso (servidores que cachearon el MX antiguo por más tiempo, sistemas de retry de otros proveedores). Ejecutar IMAPSync periódicamente esos días garantiza la captura.
Próximos pasos
Con la migración concluida, considera automatizar verificaciones para detectar problemas post-cutover:
- Configura SPF, DKIM y DMARC en el nuevo MX antes de dar de baja el antiguo
- Monitorea la tasa de rebote en las primeras 48h para detectar mala reputación de IP en el nuevo servidor
- Documenta la contraseña de aplicación generada y revócala después de 30 días
- Si vas a migrar decenas de cuentas, monta un script con GNU parallel para ejecutarlas en lote
- Configura backup automático del nuevo buzón (rsnapshot, restic o similar) para tener un punto de recuperación independiente del proveedor
Si estás consolidando correo en infraestructura propia para tener control del MX y de los backups, una VPS Hostini con IP dedicada y puertos SMTP/IMAP liberados es el punto de partida — sin bloqueo del puerto 25 para tráfico saliente y con DNS reverso configurable desde el panel.
Preguntas frecuentes
¿IMAPSync preserva las fechas originales de los mensajes?
Sí. IMAPSync replica el INTERNALDATE de cada mensaje por defecto, por lo que la fecha de recepción en el servidor de destino coincide con la del servidor de origen. Si el destino rechaza el INTERNALDATE (algunos proveedores lo hacen), usa la flag --syncinternaldates 0 y acepta que la fecha pasará a ser el momento de la migración.
¿Puedo ejecutar IMAPSync en paralelo para varias cuentas?
Sí, pero con cuidado. Cada proceso abre 2 conexiones IMAP simultáneas (una en cada lado), y muchos proveedores limitan las conexiones por IP. Empieza con 3-4 procesos paralelos y monitorea los errores 'Too many connections' en el log. GNU parallel es la forma más simple de orquestar en lote.
¿Qué pasa con los mensajes nuevos que llegan durante la migración?
Mientras el MX siga apuntando al servidor antiguo, los mensajes llegan allí. Ejecutas IMAPSync una primera vez (sync completa), cambias el MX al servidor nuevo y ejecutas una segunda vez incremental. La segunda ejecución solo copia el delta — los mensajes que llegaron entre las dos ejecuciones. Por eso el cutover siempre tiene 2 rondas.
¿Cómo manejar las diferencias de tamaño máximo de carpeta entre proveedores?
Algunos proveedores limitan Trash, Junk o Sent a pocos GB. Usa --exclude '^Trash$' --exclude '^Junk$' para saltar carpetas que no importan, o --maxsize 25000000 para ignorar mensajes mayores a 25 MB. La flag --justfolders en la primera ejecución lista todas las carpetas para que decidas qué migrar.
¿Necesito desactivar la autenticación de 2 factores en la cuenta de origen?
Depende del proveedor. Gmail, Outlook 365 e iCloud exigen contraseña de aplicación (app password) cuando 2FA está activo — IMAP simple no pasa por el 2FA interactivo. Genera la app password en el panel del proveedor, úsala en --password1 y revócala después de la migración. Proveedores con IMAP estándar (cPanel, Plesk, Zimbra) aceptan la contraseña normal.
¿IMAPSync funciona con Microsoft 365 y Gmail?
Sí. Para Microsoft 365, usa --host2 outlook.office365.com --port2 993 --ssl2 --authmech2 LOGIN. Para Gmail, activa IMAP en la configuración de la cuenta, genera una contraseña de aplicación y usa --host2 imap.gmail.com --port2 993 --ssl2. Ambos tienen límites de throughput — espera ~50 GB por día por cuenta.