Lista para migrar correo: guía operativa del cambio

Si necesitas una lista de comprobación para migrar correo, seguramente ya conoces los riesgos. Las migraciones no suelen fallar solo al copiar mensajes, sino en los detalles: alias olvidados, DNS desactualizado, perfiles de Outlook con ajustes en caché, peculiaridades de las etiquetas de Gmail y ese buzón prioritario que tarda tres días más de lo previsto.

Ese es el problema. Y muchas guías resultan demasiado generales para ayudar durante el cambio real. Si trasladas un equipo pequeño, retiras un alojamiento antiguo o buscas reducir el gasto en correo profesional, empieza por los fundamentos del correo empresarial para pequeñas empresas y vuelve después a esta lista operativa.

Esta guía ofrece una lista de comprobación para migrar correo antes, durante y después del cambio. Está pensada para fundadores, administradores de TI, agencias y proveedores de servicios gestionados que pasan a un alojamiento basado en IMAP como TrekMail. Según el artículo fuente, este ofrece correo multidominio, almacenamiento compartido y migración IMAP integrada del lado del servidor.

Qué incluye realmente una lista de comprobación para migrar correo

Es una lista de control del cambio que abarca buzones, DNS, identidad y acceso de los clientes de correo. Busca evitar rechazos de mensajes, carpetas ausentes, aplicaciones móviles que dejan de funcionar y lagunas de datos que solo aparecen cuando los usuarios vuelven a trabajar.

Una buena lista de comprobación para migrar correo no se limita a «exportar, importar y cambiar los MX». Debe cubrir todos los elementos que reciben correo, las dependencias que pueden impedir la entrega y las acciones del usuario que pueden convertir una migración terminada en una avalancha de incidencias.

1. Inventaría todo lo que pueda recibir correo

El primer punto es el inventario. Si la lista de origen solo incluye usuarios con licencia, está incompleta. Los buzones compartidos, alias, rutas catch-all, reglas de reenvío, escáneres, buzones financieros y listas de distribución antiguas pueden seguir recibiendo correo real tras el cambio.

Aquí empiezan los problemas: alguien exporta los «usuarios activos», crea los buzones de destino, cambia el DNS y da el trabajo por terminado. Después se rechazan consultas enviadas a sales@, se pierden de vista facturas enviadas a ap@ y la impresora de la oficina empieza a mostrar errores SMTP.

Revisa este inventario antes de mover datos:

1. Buzones de usuarios con licencia
2. Buzones compartidos y cuentas funcionales como info@, billing@ y support@
3. Alias asociados a usuarios o buzones compartidos
4. Listas de distribución y direcciones de grupos
5. Reglas de reenvío, comportamiento catch-all y excepciones de enrutamiento
6. Dispositivos y aplicaciones que envían a través del proveedor antiguo
7. Objetos de Exchange heredados, incluidas referencias X.500 o LegacyExchangeDN

Decidir si una dirección debe seguir siendo un alias o convertirse en un buzón importa más de lo que parece. Consulta alias de correo de dominio frente a buzón antes del traslado, no cuando empiecen los rechazos.

Regla operativa: si una dirección ha recibido pagos, oportunidades comerciales, incidencias o restablecimientos de acceso, trátala como un recurso de producción hasta demostrar lo contrario.

El modelo de TrekMail puede ayudar porque, según el artículo fuente, no se factura cada buzón funcional por usuario: los planes de pago empiezan en $3.50/mes y el almacenamiento es compartido. Puedes plantear la migración a buzones IMAP reales sin sustituir direcciones críticas por reenvíos improvisados; confirma las condiciones vigentes.

2. Comprueba qué traslada IMAP y qué no

Una lista para migraciones IMAP debe contemplar el traslado del correo, pero no dar por hecho el de todos los demás datos. Normalmente se copian mensajes y carpetas. Los calendarios, contactos, reglas, firmas, permisos y algunos metadatos propietarios suelen necesitar otro procedimiento.

Aquí se rompen las expectativas. IMAP traslada correo, no reconstruye todo el entorno de colaboración. Si el origen es Google Workspace o Exchange, los usuarios pueden esperar conservar calendarios, permisos compartidos, categorías e historial de autocompletado. No debes darlo por supuesto.

Antes del proyecto, deja por escrito qué entra en su alcance:

