Cómo migrar tu correo empresarial a Google Workspace sin perder información (Guía Completa 2026)

Migrar el correo de una empresa es una de esas decisiones que se posponen durante años. No porque nadie vea el problema —el buzón lleno, el correo que llega a spam, el servidor compartido que se cae un martes a las 9 de la mañana— sino porque existe un miedo muy concreto y muy razonable: perder información. Diez años de conversaciones con clientes, cotizaciones, contratos, historiales de soporte. Nadie quiere ser quien firmó el proyecto que borró eso.

La buena noticia es que ese miedo, en 2026, ya no corresponde a la realidad técnica. Una migración a Google Workspace bien planeada no borra nada: copia. El buzón original permanece intacto durante todo el proceso y solo se apaga cuando la empresa ya está operando con normalidad en la nueva plataforma. Lo que sí provoca pérdidas —y lo vemos con frecuencia— es improvisar: cambiar los registros MX un viernes por la tarde sin haber copiado un solo correo antes.

Esta guía está escrita desde la experiencia de ejecutar migraciones empresariales en México: desde despachos de cinco personas hasta operaciones con varios cientos de buzones y dominios en producción. No es un resumen de la documentación de Google. Es el orden real en que se hacen las cosas, lo que suele salir mal y cómo se evita.

¿Por qué migrar a Google Workspace?

El argumento no es el precio. Google Workspace no siempre es la opción más barata frente a un hosting compartido con correo incluido. El argumento es que el correo empresarial dejó de ser un buzón para convertirse en la infraestructura donde ocurre la operación: la evidencia comercial, la coordinación interna, los documentos y la identidad digital de la empresa.

Confiabilidad real, medida en minutos

La diferencia práctica entre un correo alojado en un plan compartido y Gmail empresarial se nota el día que algo falla. En hosting compartido, cuando el servidor se satura o una IP entra en lista negra por otro cliente del mismo servidor, la empresa entera deja de recibir cotizaciones y no hay a quién escalar. Con Google Workspace la disponibilidad es contractual y la entrega de correo no depende de la reputación de vecinos desconocidos.

Seguridad que no depende del usuario

El filtrado de phishing y suplantación de Gmail es el mejor del mercado por una razón simple: procesa un volumen que ningún filtro local puede igualar. A eso se suma verificación en dos pasos obligatoria por política, control de sesiones, alertas de acceso sospechoso y la posibilidad de cerrar remotamente el acceso de un colaborador que deja la empresa —algo que en un servidor POP3 con contraseñas compartidas simplemente no existe.

Colaboración sin versiones perdidas

Drive, Documentos y Hojas de cálculo eliminan el ciclo de 'cotización_final_v3_REVISADA.xlsx' enviado por correo. El archivo vive en un lugar, con historial de versiones y permisos por persona. Cuando alguien sale de la empresa, los archivos se quedan: pertenecen a la organización, no al buzón individual.

Meet, Calendar y Gemini como parte del mismo flujo

Agendar una reunión desde un correo, generar el enlace de Meet automáticamente y tener la sala de juntas sincronizada suena trivial hasta que se compara con la alternativa: tres herramientas distintas, tres facturas y ninguna integración. Gemini, integrado en Gmail y Drive, resume hilos largos, redacta respuestas y consulta documentos internos, lo que en equipos comerciales se traduce en tiempo de respuesta más corto.

Administración centralizada

Desde la consola de administración se crean cuentas, se asignan alias, se aplican políticas de contraseña, se recuperan buzones eliminados y se auditan accesos. Para una dirección general, este es el punto que más pesa: el correo deja de ser un tema del 'muchacho de sistemas' y pasa a ser un activo administrable.

¿Qué sucede durante una migración?

Una migración profesional no es un botón. Es un proyecto corto con fases bien delimitadas, donde cada fase existe para que la siguiente no genere riesgo. Este es el orden que seguimos y la razón de cada paso.

