¿Perdemos correo mientras cambia el registro MX?

No, si preparas la ventana. Baja el TTL del MX a 300 segundos al menos dos días antes del corte, porque un TTL más corto empieza a aplicar solo cuando expira el valor anterior. Después deja los buzones de cPanel funcionando unas dos semanas tras el cambio, para que lo entregado al hosting viejo durante la ventana de caché del DNS siga existiendo, y una pasada delta del servicio de migración lo trae a Workspace.

¿Los contactos, calendarios, filtros y reenvíos pasan desde cPanel?

No. Una migración IMAP con el servicio de migración de datos mueve únicamente el correo y las etiquetas, así que los eventos de calendario, los contactos, los archivos de Drive y los Sites quedan fuera. Los filtros, respuestas automáticas, reenvíos, alias, listas de correo y el catch-all son configuración y no mensajes, y se reconstruyen a mano en la configuración de Gmail y en la consola de administración. Por eso el inventario va antes que todo lo demás.

¿Podemos dejar los buzones del hosting como MX de respaldo?

Conserva los buzones, pero no conserves el registro MX viejo. Dejar el servidor del hosting en el DNS como respaldo con prioridad menor significa que el correo sigue llegando a un sistema que nadie revisa y que nadie autentica. Borra el MX del hosting en el corte, deja los buzones en su lugar para no perder lo que se entregue durante la ventana de caché del DNS, corre una última migración delta y cancela el correo del hosting después de eso.

Migrar el correo de cPanel a Google Workspace

Imagina una importadora de 14 personas en San Salvador. Su correo vive en hosting compartido desde 2016: once buzones en cPanel, un webmail que nadie disfruta, una cuota de 2 GB por cuenta que contabilidad rebasó hace dos años y facturas que este trimestre empezaron a caer en el spam de los clientes. Quieren Google Workspace. Y antes que nada quieren escuchar que nadie va a perder ocho años de correo.

Esa es la objeción real y es razonable. La migración en sí es trabajo de rutina. El miedo no lo es, porque en estos proyectos sí se pierde correo, casi siempre por una de dos razones: se movió el DNS antes de copiar los buzones, o nadie anotó qué estaba enviando el hosting viejo en nombre de la empresa.

Este es el orden en que trabajamos cuando el punto de partida es cPanel o cualquier otro correo de hosting compartido, qué copia de verdad la herramienta de Google y dónde se rompen las cosas sin que te des cuenta.

El correo del hosting son dos sistemas y solo uno migra

Los buzones son un sistema. La configuración alrededor de ellos es otro: reenvíos, respuestas automáticas, filtros, alias, listas de correo y la cuenta catch-all. El servicio de migración de datos de Google llega al primero por IMAP y no ve el segundo en absoluto. Cuando el origen es un servidor IMAP, el servicio mueve únicamente el correo y las etiquetas. Los eventos de calendario, los contactos, los archivos de Drive y los Sites no forman parte de una migración IMAP. Todo lo que en cPanel es configuración y no un mensaje se vuelve a construir a mano en la consola de administración, y eso está bien siempre que alguien lo haya anotado antes.

Conviene conocer tres límites antes de prometer nada. La ruta IMAP del servicio de migración admite hasta 100 usuarios de origen. Los mensajes de más de 25 MB con adjuntos incluidos no se migran. Las carpetas IMAP compartidas o públicas no son compatibles. En una empresa pequeña los dos primeros casi nunca estorban, pero el techo de 25 MB sí, justo en el buzón que te imaginas: el que recibe contratos escaneados.

El inventario, antes de crear nada

Abrimos una hoja y la llenamos desde el panel, no de memoria:

Cada buzón, su tamaño actual y su cuota. El tamaño te dice cuánto tardará la copia. La cuota te dice qué cuentas llevan tiempo rechazando correo en silencio.
Cada alias, reenvío y lista de correo, con su destino.
Cada filtro y respuesta automática, incluidos los que configuró desde el webmail alguien que ya no trabaja ahí.
La configuración del catch-all. En hosting compartido suele estar activa, así que las direcciones mal escritas llevan años llegando a algún lado.
Cada aplicación que envía con el dominio: el proveedor de facturación o DTE, la tienda en línea, el CRM, el formulario de contacto del sitio, el escáner del pasillo.
Los registros MX, SPF, DKIM y DMARC actuales, con sus valores de TTL.
Quién controla de verdad el registrador y la zona DNS. Este es el punto que atrasa los cortes.