La herramienta de TrekMail está destinada a importar correo mediante IMAP. Utilízala para ese fin. Revisa la introducción a la migración IMAP y cómo iniciar una importación desde el panel antes de prometer una «migración de todo el entorno».

3. Copia previamente los buzones grandes para tener un calendario realista

La planificación debe considerar los límites de velocidad. Tu conexión local no es el único límite: el proveedor de origen, el de destino y las restricciones de las sesiones IMAP determinan el ritmo real.

Una conexión rápida en la oficina no impide que un buzón de 50 GB avance lentamente si el origen reduce el ritmo de las solicitudes, limita las conexiones o suspende una actividad IMAP intensa. Google publica límites de ancho de banda de Gmail y cuotas API; los entornos Microsoft también aplican restricciones.

No planifiques trasladar todos los buzones de golpe durante un fin de semana. Divide la migración en fases:

1. Copia los mensajes antiguos con dos o tres semanas de antelación.
2. Deja el correo reciente en el origen mientras los usuarios siguen trabajando.
3. Ejecuta una sincronización incremental durante la ventana final.
4. Valida los recuentos antes de modificar los MX.

Este paso reduce el riesgo y hace el proyecto más manejable. También puede reducir las consultas de soporte porque los usuarios encuentran gran parte de su histórico al acceder el primer día.

Si migras desde Gmail, recuerda las etiquetas. Una herramienta IMAP que no las gestione adecuadamente puede interpretar un mensaje con varias etiquetas como varias copias en carpetas distintas. Eso aumenta el tamaño y genera duplicados. Una lista de comprobación para migrar correo debe revisar expresamente la correspondencia de etiquetas y, cuando proceda, excluir estructuras innecesarias, como grandes carpetas de archivo.

Si prefieres trabajar con herramientas independientes, compara las opciones con imapsync. Para una migración integrada en el panel de alojamiento, la importación del lado del servidor de TrekMail evita hacer pasar todo el trabajo por el portátil de un administrador, según el funcionamiento descrito en el artículo fuente.

4. Reduce el TTL antes del cambio, no durante él

La lista debe incluir los tiempos del DNS. Bajar el TTL después de modificar los MX no reduce la duración de las respuestas antiguas que ya están en caché. Prevé reducirlo al menos 24 a 48 horas antes, teniendo en cuenta el TTL anterior y el comportamiento de los resolutores externos.

Es el problema clásico de dos destinos activos: parte de Internet ve el MX nuevo y otra parte sigue entregando al servidor antiguo. El panel puede indicar que la migración ha terminado mientras sigue llegando correo al proveedor anterior que nadie consulta.

Utiliza este calendario orientativo:

Los registros necesarios de TrekMail se describen en registros DNS obligatorios. Si ambos proveedores envían durante la transición, SPF puede necesitar autorizarlos temporalmente a los dos. SPF está definido en el RFC 7208 y DMARC en el RFC 7489.

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

Esta combinación temporal de SPF es un punto útil de la lista de comprobación para migrar correo. Retira el include antiguo más adelante, cuando deje de ser necesario, no apenas cinco minutos después del cambio de MX.

5. Valida el número de elementos, no solo el tamaño del buzón

Una lista adecuada verifica primero el número de mensajes. El tamaño puede resultar engañoso: los proveedores calculan el almacenamiento de formas distintas, la codificación de adjuntos añade sobrecarga y las etiquetas de Gmail pueden mostrar un mismo mensaje en varias carpetas.

Aquí suelen surgir alarmas injustificadas. El origen indica 10.2 GB y el destino 9.8 GB. Eso no implica automáticamente pérdida de datos. La codificación MIME, los motores de almacenamiento y la eliminación de duplicados pueden cambiar el tamaño declarado.

Sigue este orden de validación:

1. Comprueba el número total de elementos.
2. Revisa carpetas clave como Recibidos, Enviados, Borradores y Archivo.
3. Comprueba por muestreo los intervalos de fechas y las conversaciones con muchos adjuntos.
4. Solo después compara el tamaño declarado como indicador aproximado.

Si coinciden los recuentos y las comprobaciones por muestreo son correctas, es una buena señal, aunque no una garantía absoluta. Si los recuentos difieren, detente e investiga antes de dar la migración por terminada.

Prueba también el flujo real del correo. Envía desde fuera del dominio, desde dentro y desde el dispositivo más problemático de la empresa. Outlook, Mail de iPhone y los escáneres antiguos pueden revelar errores que no aparecen en el panel.

