Si intentas migrar el correo de Google Workspace de forma incorrecta, el lunes por la mañana tendrás entregas divididas, alias ausentes y usuarios molestos. Es una operación de cambio de servicio, no una simple exportación mediante arrastrar y soltar. Si antes necesitas una visión más amplia para decidir, consulta correo empresarial. Si ya estás preparando el traslado, este procedimiento explica cómo migrar el correo de Google Workspace a un host IMAP como TrekMail sin interrumpir la recepción.
La trampa es sencilla: los administradores se concentran en copiar los mensajes antiguos y olvidan la capa de enrutamiento. Al correo no le importa que la migración esté completada al 92%. En cuanto cambian los registros MX, los mensajes nuevos deben llegar a algún sitio. Si los alias, grupos, DNS y clientes no están listos en ese mismo momento, aparecen dos bandejas de entrada paralelas. Los usuarios siguen enviando mensajes, los clientes siguen respondiendo y parte del correo termina donde no corresponde.
La solución está en el orden. Primero haz el inventario. Después prepara los datos. Cambia el DNS una sola vez. Vuelve a configurar los clientes correctamente. Por último, verifica por cantidad de elementos, no por intuición. TrekMail encaja en este modelo porque ofrece almacenamiento compartido, alojamiento multidominio con tarifa fija, migración IMAP integrada y compatibilidad con clientes IMAP/SMTP estándar sin cobrar por usuario.
¿Qué significa migrar el correo de Google Workspace?
Para migrar el correo de Google Workspace, debes trasladar los mensajes almacenados mediante IMAP y después cambiar el enrutamiento del correo activo de Google al nuevo proveedor. La copia es importante, pero el cambio lo es aún más. Si modificas el enrutamiento antes de preparar identidades, DNS y clientes, los mensajes empezarán a llegar a bandejas equivocadas.
Esta diferencia importa porque Google Workspace reúne varios tipos de identidad bajo una misma interfaz de administración. Una cuenta de acceso no equivale a todas las direcciones que reciben correo para esa persona. Los alias compartidos, direcciones de grupos, reenvíos y reglas catch-all pueden afectar al cambio.
Antes de tocar el DNS, prepara correctamente el destino. En TrekMail, esto suele implicar añadir el dominio, confirmar los registros DNS, crear cada buzón y decidir qué direcciones deben seguir como alias y cuáles necesitan un buzón propio. Estos recursos ayudan con la preparación: añade un dominio, comprueba los registros DNS necesarios y revisa cómo gestiona TrekMail las migraciones desde Gmail.
Fase 1: prepara un inventario exhaustivo antes de copiar
Al migrar el correo de Google Workspace, la primera tarea real es localizar todas las direcciones capaces de recibir mensajes. Los usuarios principales son evidentes. Los fallos suelen esconderse en los alias, grupos y reglas de enrutamiento antiguas. Si omites esas direcciones, el cambio de DNS las convertirá en rechazos definitivos o destinos sin salida.
Empieza con cuatro listas:
- Usuarios principales y tamaño de sus buzones.
- Todos los alias asociados a cada usuario.
- Grupos de Google que todavía reciben correo real.
- Reenvíos, direcciones catch-all y direcciones retiradas que aún aparecen en facturas, formularios de contacto o firmas.
Por eso una simple exportación del panel de administración no basta. Una comercial puede acceder como jane@company.com y seguir recibiendo correo en sales@company.com, quotes@company.com y en un antiguo dominio adquirido que nadie documentó. Si olvidas uno, parecerá que el cambio ha fallado aunque el DNS esté bien. Para migrar limpiamente el correo de Google Workspace, toda dirección enrutable debe tener un destino.
Al extraer datos de Google, los operadores suelen recurrir a GAM o al SDK de administración para crear un mapa completo de enrutamiento. La herramienta concreta importa menos que el resultado: cada dirección enrutable debe contar con un destino explícito en el nuevo sistema antes de migrar el correo de Google Workspace.
gam print users aliases > aliases.csv
gam print groups members > group_members.csvMientras organizas las direcciones, decide qué será cada identidad en el nuevo host:
| Tipo de dirección | Método anterior | Método nuevo |
|---|---|---|
| Usuario principal | Copiar primero el correo y confiar en que el enrutamiento se adapte | Crear primero el buzón e importar después el correo al buzón de destino exacto |
| Alias de usuario | Ignorarlo porque no sirve para iniciar sesión | Crearlo como alias o regla de reenvío antes del cambio |
| Bandeja compartida de equipo | Dejarla como Grupo de Google y confiar en la suerte | Decidir si debe ser un buzón, un alias o una ruta de reenvío |
| Dirección retirada todavía activa | Descubrirla después de las quejas de los clientes | Asignarla durante el inventario y mantener la recepción |
Si necesitas un criterio rápido para asignar identidades, consulta alias de correo del dominio frente a buzón. Muchos errores de migración empiezan ahí.
Fase 2: prepara los datos porque Google limita IMAP
Para migrar correo de Google Workspace a una escala considerable, necesitas una fase de precarga. Google documenta límites de ancho de banda IMAP que restringen la cantidad de datos que puedes descargar y cargar por cuenta y día. Los buzones grandes no terminarán en un solo fin de semana, por muy optimista que sea el plan.
Google publica los límites de ancho de banda de Gmail para las cuentas de Workspace: la descarga por IMAP es de 2,500 MB al día y la carga por IMAP, de 500 MB al día. Es una restricción real de la migración, no una recomendación. Un buzón de 50 GB puede tardar semanas si descargas todo el historial mediante IMAP.
El patrón correcto es el siguiente:
- Precargar el correo antiguo mientras los usuarios siguen trabajando en Google.
- Ejecutar sincronizaciones incrementales durante los días previos al cambio.
- Mover el correo más reciente después de cambiar el DNS o durante la sincronización final.
Para usuarios con mucho correo, divide el trabajo por intervalos de fechas si la herramienta lo permite. El flujo de migración de TrekMail admite importaciones por etapas mediante su sistema de migración IMAP. Así resulta mucho más práctico migrar el correo de Google Workspace por lotes en lugar de descargar a ciegas todo el historial.
Ejemplo: si contabilidad tiene un buzón de 36 GB, pero solo necesita de inmediato los últimos 90 días, importa primero las carpetas recientes, cambia el flujo de correo y completa el archivo cuando el entorno de producción sea estable.
Las indicaciones actuales de Google sobre el acceso también son importantes. La autenticación básica antigua ya no está disponible en la mayoría de los casos, salvo la principal excepción de las contraseñas de aplicaciones en configuraciones compatibles. Para migraciones con Gmail como origen, la documentación vigente de TrekMail indica que se utilice una contraseña de aplicación de Gmail en vez de la contraseña normal de la cuenta cuando lo exija la política de Google. Consulta la ayuda de Google sobre contraseñas de aplicaciones.
Fase 3: cambia el DNS una vez y en el orden correcto
Al migrar el correo de Google Workspace, el DNS es el punto de cambio que decide dónde llegan los mensajes nuevos. Reduce el TTL con antelación, publica los nuevos registros de autenticación y modifica los MX solo cuando los buzones y alias de destino ya existan. Si inviertes el orden, crearás una entrega dividida.
La secuencia correcta es deliberadamente previsible. Dos días antes del cambio, reduce a 300 segundos el TTL de MX, SPF y DMARC. Un día antes, publica el DKIM del proveedor de destino. En el momento del cambio, sustituye los MX de Google por los de TrekMail. Después comprueba la propagación desde un resolvedor público en vez de confiar en la caché de tu equipo.
; Transitional SPF while some devices still send through Google
v=spf1 include:_spf.google.com include:spf.trekmail.net -alldig @1.1.1.1 example.com MX +shortDurante el periodo de solapamiento, conserva Google y TrekMail en SPF si todavía puede salir correo a través de ambos sistemas. Esto coincide con RFC 7208. Vigila el límite de 10 consultas DNS. Si el registro ya está saturado de proveedores, simplifícalo antes de migrar el correo de Google Workspace.
Si vas a repetir el proceso en muchos dominios de clientes, aquí es donde TrekMail comienza a compensar. El método anterior consiste en editar el DNS y la configuración de buzones dominio por dominio mientras pagas por usuario. El nuevo ofrece una plataforma de tarifa fija con control multidominio, almacenamiento compartido, un asistente de DNS y migración integrada.
Fase 4: corrige los clientes, no solo la contraseña
Después de migrar el correo de Google Workspace, muchas solicitudes de soporte parecen fallos de contraseña, pero no lo son. Los clientes configurados para Google suelen conservar supuestos de OAuth, datos de detección automática en caché o ajustes predefinidos del proveedor anterior. Los usuarios necesitan una configuración IMAP limpia que apunte al nuevo host, no intentos desesperados de contraseña.
Los dispositivos móviles y Outlook son los más afectados. En el teléfono, los usuarios suelen tocar el logotipo de Google durante la configuración porque les resulta familiar. Después del cambio, esa opción es incorrecta. En Outlook, los perfiles antiguos pueden seguir intentando conectarse a Google incluso cuando los MX ya apuntan a otro sitio.
Usa la configuración IMAP directa de TrekMail:
Incoming server: imap.trekmail.net
Port: 993
Security: SSL/TLS
Username: full email address
Password: mailbox passwordEn iPhone y Android, indica a los usuarios que eliminen la antigua cuenta de Google y vuelvan a añadir el buzón como Otra o IMAP. En Outlook para escritorio, crea un perfil de correo nuevo en lugar de reparar el anterior. Para conocer los pasos exactos, las guías de clientes de TrekMail explican la configuración IMAP/SMTP. Puedes complementarlas con la guía publicada sobre imapsync si necesitas un proceso de migración más manual.
Un detalle más: TrekMail ofrece alojamiento IMAP basado en estándares. No admite POP3 ni pretende ser Exchange. Si un dispositivo o usuario insiste en emplear los flujos propios de Google o Microsoft, perderás tiempo con el protocolo equivocado.
Fase 5: verifica con recuentos y mantén sencilla la reversión
Para migrar de forma segura el correo de Google Workspace, verifica el estado de cada buzón mediante los recuentos por carpeta y el flujo de correo activo, no por gigabytes totales. La vista de almacenamiento de Google incluye compresión y factores ajenos al correo que no se corresponden de forma directa con un destino IMAP. Cuenta mensajes. Confirma la recepción y el envío nuevos. Después da por terminado el cambio.
La lista de comprobación mínima debe ser esta:
- Los recuentos de carpetas son suficientemente parecidos en todos los buzones críticos.
- Tras propagarse los MX, los mensajes de prueba entrantes llegan únicamente a TrekMail.
- El correo saliente supera las comprobaciones de SPF, DKIM y DMARC.
- Los alias y direcciones compartidas entregan exactamente donde corresponde.
- Los usuarios pueden iniciar sesión en equipos de escritorio y móviles con la nueva configuración.
Las pequeñas diferencias de recuento pueden ser normales. Los mensajes dañados, las invitaciones rotas y ciertos elementos extraños sin contenido no siempre sobreviven a IMAP. Lo que no es normal es que el correo entrante nuevo siga llegando a Google cuando crees que has terminado. Si sucede, todavía no has completado la migración desde Google Workspace.
La reversión debe ser directa y rápida. Si la recepción falla de forma generalizada, vuelve a apuntar los MX a Google mientras el TTL siga bajo. Después exporta los mensajes que hayan llegado al nuevo host durante el periodo problemático y vuelve a introducirlos si es necesario. Un plan de reversión que no puedas ejecutar en cinco minutos no es un verdadero plan de reversión.
Método anterior frente al nuevo: por qué los operadores eligen TrekMail
Si migras correo de Google Workspace con frecuencia, el coste real no es solo el precio de las licencias. También incluye el trabajo administrativo repetido con dominios, creación de buzones, reconfiguración de clientes y reintentos de migración. TrekMail reduce ese trabajo con un modelo multidominio de tarifa fija diseñado para operadores, no para hojas de cálculo por usuario.
| Paso | Método anterior | Método nuevo con TrekMail |
|---|---|---|
| Aprovisionamiento | Crear y presupuestar buzones usuario por usuario | Crear buzones IMAP en una única plataforma de tarifa fija |
| Almacenamiento | Controlar límites y ampliaciones por usuario | Usar almacenamiento compartido en toda la cuenta |
| Migración | Comprar o programar herramientas independientes | Usar la herramienta de migración IMAP integrada en los planes de pago |
| Operaciones de dominio | Gestionar cada dominio en un panel de administración separado | Controlar varios dominios desde un único panel |
| Costes | Seguir pagando por usuario | Empezar en $3.50/month con Starter y ampliar por plan, no por puesto |
TrekMail ofrece dominios personalizados, buzones IMAP, compatibilidad catch-all, reenvío de buzones, SMTP propio o incluido según el plan y migración del lado del servidor. El plan Nano es siempre gratuito y no requiere tarjeta. Los planes de pago incluyen una prueba gratuita de 14-day, que sí exige una tarjeta de crédito. Si hoy administras una marca y el próximo trimestre gestionas veinte dominios de clientes, ese modelo de precios marca la diferencia entre conservar margen o crear un caos.
Para los equipos que manejan muchos buzones a la vez, la ventaja operativa se parece mucho al alojamiento de correo multidominio: un solo panel, menos piezas móviles y ninguna trampa de coste por usuario cada vez que un cliente añade otro buzón.
Si quieres migrar el correo de Google Workspace sin convertir el cambio en una emergencia de fin de semana, empieza por los precios de TrekMail. Prepara primero el destino. Precarga el correo. Cambia el DNS una vez. Después verifica como un profesional.