Un runbook por lotes, válido para cualquier proveedor
Un cliente cambia de hosting, o usted retoma una cartera: los buzones deben seguirle sin que nadie pierda un mensaje durante la propagación del DNS. Esta guía solo supone dos cosas: acceso IMAP a ambos servidores y control de la zona DNS del dominio. No depende de ningún panel ni de ninguna marca.
La dificultad no es copiar un mensaje, sino no olvidar nada a su alrededor: el buzón que nadie listó, la redirección que solo existe en el panel antiguo, la cuota demasiado justa en destino, el correo que sigue llegando a la dirección antigua porque un resolvedor conserva el MX anterior en caché. De ahí un método por lotes: inventariar, preparar un único archivo, sincronizar dos veces, contar.
La salida de Gmail o Microsoft 365, y de AWS WorkMail hacia un servidor Mailcow, tienen sus propias guías ("Migrar el correo profesional: dejar Gmail y Microsoft 365" y "AWS WorkMail cierra: migra a Mailcow autoalojado en VPS"). Aquí tratamos el caso general de una cartera de clientes.
El inventario, antes de tocar nada
Una migración por IMAP mueve mensajes y carpetas. Nada más. Todo lo que vive junto a ellos en el panel antiguo debe listarse antes de la primera transferencia; si no, desaparece sin ruido en el cambio.
Pida al proveedor anterior la exportación de las cuentas, o léalas en su interfaz, y consolídelas en una tabla por dominio. Añada una columna de "uso real": un buzón de 40 GB que en realidad ocupa 5 GB cambia el tiempo de copia y la cuota que hay que prever en destino. Añada una columna de "último acceso": un buzón que no se abre desde hace un año es una cuenta fantasma que archivar o una dirección de formulario que aún recibe solicitudes. Esa pregunta es para el cliente, no para usted.
El cliente debe validar la tabla antes de continuar. Es la única protección contra el buzón olvidado.
Qué debe contener el inventario, buzón por buzón
- Buzones y cuotas — dirección, cuota asignada, espacio realmente ocupado, número de carpetas, para dimensionar el destino.
- Alias y redirecciones — cada alias, cada reenvío a una dirección externa, cada dirección "catch-all": IMAP no los transporta, hay que recrearlos a mano.
- Respuestas automáticas y filtros — respuestas automáticas, reglas de clasificación en el servidor, listas de bloqueo: recrearlas o exportarlas si el panel lo permite.
- Dispositivos y clientes de correo — teléfonos, Outlook, Thunderbird, escáneres e impresoras que envían por SMTP: cada uno deberá apuntar al nuevo servidor.
- Credenciales — una contraseña por buzón, o una contraseña de aplicación si la autenticación en dos pasos está activa en el origen.
- Contactos y calendarios — fuera del alcance de IMAP: expórtelos aparte y dígaselo explícitamente al cliente.
El calendario de TTL, antes del cambio de MX
El TTL (tiempo de vida) de un registro DNS indica cuánto tiempo puede conservarlo un resolvedor en caché. Si el MX está a 86 400 segundos, un remitente puede seguir entregando al servidor antiguo durante veinticuatro horas tras su cambio. Bajar el TTL solo sirve si se hace con suficiente antelación: el valor reducido debe haber caducado en las cachés antes del cambio.
Regla práctica: leer el TTL actual del MX, bajar el registro a 300 segundos al menos un período del TTL antiguo antes del cambio (dos o tres días antes si no lo conoce) y no tocar nada más. El día D se modifica el MX, se lanza la pasada delta y el servidor antiguo sigue activo. El TTL solo vuelve a subir cuando termina el período de doble lectura.
Prevea también los registros de autenticación: el SPF y la clave DKIM del nuevo proveedor se publican antes del cambio, no después. Su definición está en "SPF, DKIM, DMARC: superar el umbral de 5000 correos".
Calendario tipo de un cambio
Desplace la tabla
| Momento | Acción | Por qué |
|---|---|---|
| D-7 | Inventario validado por el cliente, buzones creados en destino | Ningún buzón olvidado, cuotas dimensionadas |
| D-3 | TTL del MX bajado a 300 segundos | El valor reducido debe caducar en las cachés antes de D |
| D-2 | Primera pasada de imapsync, el grueso del correo | El gran volumen se copia sin urgencia |
| D-1 | SPF y DKIM del nuevo proveedor publicados | Los primeros mensajes salientes quedan autenticados |
| D | Cambio del MX y luego pasada delta | Recoge lo llegado desde la primera pasada |
| D+1 a D+3 | Pasadas delta adicionales, doble lectura | Resolvedores rezagados y correo en cola |
| D+7 | Verificación final, TTL subido, servicio antiguo cancelado | Se corta solo después de contar |
Las credenciales no deben quedar por ahí
Un lote de buzones es una lista de contraseñas. La trampa habitual es pegarlas en un comando: quedan en el historial del shell y en la lista de procesos mientras el comando se ejecuta. Prefiera la opción --passfile1 de imapsync, que lee la contraseña en la primera línea de un archivo, en lugar de --password1, que la propia documentación de imapsync desaconseja.
Trabaje en una carpeta temporal creada con umask 077, en una máquina que controle, nunca en el puesto compartido de un compañero. El archivo de lote se elimina al final con shred -u, y las contraseñas de destino se cambian después si el cliente las comunicó por un canal no confidencial. Un archivo de lote olvidado en una carpeta sincronizada con una nube personal es un incidente, no un detalle.
Si un buzón de origen exige una contraseña de aplicación, pídasela al cliente de forma explícita: la contraseña habitual será rechazada.
La sincronización en dos pasadas, buzón a buzón y luego en lote
Preparar la carpeta de trabajo
umask 077 && mkdir lote-cliente && cd lote-clientey despuésmkdir logs. Nada de esta carpeta debe acabar en un repositorio Git ni en una carpeta sincronizada.Escribir el archivo de lote
Un archivo
buzones.csv, una línea por buzón:usuario origen;contraseña origen;usuario destino;contraseña destino. Los servidores se fijan en el comando, como en el ejemplo de la documentación de imapsync. Una contraseña con punto y coma rompe la línea: elija otro separador para ese lote.Probar un solo buzón en seco
imapsync --dry --host1 imap.proveedor-antiguo.com --user1 [email protected] --passfile1 p1 --host2 imap.proveedor-nuevo.com --user2 [email protected] --passfile2 p2 --ssl1 --ssl2 --automapno copia nada y muestra lo que se haría.--automapempareja las carpetas habituales (Enviados, Borradores, Spam) cuyo nombre difiere entre servidores.Anotar los tamaños de las carpetas
Añada
--justfoldersizesal mismo comando: imapsync muestra los tamaños iniciales de ambos lados y se detiene. Conserve esa salida, es la base del recuento final.Lanzar la primera pasada en ese buzón
Quite
--dryy--justfoldersizes, añada--logfile logs/contacto.txt. Repetir la ejecución no retransfiere lo que ya está, y por defecto no se borra nada en destino: no añada--delete2antes del final del proyecto.Ejecutar el lote
while IFS=';' read -r u1 p1 u2 p2; do printf '%s' "$p1" > p1; printf '%s' "$p2" > p2; imapsync --host1 imap.proveedor-antiguo.com --user1 "$u1" --passfile1 p1 --host2 imap.proveedor-nuevo.com --user2 "$u2" --passfile2 p2 --ssl1 --ssl2 --automap --logfile "logs/$u1.txt"; echo "$u1;$?" >> resultados.csv; done < buzones.csvLeer el código de salida de cada buzón
grep -v ';0$' resultados.csvlista los buzones que no terminan en cero. Los códigos útiles son 16, 161 y 162 (autenticación), 113 (cuota superada en destino) y 101 o 102 (no se puede conectar con uno de los dos servidores).Cambiar el MX y repetir el mismo lote
Tras el cambio de MX, vuelva a ejecutar exactamente el mismo bucle: es la pasada delta. Solo copia los mensajes llegados desde la primera pasada. Repítala en D+1 y D+3 y después
shred -u buzones.csv p1 p2.
Verificar la llegada en lugar de creerla
Una sincronización "terminada" no es una prueba. Lo que se verifica es un recuento: vuelva a lanzar --justfoldersizes en cada buzón, lado origen y lado destino, y compare carpeta por carpeta el número de mensajes y el tamaño. Una diferencia debe explicarse línea por línea (papelera excluida a propósito, duplicados fusionados, carpeta no suscrita), no redondearse. No se dice "sin pérdidas"; se dice "recuento coincidente en cada carpeta, diferencias explicadas".
Después, la prueba de extremo a extremo: envíe un mensaje desde una dirección externa a cada buzón migrado y compruebe que llega al nuevo servidor; responda desde el webmail del destino y compruebe que llega a un destinatario externo. En las cabeceras del mensaje recibido, compruebe que SPF, DKIM y DMARC están en pass. Por último, abra de verdad un buzón por dominio en un cliente de correo recién configurado: es lo que revela una carpeta no suscrita o una contraseña mal transmitida.
Solución de problemas: los errores que se repiten en los lotes
AUTHENTICATIONFAILEDy código de salida 161 o 162 — contraseña incorrecta, contraseña de aplicación exigida o IMAP desactivado en esa cuenta. El 161 designa el origen y el 162 el destino: compruebe primero la mitad correcta.- Código 113,
OVERQUOTA— el buzón de destino es demasiado pequeño. Suba la cuota en destino a partir del inventario antes de repetir; si no, la pasada delta fallará en el mismo punto. - Código 101 o 102 — servidor inalcanzable: cortafuegos, puerto incorrecto o límite de conexiones simultáneas del proveedor de origen. Lance el lote buzón a buzón, no en paralelo, y espacie los reintentos.
- Carpetas duplicadas o mal nombradas — los separadores de jerarquía difieren (punto en un lado, barra en el otro). Repita la prueba
--dry --justfoldersy ajuste--automapantes de copiar. - Mensajes presentes dos veces — la identificación se basa en las cabeceras. Si un cliente señala duplicados, lea la opción
--useheader "Message-Id"en la documentación de imapsync antes de repetir.
No cierre el servicio antiguo el día del cambio
Mantenga activos los buzones de origen al menos una semana después del cambio de MX y pida al cliente que consulte ambos mientras tanto. Un remitente cuyo resolvedor conservó el MX anterior, o cuyo servidor reintenta una entrega diferida, seguirá dejando correo en la dirección antigua; la pasada delta lo trae, pero solo si la cuenta sigue existiendo. Suba el TTL y cancele el servicio antiguo solo cuando la última pasada delta no encuentre ningún mensaje nuevo.
Acoger los buzones: qué cubre el hosting web y qué no
El hosting web cPanel de ServOrbit incluye correo profesional: usted crea los buzones en cPanel, fija su cuota y el cliente accede a su webmail; la guía "Crear una dirección de correo profesional en cPanel" detalla el gesto. El número de buzones depende del plan elegido, que se consulta en la página del plan al dimensionar el lote.
Hay que ser preciso con el alcance. El asistente de migración de cartera de ServOrbit, descrito en "ServOrbit: migre toda su cartera en un solo pedido", cubre los dominios y las cuentas de hosting cPanel. No mueve los buzones IMAP de un proveedor externo. La migración asistida existe como opción: hay que pedirla y confirmarla antes de prometer una fecha al cliente, nunca suponerla incluida.
Una vez llegados los buzones, la configuración de los dispositivos sigue la guía "Configurar su correo profesional en el móvil u Outlook".
Lo que entrega al cliente al final
Una migración se cierra con un documento, no con un "ya está". Entregue al cliente la tabla de inventario anotada (buzón, estado, diferencias de recuento explicadas), la lista de alias, redirecciones y respuestas automáticas recreados, la lista de dispositivos reconfigurados y la fecha en que se cancelará el servicio antiguo. Adjunte las salidas de recuento de antes y después: si llega una reclamación tres semanas más tarde, permiten responder con cifras.
Anote también lo que no estaba cubierto: contactos, calendarios, reglas de clasificación no recreadas. Una rutina que devuelve "OK" solo dice lo que mira. Y programe una comprobación diez días después: un buzón poco consultado solo señalará su problema entonces.