1. 1Levantamiento técnico. Se documenta dónde vive hoy el correo, qué protocolo usa (IMAP, POP3, Exchange), cuántos buzones existen, cuánto pesa cada uno, qué alias y listas de distribución están activas, quién administra el dominio y dónde están alojados los registros DNS. Este último punto es el que más veces se desconoce y el que más retrasa proyectos.
2. 2Diseño de la estructura destino. Se define la nomenclatura de cuentas, qué buzones se convierten en alias (y dejan de costar licencia), qué se vuelve grupo de distribución, quién será administrador y qué unidades organizativas se necesitan para aplicar políticas distintas por área.
3. 3Preparación del dominio. Verificación de propiedad del dominio en Google, creación de usuarios y configuración de autenticación de correo (SPF, DKIM y DMARC) antes de tocar cualquier registro MX.
4. 4Reducción de TTL. Entre 24 y 48 horas antes del corte se baja el TTL de los registros DNS a 300 segundos. Es un paso invisible y es la diferencia entre una ventana de propagación de cinco minutos y una de veinticuatro horas.
5. 5Prueba piloto. Se migran dos o tres buzones reales —normalmente uno de dirección, uno de ventas y uno con volumen alto— y se valida integridad, carpetas, adjuntos y calendarios antes de tocar al resto de la empresa.
6. 6Migración inicial de datos. Se copia el histórico completo con el buzón origen todavía en producción. Nadie deja de trabajar. Según volumen, esta fase puede tomar de unas horas a varios días.
7. 7Cambio de registros MX. Es el corte real. A partir de ese momento el correo nuevo entra a Google Workspace. Se programa en horario de bajo tráfico, típicamente viernes por la noche o inicio de fin de semana.
8. 8Migración delta. Se corre una segunda pasada que copia todo lo que llegó al buzón anterior entre la copia inicial y el corte. Aquí es donde se garantiza que no falte un solo correo.
9. 9Configuración de dispositivos y acompañamiento. Celulares, clientes de escritorio, firmas corporativas, contactos y capacitación al equipo.
10. 10Cierre y desmontaje. Se mantiene el buzón antiguo en solo lectura durante un periodo prudente —recomendamos 30 días— y solo después se da de baja el servicio anterior.

"El buzón origen nunca se apaga el día del cambio. Se apaga cuando la empresa ya lleva semanas operando sin incidentes en la nueva plataforma."

¿Qué información puede migrarse?

Prácticamente todo lo que constituye el histórico operativo de la empresa. Lo importante es saber qué se copia de forma automática, qué requiere tratamiento manual y qué simplemente no tiene equivalente.

Un detalle que conviene decidir antes y no durante: qué buzones realmente necesitan licencia. Cuentas como facturacion@, ventas@ o contacto@ muchas veces pueden operar como alias o grupos de un usuario existente. En una empresa de 40 personas hemos visto reducir 12 licencias innecesarias en el levantamiento, lo que paga buena parte del proyecto.

Migraciones más comunes

El origen determina la dificultad. No es lo mismo copiar buzones IMAP de un hosting compartido que desmontar un Exchange local con reglas heredadas de una década.

Migrar de cPanel a Google Workspace

Es el escenario más frecuente en México: el correo vive en el mismo hosting que la página web. Técnicamente es sencillo —IMAP estándar— pero tiene dos trampas. La primera es la cuota: muchos buzones llevan años al límite y hay correo que nunca se entregó. La segunda, y más delicada, es que al cambiar los MX se suele tocar la misma zona DNS donde vive el sitio web; un error ahí tira el sitio, no solo el correo. Antes de mover nada, se exporta la zona completa.

Migrar de Hostinger a Google Workspace

Similar a cPanel, con la particularidad de que el panel de Hostinger administra tanto el correo como el DNS y a veces el registro del dominio. El reto habitual no es técnico sino de acceso: los credenciales están a nombre de un proveedor que hizo el sitio hace cinco años. Recuperar el control administrativo del dominio suele tomar más tiempo que la migración misma, y por eso es lo primero que verificamos.

Migrar de GoDaddy a Google Workspace

GoDaddy revende su propio correo y, en algunos casos, versiones administradas de Microsoft 365. El punto crítico es que la interfaz oculta los registros MX detrás de configuraciones automáticas: si no se desactiva el correo del proveedor antes del corte, el panel vuelve a escribir sus propios registros y el correo rebota. Se desconecta primero el servicio, se limpia la zona y después se apunta a Google.

Migrar de Zoho Mail a Google Workspace