La lista de aplicaciones es la que todos se saltan, y es la que produce la llamada de "todo funciona menos las facturas" una semana después.

Crea los usuarios como los vas a pagar

Cada persona real recibe un usuario. Las direcciones compartidas como info@ o ventas@ se vuelven grupos, no cuentas con una contraseña que conocen tres personas. Los alias se quedan como alias sobre el usuario que los lee. Una empresa que viene de hosting compartido casi siempre tiene muchas más direcciones que personas, y la diferencia entre modelar eso bien y crear un usuario con licencia por cada dirección es buena parte del costo del primer año.

Verifica el dominio con el registro TXT que te da Workspace, crea los usuarios y detente ahí. El MX se queda donde está.

Copia el correo con el sistema viejo todavía en vivo

El servicio de migración de datos se conecta al servidor del hosting por IMAP y copia hacia los buzones nuevos mientras el correo sigue llegando con normalidad a cPanel. No se interrumpe nada, así que no hay por qué apurar esta etapa. Necesitas el nombre del servidor de correo, el puerto de IMAP sobre TLS y la contraseña de cada buzón o una credencial administrativa que tu proveedor permita para migraciones.

Servidor origen:  mail.ejemplo.com
Puerto:           993 (IMAP sobre TLS)
Por buzón:        dirección + contraseña del panel de hosting

Corre la copia completa varios días antes del corte. Después del corte vuelve a ejecutar el servicio contra el mismo origen. Esa segunda pasada es un delta: recoge todo lo que llegó al hosting viejo mientras tanto, y es el mecanismo que vuelve seguro todo el proyecto. Un buzón de origen con más de 6,000 etiquetas o carpetas también necesita una pasada delta para terminar.

Una revisión antes de empezar: una cuenta no puede recibir más correo del que permite su almacenamiento en Workspace. Si un buzón de cPanel de 40 GB va hacia un plan con menos espacio que eso, la importación se detiene a medio camino, y la solución es cambiar de plan, no reintentar.

Baja el TTL dos días antes, no esa mañana

Este paso decide si tu ventana de corte se mide en minutos o en un día. El TTL de un registro le dice a los resolvers cuántos segundos guardarlo en caché, y un TTL más corto empieza a aplicar solo cuando expira el valor anterior. Si tu registro MX lleva tiempo en 86400, bajarlo esta tarde no sirve esta tarde: los resolvers que ya tenían el registro en caché pueden conservarlo otras 24 horas antes de empezar a respetar el valor nuevo y más corto. Bájalo con al menos dos días de anticipación. Google recomienda 3600 como valor de trabajo, y uno más corto como 300 cuando quieres poder revertir un cambio rápido, que es justo la situación del día del corte.

; valor típico por defecto en hosting compartido
ejemplo.com.   86400   IN   MX   0 mail.ejemplo.com.

; dos días antes del corte: mismo destino, TTL más corto
ejemplo.com.   300     IN   MX   0 mail.ejemplo.com.

El corte, en orden

Confirma que la migración masiva terminó y que los usuarios ya ven su correo viejo en Gmail.
Reemplaza el registro MX con el valor de Google Workspace y borra el MX del hosting. No dejes el viejo como respaldo con prioridad menor, porque así es como el correo sigue llegando a un lugar que nadie revisa.
Manda un mensaje de prueba desde una dirección externa y confirma que llega a Gmail.
Deja los buzones de cPanel en su lugar, recibiendo lo que todavía les llegue.
Corre la migración delta al día siguiente y otra vez una semana después.
Sube el TTL del MX de vuelta a 3600 cuando estés tranquilo.

ejemplo.com.   300   IN   MX   1 smtp.google.com.