6. Planifica la nueva autenticación y la reconstrucción de perfiles

La lista está incompleta si termina con el estado del servidor. Los usuarios todavía deben acceder de nuevo en teléfonos, ordenadores, tabletas y aplicaciones antiguas. En muchos casos, recrear la cuenta es más eficaz que intentar reparar el perfil.

Es la fase de mayor carga para soporte. El buzón y el DNS están bien, pero Outlook insiste en la última configuración conocida o un teléfono conserva un token de Google o Microsoft y no conecta al nuevo servidor IMAP.

Prepara instrucciones para el primer día: tras proteger cualquier dato local pendiente, elimina la cuenta antigua, añade la nueva y utiliza los ajustes IMAP y SMTP exactos. TrekMail los publica en ajustes IMAP y SMTP para todos los clientes. Los valores habituales del artículo fuente son:

IMAP host: imap.trekmail.net
IMAP port: 993
SMTP host: smtp.trekmail.net
SMTP port: 465
Username: full email address
Password: mailbox password

Otro detalle: según el artículo fuente, TrekMail utiliza IMAP y no ofrece POP3. En 2026, mantener el estado compartido entre dispositivos suele resultar más útil que el modelo antiguo de descargar y eliminar mensajes.

Si administras muchos dominios o entornos de clientes, esta fase de soporte se complica rápidamente. La organización operativa importa entonces tanto como la herramienta de migración. Para planificar esa parte, consulta el alojamiento de correo multidominio.

7. Decide si hace falta trasladar todo el histórico

Una lista bien planteada a veces recomienda «no migrarlo todo». Si los usuarios apenas consultan una década de mensajes, exportar un archivo y empezar con un buzón más limpio puede reducir riesgos, acortar la transición y limitar el alcance de posibles incidencias.

Este punto suele evitarse porque requiere conversaciones difíciles. Pero trasladar 15 años de recibos, boletines y proyectos cerrados en una migración activa consume tiempo y aumenta el riesgo de fallo. Si el archivo apenas se usa, sácalo de la ruta crítica, respetando las necesidades de conservación.

La diferencia entre ambos enfoques es sencilla:

Enfoque tradicional: seguir pagando por usuario porque un buzón contiene 40 GB de histórico que nadie abre.

Enfoque nuevo: archivar lo que ya no es operativo, migrar lo que los usuarios necesitan y utilizar almacenamiento compartido para reducir la presión de ampliar licencias por un único buzón grande.

Por eso TrekMail puede encajar al reorganizar muchos buzones. Según el artículo fuente, se puede empezar gratis, los planes de pago parten de $3.50/mes y ofrecen una prueba gratuita de 14 días que requiere tarjeta de crédito. Nano se describe sin tarjeta y gratuito; confirma las condiciones actuales.

Lista de comprobación para migrar correo: procedimiento final

Esta versión breve puede incorporarse a una solicitud de cambio. Reúne controles básicos para reducir los fallos habituales de una transición IMAP en producción.

1. Inventaría todos los buzones, alias, buzones compartidos, grupos, rutas y aplicaciones de envío.
2. Confirma qué trasladará IMAP y qué necesita una exportación aparte.
3. Copia el correo antiguo antes del cambio.
4. Reduce el TTL de MX con 24 a 48 horas de antelación.
5. Prepara una autorización SPF temporal para ambos sistemas si los dos enviarán durante la transición.
6. Ejecuta la sincronización incremental final antes de cambiar los MX; mantén el servidor antiguo disponible y repite la sincronización para recoger las entregas posteriores hasta completar la validación.
7. Valida con recuentos, revisión de carpetas y pruebas reales de envío y recepción.
8. Reconstruye los perfiles que lo necesiten. No dediques horas a reparar configuraciones obsoletas en caché.
9. Archiva el histórico sin uso en vez de migrar automáticamente contenido innecesario.
10. Mantén acceso al sistema antiguo para una posible reversión hasta terminar la validación.

Ese es el objetivo de una lista de comprobación para migrar correo: no la elegancia ni la teoría, sino reducir las sorpresas.

Si buscas un destino que facilite las migraciones IMAP, compara los precios de TrekMail. Según el artículo fuente y el plan, ofrece dominios propios, buzones IMAP, catch-all, SMTP propio o gestionado, reenvío de buzones y una herramienta de migración integrada, sin facturación por usuario. Verifica las funciones y condiciones vigentes.