Zoho permite IMAP, pero exige generar contraseñas de aplicación por usuario y habilitar el acceso desde su consola. El reto real aparece cuando la empresa también usa Zoho CRM o Zoho Desk: ahí no solo se migra correo, se decide qué pasa con los flujos que dependían de esos buzones. Ese análisis debe ocurrir antes, no cuando el correo ya cambió de casa.

Migrar de Microsoft 365 a Google Workspace

Es la migración más completa porque incluye correo, calendarios, contactos, Teams y archivos en OneDrive y SharePoint. La herramienta de migración de Google cubre bien correo y calendario; los archivos requieren un plan aparte y decisiones de gobernanza: qué se convierte en unidad compartida y qué se queda como carpeta personal. Además, las reglas de buzón y las carpetas públicas heredadas no tienen equivalente y deben rediseñarse.

Migrar de Exchange (servidor local) a Google Workspace

El caso más delicado. Suele haber buzones enormes, integraciones con sistemas internos (ERP, escáneres, sistemas de facturación que envían correo por SMTP autenticado) y usuarios acostumbrados a Outlook con archivos PST locales. Aquí conviene una migración por fases con coexistencia temporal: parte de la empresa en Google, parte en Exchange, con enrutamiento controlado. Y hay que inventariar cada equipo o aplicación que envía correo con el dominio, porque el día del corte esos son los primeros en fallar.

¿Se perderán mis correos?

No. Y la razón es estructural: una migración copia, no mueve. Mientras el proceso ocurre, el buzón original conserva absolutamente todo. Si algo saliera mal, el plan de reversión consiste en devolver los registros MX a su valor anterior y la empresa vuelve al punto de partida en cuestión de minutos.

Dicho eso, hay una condición: que la migración esté planeada. Los casos de pérdida real que hemos visto —siempre en proyectos hechos por terceros— comparten el mismo patrón: se cambiaron los registros MX antes de copiar los buzones, y el correo que llegó en esas horas cayó en un destino vacío mientras el histórico seguía en un servidor que después se canceló por falta de pago.

El papel del DNS: MX, SPF, DKIM y DMARC en lenguaje claro

Cuatro registros determinan si el correo llega y si el mundo confía en tu dominio. No hace falta ser administrador de sistemas para entender qué hace cada uno:

• MX: indica a internet a qué servidor entregar el correo dirigido a tu dominio. Es el interruptor del cambio: mientras apunte al proveedor viejo, el correo nuevo llega ahí.
• SPF: declara qué servidores tienen permiso de enviar correo en nombre de tu dominio. Si el CRM, el sistema de facturación o la plataforma de campañas no están incluidos, sus correos empiezan a caer en spam.
• DKIM: firma criptográficamente cada correo saliente para probar que no fue alterado en el camino. En Google Workspace se activa desde la consola y es un paso que se olvida con frecuencia.
• DMARC: define qué debe hacer el receptor cuando un correo no pasa SPF o DKIM, y envía reportes. Se recomienda arrancar en modo observación y endurecer la política semanas después, nunca el mismo día del corte.

Reducir el TTL antes del cambio y validar estos cuatro registros después es lo que hace que la transición se sienta invisible para el equipo comercial. Cuando se hace bien, la mayoría de los usuarios se entera del cambio porque su bandeja se ve distinta, no porque dejó de recibir correos.

Errores más comunes

Todos los que siguen los hemos encontrado en migraciones que llegaron a nosotros para ser rescatadas. Ninguno es exótico.

• Cambiar los MX antes de copiar un solo correo. Es el error más caro y el más frecuente: durante la propagación, el correo entrante se reparte entre dos destinos y nadie sabe dónde quedó qué.
• No respaldar antes de empezar. Aunque la migración copie, el respaldo independiente del buzón origen es la póliza de seguro del proyecto. Cuesta poco y evita conversaciones muy incómodas.
• No reducir el TTL. Con un TTL de 24 horas, la mitad de los proveedores del mundo seguirá entregando al servidor viejo durante un día completo después del cambio.
• Cancelar el hosting anterior el mismo día. El correo antiguo debe permanecer accesible en solo lectura al menos 30 días. Cancelarlo antes convierte cualquier faltante en pérdida definitiva.
• Comprar licencias equivocadas. Asignar Business Standard a todos cuando la mitad opera con alias, o contratar el plan mínimo y descubrir en la semana dos que faltan controles de seguridad o almacenamiento.
• No avisar a los usuarios. Un equipo que no sabe que su correo cambia de plataforma el lunes genera cincuenta tickets el lunes. Un correo interno con instrucciones y una sesión de 30 minutos eliminan casi todos.
• Saltarse la prueba piloto. Migrar 80 buzones de golpe sin haber validado dos es apostar el histórico de la empresa a que la configuración estaba bien a la primera.
• Olvidar los sistemas que envían correo. Escáneres, ERP, tienda en línea, formularios del sitio web y plataformas de facturación autenticaban contra el servidor viejo. El día del corte dejan de enviar y nadie lo relaciona con la migración.
• Ignorar la migración delta. Sin la segunda pasada, todo el correo recibido entre la copia inicial y el corte se queda en el buzón anterior.

