Si necesitas una lista de migración de correo, empieza por esta regla: el correo no se traslada arrastrando carpetas. Es un sistema activo con estados de mensajes que cambian, alias, reenvíos, limitaciones, clientes averiados y usuarios que siguen enviando mientras trabajas. Por eso fallan los cambios improvisados. Si aún estás decidiendo dónde alojar el correo después del traslado, consulta primero correo empresarial para pequeñas empresas. Si ya sabes que debes migrar, usa este procedimiento y mantén el proceso previsible.
El problema es sencillo. La mayoría de los equipos copia el correo, cambia los MX y espera que todo salga bien. El lunes aparecen los elementos ausentes: el archivo del fundador, el reenvío de facturas o el buzón compartido que en realidad usaban cinco personas con una sola cuenta. Esta lista corrige el problema al reunir descubrimiento, sincronización previa, verificación, reintentos y reversión en un único documento operativo.
| Enfoque | Método anterior | Método nuevo |
|---|---|---|
| Planificación | Copiar todo en un fin de semana | Auditar, preparar, cambiar, verificar y bloquear el origen |
| Métrica de éxito | El tamaño del buzón parece parecido | Coinciden los recuentos, registros de fallos y envíos de prueba |
| Gestión de fallos | Reintentar hasta que alguien se queje | Definir espera, responsable y activador de reversión para cada error |
| Seguimiento | Dejar el correo antiguo activo durante días | Bloquear accesos zombis y reconstruir rápido los clientes dañados |
Lista de migración antes de copiar un solo mensaje
Una lista de migración empieza por la visibilidad. Antes de mover un byte, necesitas un inventario programático de buzones, alias, reglas de reenvío, tamaños y límites del origen. Si el descubrimiento es deficiente, cada paso posterior será más lento, arriesgado y costoso.
No confíes en las exportaciones de RR. HH. ni en la hoja de cálculo que el cliente envió el mes pasado. Extrae los datos de la plataforma de origen y crea un inventario que responda cinco preguntas:
- ¿Qué buzones existen y cuáles siguen recibiendo correo?
- ¿Qué alias y cuentas funcionales corresponden a esos buzones?
- ¿Qué usuarios destacan por su consumo de almacenamiento?
- ¿Qué reglas de reenvío de bandeja, transporte o buzón están activas?
- ¿Qué cuentas son direcciones operativas compartidas y no buzones personales?
El último punto importa más de lo que muchos admiten. invoices@, support@ y hello@ suelen parecer buzones normales hasta el día del cambio. Entonces nadie sabe quién es responsable, qué dispositivo sigue conectado ni dónde han ido las respuestas.
Ejecuta también una revisión de datos defectuosos. Busca MIME mal formado, adjuntos demasiado grandes y estructuras de carpetas absurdas. IMAP puede mover mucho, pero no convierte datos de origen dañados en datos de destino limpios. Recuerda además lo que IMAP no traslada bien o no traslada en absoluto. El flujo de TrekMail solo mueve correo, por lo que calendarios y contactos requieren otro plan. La introducción a la migración IMAP de TrekMail deja claro ese límite.
Ejemplo: un buzón tiene 14,200 elementos en origen, pero dos mensajes están dañados y un adjunto de 80 MB supera la política de destino. Si el procedimiento dice que el tamaño parece correcto, no lo detectarás. Si exige revisar los recuentos y el registro de elementos fallidos, lo encontrarás antes que los usuarios.
Lista de migración para diseñar el cambio
La lista debe definir la arquitectura de migración antes de que nadie programe un cambio de fin de semana. Los buzones pequeños pueden soportar un traslado total. Las empresas reales normalmente no. Prepara el correo histórico, deja los cambios recientes para la última sincronización incremental y modifica el DNS solo cuando los buzones más lentos estén casi terminados.
Hay tres patrones habituales:
| Patrón | Ideal para | Riesgo principal |
|---|---|---|
| Cambio total | Equipos diminutos con buzones ligeros | Sin margen si aparecen límites o daños durante el cambio |
| Preparación más incremento | La mayoría de migraciones de pymes y MSP | Requiere registros disciplinados y una segunda pasada |
| Híbrido | Grandes entornos de Exchange | Complejidad innecesaria para la mayoría de equipos pequeños |
Para la mayoría, la respuesta correcta es preparar y ejecutar una pasada incremental. Un calendario práctico se parece a este:
- T menos 14 días: migra primero el correo antiguo e identifica los buzones lentos.
- T menos 7 días: confirma alias, reglas de reenvío y asignación de buzones de destino.
- T menos 2 días: reduce el TTL de DNS, prueba la autenticación y revisa el registro de fallos.
- T cero: cambia los MX, actualiza SPF y DKIM, ejecuta la sincronización incremental y corrige los clientes.
- T más 1 día: verifica recuentos, prueba correo entrante y saliente y desactiva el acceso anterior.
Si configuras mal el DNS, el flujo se interrumpe. Reduce el TTL con al menos 48 horas de antelación y compara después los registros de destino con los registros DNS necesarios de TrekMail.
example.com. 300 IN MX 10 mail.trekmail.net.
example.com. 300 IN TXT "v=spf1 include:spf.trekmail.net -all"
_dmarc.example.com. 300 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"
# DKIM value is generated per domain in the TrekMail dashboard.Durante las primeras 24 a 48 horas tras modificar los MX, una política DMARC temporal p=none puede reducir los rechazos provocados por la propia migración mientras se actualizan las cachés. Cuando el traslado sea estable, vuelve a aplicar una política estricta. Este consejo importa aún más si envías un volumen considerable a Gmail. Las directrices de Google para remitentes exigen ahora SPF, DKIM, alineación, TLS y DMARC a los remitentes masivos.
Lista de migración para la preparación y sincronización incremental
La parte central de una lista de migración trata de límites físicos, no de optimismo. IMAP copia mensajes carpeta por carpeta y los grandes proveedores imponen límites de ancho de banda y velocidad. Debes trasladar pronto el correo antiguo, controlar los reintentos y reducir la última pasada lo suficiente para terminarla dentro de la ventana de cambio.
Aquí fracasan muchas migraciones. IMAP depende de identificadores de mensajes y del estado de los buzones. El comportamiento de RFC respecto a UID y UIDVALIDITY en RFC 3501 explica por qué las carpetas reindexadas o dañadas pueden provocar resincronizaciones problemáticas. Si la herramienta permite omitir duplicados o comparar por contenido, usa esa opción. El asistente de importación de TrekMail incluye la omisión de duplicados y los pasos vigentes aparecen en Iniciar una migración en el panel.
Para los operadores que prueban herramientas de línea de comandos antes de tocar producción, conviene mantener abierta esta guía complementaria sobre imapsync.
imapsync \
--host1 oldmail.example.com --user1 alice@example.com --password1 'SOURCE_PASS' \
--host2 imap.trekmail.net --user2 alice@example.com --password2 'DEST_PASS' \
--ssl1 --ssl2 \
--syncinternaldates \
--exclude 'Calendar|Contacts' \
--skipsize
Calcula el ancho de banda antes de prometer que terminarás en un fin de semana. Google publica límites IMAP para Gmail, incluido un máximo diario de descarga de 2,500 MB por cuenta. Microsoft funciona de otro modo, pero no es más generoso. Según Microsoft, el rendimiento de la migración varía y está condicionado por límites del servicio. Por eso un buzón enorme puede arruinar el calendario si lo descubres tarde.
Mantén también un alcance realista en el destino. TrekMail solo ofrece IMAP, no una suite ofimática completa. Durante una migración es una ventaja, porque el alcance permanece claro: mueve el correo, verifícalo y gestiona calendarios y contactos por separado en vez de mezclar ámbitos de fallo.
Lista de verificación después de cambiar el DNS
Una buena lista trata la verificación como una fase independiente, no como un vistazo rápido al tamaño del buzón. El tamaño engaña. La codificación cambia, cada plataforma gestiona los adjuntos de forma distinta y los cálculos de almacenamiento del servidor no son coherentes. Los recuentos, comprobaciones puntuales, envíos de prueba y revisión de fallos indican si el correo sobrevivió al traslado.
Usa una matriz sencilla para cada clase de buzón: directivos, cuentas compartidas, usuarios normales y usuarios con buzones enormes.
| Comprobación | Qué comparar | Condición de aprobación |
|---|---|---|
| Recuento de elementos | Totales por carpeta en origen y destino | Coincidencia exacta o diferencias explicadas en los registros |
| Flujo de correo | Entrada externa, salida externa y correo interno | Los tres funcionan y llegan al buzón previsto |
| Alias | Pruebas de respuesta y recepción para cada alias | Sin rebotes y entrega al buzón correcto |
| Reenvío | Reenvíos empresariales críticos conocidos | Reglas recreadas y documentadas |
| Acceso de clientes | Outlook, Apple Mail y clientes móviles | El perfil nuevo o la nueva configuración funcionan sin credenciales antiguas |
La lista también debe incluir un paso para buzones zombis. Cuando termine la sincronización incremental, bloquea el acceso de los usuarios a la plataforma antigua. De lo contrario, un teléfono o perfil de Outlook obsoleto todavía puede enviar o recibir contra el origen y dejar mensajes aislados.
En TrekMail, la configuración es directa: host IMAP imap.trekmail.net, puerto 993 y la dirección completa como nombre de usuario. POP3 no está disponible. Los valores exactos figuran en la guía de configuración IMAP y SMTP de TrekMail. Si Outlook insiste en utilizar el servidor anterior, deja de parchearlo y crea un perfil nuevo.
dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
Lista de migración para reintentos, registros y reversión
El último tercio de la lista define qué ocurre cuando el plan se complica. Necesitas reglas de reintento, campos de registro, responsables de escalado y un umbral de reversión antes de iniciar el primer buzón. Si los inventas bajo presión, tomarás malas decisiones.
El registro debe guardar buzón, carpeta, marca temporal, servidor de origen, servidor de destino, cantidad intentada, cantidad copiada, bytes copiados, número de reintentos, estado final y error legible. Después clasifica los fallos rápidamente:
| Fallo | Significado | Acción del operador |
|---|---|---|
| Fallo de autenticación | Contraseña incorrecta, falta la contraseña de aplicación o se bloqueó el acceso al origen | Corregir credenciales, probar un buzón y reanudar el lote |
| Conexión rechazada | Puerto incorrecto, SSL incompatible, cortafuegos o problema del host de origen | Validar host y puerto 993 y probar manualmente antes de reintentar |
| Limitación o espera tipo 429 | El proveedor limita la frecuencia de solicitudes | Reducir concurrencia, esperar 5 a 10 minutos y reanudar lentamente |
| Avalancha de duplicados | La carpeta se reindexó o el estado de migración se desvió | Detener el lote, activar la omisión de duplicados y repetir solo las carpetas afectadas |
| Falta correo reciente | La pasada incremental estaba incompleta o los clientes antiguos siguieron escribiendo en origen | Repetir la pasada final y desactivar de inmediato el acceso al origen |
Revertir no significa devolverlo todo porque un usuario se quejó. Una lista rigurosa define los activadores de reversión con antelación. Son válidos un fallo general de entrada tras cambiar MX, grandes diferencias inexplicables en buzones críticos o un fallo de autenticación del destino que bloquea todo el entorno. No lo son un dispositivo móvil obsoleto ni un usuario que nunca actualizó su contraseña.
Si hace falta revertir, limita el alcance. Restaura primero el flujo, comunica un único estado y conserva todos los registros. No reinicies tres herramientas a la vez ni provoques un problema mayor que el fallo original.
Por qué esta lista funciona mejor con TrekMail
Esta lista resulta más sencilla cuando la plataforma de destino está creada para correo y no para vender puestos agrupados. El método anterior consiste en pagar por usuario una suite que apenas utilizas y tratar la migración como una tarea secundaria. El método nuevo es trasladarse a una plataforma centrada en correo, con almacenamiento previsible, DNS claro y un proceso IMAP adecuado.
TrekMail encaja bien en ese modelo. Admite dominios personalizados, buzones IMAP, catch-all, reenvío, migración del lado del servidor, asistente de SPF/DKIM/DMARC, SMTP propio o incluido y una API. Los planes de pago empiezan en $3.50 al mes con Starter y la herramienta integrada está disponible en ellos. Para probar funciones de pago hay una prueba gratuita de 14-day que requiere tarjeta de crédito. Si solo quieres empezar sin tarjeta, Nano siempre es gratuito.
La ventaja operativa es el almacenamiento compartido y la gestión multidominio con tarifa fija. Un buzón enorme no obliga a pagar licencias por puesto en toda la empresa. Esto importa a agencias, MSP y cualquiera que mantenga cuentas funcionales en muchos dominios. Si ese es tu entorno, lee después la perspectiva de TrekMail sobre alojamiento de correo multidominio. Para comparar precios y planes, consulta directamente los precios de TrekMail.
La ejecución también es más limpia. Añades el dominio, creas el buzón de destino, ejecutas la migración IMAP en el servidor, validas el DNS y cambias los clientes. Sin desvíos por POP3 ni conectores propietarios opacos. Solo IMAP y SMTP estándar con ajustes explícitos.
Conclusión: mantén previsible la lista de migración
La mejor lista de migración es la que nadie recuerda un mes después. Inventaría el origen, prepara el correo antiguo, cambia el DNS de forma deliberada, ejecuta la pasada incremental, verifica con recuentos, elimina accesos zombis y limita la reversión. Así, la migración deja de ser una apuesta y se convierte en una tarea operativa normal, justo lo que debe ser el correo en producción.