Google Workspace usa un solo valor de MX, smtp.google.com. Los registradores no se ponen de acuerdo en cómo escribirlo: algunos piden un punto final y otros esperan la prioridad y el destino juntos en un mismo campo, como 1 smtp.google.com. Los dominios que empezaron en Workspace antes de 2023 pueden conservar el conjunto anterior de registros aspmx, que siguen siendo compatibles, así que no hay necesidad de cambiarlos como parte de este proyecto. Los registros MX nuevos pueden tardar hasta 72 horas en reconocerse en todos lados, aunque con un TTL de 300 segundos ya puesto la mayoría de remitentes te sigue en minutos.

Los días posteriores al cambio son la ventana de doble entrega: algunos remitentes todavía resuelven el registro viejo en caché y entregan a cPanel. Eso es esperable y es inofensivo mientras los buzones viejos sigan existiendo. Borrarlos el día del corte es la forma más común de perder correo de verdad en esta migración. Dos semanas es un plazo razonable, y la cuenta de hosting se cancela solo después de la última pasada delta.

Los remitentes que siguen usando el servidor viejo

Después del cambio de MX, mail.ejemplo.com normalmente sigue resolviendo y sigue aceptando SMTP. Cada aplicación configurada con ese nombre y una contraseña vieja de buzón sigue funcionando, en el sentido de que sigue enviando. Esos mensajes ahora salen por un servidor que el dominio ya no autoriza, y las copias caen en un buzón que nadie abre. Recorre la lista de aplicaciones de tu inventario y reapunta cada una: la tienda, el CRM, el formulario de contacto, el escáner, la plataforma de facturación. En El Salvador el proveedor de DTE también entra en esa lista, y escribimos aparte por qué las facturas electrónicas llegan a spam.

Autentica el mismo día

Un dominio que sale del hosting compartido también deja atrás una reputación de envío compartida, que suele ser una de las razones de la mudanza. Publica la autenticación nueva el día del corte y no el mes siguiente:

ejemplo.com.         300  IN  TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey    300  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc               300  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com"

SPF es un solo registro por dominio. El SPF del hosting se reemplaza, no se apila junto al nuevo, porque tener dos registros TXT de SPF es una falla permanente. El DKIM se genera en la consola de administración, en Gmail, Autenticar correo: elige una llave de 2048 bits si tu proveedor de DNS lo admite, conserva el prefijo de selector google por defecto, publica el registro TXT y regresa a la consola para iniciar la autenticación. Una llave de 2048 bits no cabe en una sola cadena DNS de 255 caracteres, así que se ingresa como varias cadenas entre comillas dentro del mismo registro TXT, algo que algunas interfaces de registrador resuelven por ti y otras no. DMARC arranca en p=none con una dirección de reportes, y el endurecimiento viene después de leer un par de semanas de reportes, que es el tema de pasar DMARC de p=none a p=reject.

Deja el selector DKIM y el include de SPF del hosting viejo en el DNS hasta confirmar que ya nada envía por ese servidor, y entonces bórralos.

Lo que suele salir mal

Se borraron los buzones viejos el día del corte, así que lo que se entregó durante la ventana de caché del DNS se perdió para siempre.
Nunca se recreó el catch-all, y direcciones que antes se aceptaban en silencio ahora rebotan.
Se dio por hecho que los filtros y reenvíos migran. No migran: se reconstruyen en la configuración de Gmail y en la consola de administración.
Alguien esperaba que los contactos y calendarios llegaran con una migración IMAP. Esos se exportan e importan aparte.
Se bajó el TTL la mañana del cambio, así que el registro viejo se quedó en caché el resto del día.

Cómo ayuda Guanacos Tech

Somos una consultoría independiente con ingenieros certificados por Google, trabajando en inglés y español en Norteamérica y Latinoamérica. Hacemos el inventario, corremos la copia IMAP, acompañamos la hora del corte, reconstruimos los reenvíos y filtros, y publicamos SPF, DKIM y DMARC el mismo día, para que el dominio llegue autenticado en lugar de repararse después. Si quieres ver cómo está tu dominio antes de tocar el DNS, el diagnóstico de correo es gratis, un proyecto de Workspace explica el alcance, cómo trabajamos cubre la forma de cotizar, y puedes agendar una llamada en calendar.app.google.

Migrar el correo de cPanel u hosting compartido a Google Workspace sin perder mensajes