Buenas prácticas antes de migrar

Este es el checklist que aplicamos antes de tocar cualquier registro. Si tu proveedor no puede responder a todos estos puntos, la migración todavía no está lista para ejecutarse.

1. 1Confirmar quién tiene el control administrativo del dominio y del DNS, con acceso probado, no supuesto.
2. 2Exportar y guardar una copia completa de la zona DNS actual antes de modificar nada.
3. 3Inventariar buzones con su tamaño real y clasificar cuáles requieren licencia, cuáles pasan a alias y cuáles se archivan.
4. 4Documentar alias, listas de distribución, reglas de reenvío y respuestas automáticas activas.
5. 5Listar todos los sistemas y dispositivos que envían correo con el dominio.
6. 6Generar un respaldo independiente de los buzones críticos, especialmente dirección, ventas y administración.
7. 7Verificar el dominio en Google Workspace y crear los usuarios con la nomenclatura definitiva.
8. 8Configurar SPF, DKIM y DMARC en el destino antes del corte.
9. 9Reducir el TTL de los registros a 300 segundos, entre 24 y 48 horas antes.
10. 10Ejecutar el piloto con dos o tres buzones reales y validar carpetas, adjuntos y calendarios.
11. 11Comunicar la fecha y el plan al equipo, con instrucciones concretas para celular y computadora.
12. 12Definir la ventana de corte en horario de bajo tráfico y dejar por escrito el plan de reversión.

¿Cuánto tarda una migración?

La pregunta correcta tiene dos respuestas distintas: cuánto dura el proyecto y cuánto dura la interrupción para el usuario. La segunda debe ser cercana a cero en todos los escenarios; la primera depende del volumen de datos y del origen.

Los factores que más alargan un proyecto no son los buzones: son el acceso al DNS cuando el dominio está a nombre de un tercero, los buzones históricos de más de 50 GB y las integraciones que envían correo desde sistemas internos. Cuando esos tres puntos se resuelven en el levantamiento, los tiempos de la tabla se cumplen.

¿Cuándo conviene contratar ayuda profesional?

Con dos o tres buzones personales y sin histórico crítico, una migración autogestionada es perfectamente viable. La ecuación cambia cuando el correo es el registro operativo de la empresa.

• Cuando el dominio es crítico: si el correo se cae, se detienen cotizaciones, facturación o soporte a clientes.
• Cuando hay más de diez buzones o histórico de varios años que debe conservarse íntegro.
• Cuando el origen es Exchange, Microsoft 365 o cualquier entorno con reglas, carpetas públicas o integraciones.
• Cuando existen sistemas que envían correo con el dominio y nadie tiene el inventario completo.
• Cuando no hay claridad sobre quién administra el DNS o el registro del dominio.
• Cuando la empresa necesita continuidad garantizada y un plan de reversión por escrito, no buena voluntad.

El costo de una migración profesional casi siempre es menor que el de un día sin correo. Esa es, en la práctica, toda la evaluación financiera que la mayoría de las direcciones necesita hacer.

Cómo trabajamos las migraciones en North

Entregamos un levantamiento técnico documentado, un plan de migración con fecha y ventana de corte definidas, ejecución con piloto y migración delta, configuración completa de SPF, DKIM y DMARC, despliegue de firmas corporativas, capacitación al equipo y acompañamiento durante las primeras semanas de operación. El buzón anterior se mantiene accesible hasta que la empresa confirma que todo está en su lugar.