¿Vamos a perder correo durante el cambio de MX?

No, si bajas el TTL del MX a 300 segundos dos días antes y dejas los buzones viejos encendidos una semana. Durante esa ventana algunos remitentes todavía llegan al servidor anterior porque su resolver guardó el registro viejo, así que ambos sistemas siguen recibiendo, y una segunda pasada incremental del servicio de migración trae a Workspace lo que quedó atrás.

¿El servicio de migración de datos puede mover un buzón personal de Hotmail u Outlook.com?

No. El origen Exchange Online es para un tenant de Microsoft 365, y las cuentas personales son cuentas de consumidor. Además, desde que Microsoft empezó a retirar la autenticación básica en las cuentas personales de Outlook, Hotmail y Live el 16 de septiembre de 2024, las herramientas que entran por IMAP con usuario y contraseña ya no conectan, así que esos buzones se copian con un cliente de escritorio que soporte autenticación moderna.

¿Qué no sobrevive a la migración?

Las reglas de Outlook, las firmas, las definiciones y asignaciones de categorías, la estructura de carpetas de contactos, el texto con formato en la descripción de eventos, los colores y la zona horaria del calendario, y los mensajes de más de 25 MB con adjuntos incluidos. Los calendarios compartidos se importan solo para su dueño y las tareas recurrentes llegan como tareas únicas.

Migrar de Hotmail o Microsoft 365 a Google Workspace

La pregunta siempre llega con la misma forma. "Si cambiamos el registro MX y algo sale mal, ¿perdemos el correo?" Es una pregunta justa, y la respuesta honesta es que sí se pierde correo en las migraciones, por dos razones: alguien mueve el DNS antes de copiar los buzones, o nadie anotó qué sistemas enviaban correo a nombre de la empresa. Las dos se evitan con una hora de preparación.

Este es el orden que usamos para mover a una empresa pequeña de Hotmail, Outlook.com o Microsoft 365 a Google Workspace. Funciona igual con cinco buzones que con ochenta. Casi todo se hace con herramientas que ya vienen en Workspace, y donde esas herramientas se quedan cortas, lo decimos.

Qué se migra y qué vas a rehacer a mano

El servicio de migración de datos de Google, dentro de la consola de administración, copia correo desde otra cuenta de Google Workspace, desde una cuenta de Microsoft Exchange Online, desde una cuenta IMAP o desde una sola cuenta personal de Gmail. Desde Exchange Online se traen las carpetas y subcarpetas y el nivel de importancia de cada mensaje. Desde un servidor IMAP se traen carpetas y subcarpetas. Desde una cuenta de Google se traen etiquetas, subetiquetas y destacados.

La lista útil es la otra, la de lo que no se migra, porque cada punto es una pequeña sorpresa el lunes después del cambio:

Los mensajes de más de 25 MB, contando adjuntos, se saltan. También los tipos de archivo que Gmail no acepta, como los ejecutables.
Las reglas. Ni las del servidor ni las del cliente de Outlook se migran. Se rehacen como filtros de Gmail.
Las firmas. Se vuelven a crear por usuario, que es buen momento para dejarlas parejas.
Las categorías. Ni las definiciones ni las asignaciones en cada mensaje se importan.
Las carpetas de contactos. Los contactos sí se migran, todos, pero llegan en un solo montón. La estructura de carpetas no viaja: en Google se reemplaza con etiquetas.
Detalles del calendario. El texto con formato en la descripción de los eventos, los colores del calendario y la zona horaria no se importan. Un calendario compartido se importa solo para quien es su dueño, no para todos los que lo tenían compartido.
Las tareas. Una tarea recurrente llega como una tarea única, una hora de vencimiento se vuelve una tarea de todo el día y los adjuntos de tareas no se admiten.

Nada de esto es motivo para no migrar. Es motivo para entregarle a cada persona una lista corta antes del cambio, para que su primer día en Gmail sea trabajar y no andar buscando su firma.

Antes de tocar el DNS: el inventario

Abre una hoja de cálculo y llena cuatro columnas antes que nada.

Buzones y direcciones. Cada buzón, cada alias, cada lista de distribución, cada buzón compartido, cada reenvío. En Workspace se convierten en usuarios, alias y grupos, y todos tienen que existir antes de cambiar el MX. El correo dirigido a una dirección que Google no conoce se rechaza en la puerta.
Todo lo que envía con tu dominio. El sistema de facturación, el CRM, la tienda en línea, el formulario del sitio, el escáner de la oficina que manda PDF, las alertas de monitoreo. Esta columna es la que se olvida, y es la que provoca la llamada de "ahora las facturas caen en spam" dos semanas después.
El DNS actual. Guarda lo que está publicado hoy, antes de editar nada.
Quién controla el registrador. Ubica ya a la persona que tiene el acceso, no a las 8 de la mañana del día del cambio.

dig +short MX ejemplo.com
dig +short TXT ejemplo.com
dig +short TXT _dmarc.ejemplo.com
dig +short CNAME autodiscover.ejemplo.com

Guarda esa salida. Es tu plan de retorno, y es la materia prima del SPF que vas a publicar después. Si en la columna dos tienes más de tres o cuatro sistemas, lee cómo quedarte debajo del límite de 10 consultas DNS del SPF antes de escribir un solo registro, porque una migración es justo el momento en que los dominios se pasan de ese límite.

Cómo correr el servicio de migración de datos

En la consola de administración la ruta es Migración de datos y ahí eliges el origen. Para un tenant de Microsoft 365, elige el origen Exchange Online y conéctalo con OAuth, que es el método actual y elimina el viejo paso del certificado. Una ejecución cubre hasta 1,000 usuarios de Google Workspace, hasta 1,000 usuarios de Exchange Online, hasta 100 cuentas IMAP o una sola cuenta personal de Google.

Dos costumbres importan más que la configuración:

Empieza la copia varios días antes del cambio. El sistema viejo sigue recibiendo correo mientras tanto. Copiar un buzón no lo mueve, así que empezar temprano no tiene riesgo y logra que la parte lenta ya esté lista cuando alguien esté esperando.

Corre una segunda pasada después del cambio. Todo lo que llegó al buzón viejo entre la primera copia y el cambio de DNS sigue ahí. Una pasada incremental lo recoge. Después lee bien el reporte de migración: que la pantalla diga "completado" no es lo mismo que tener un conteo por carpeta igual al del origen. Compara los conteos de los dos o tres buzones más grandes antes de decirle a alguien que ya se puede apagar el sistema viejo.

Las cuentas personales de Hotmail, Outlook.com y Live son otro trabajo

Un buzón personal @hotmail.com o @outlook.com es una cuenta de consumidor de Microsoft, no un tenant de Exchange Online, así que la ruta de Exchange en la consola no aplica. Queda IMAP, y Microsoft la angostó: el 16 de septiembre de 2024 empezó a retirar la autenticación básica para las cuentas personales de Outlook, Hotmail y Live, así que cualquier herramienta de migración que entre a IMAP con usuario y contraseña ya no conecta.

Lo que sí funciona es un cliente de correo de escritorio que inicie sesión con autenticación moderna, con las dos cuentas configuradas al mismo tiempo, y copiar las carpetas de una a otra dentro del cliente. Es más lento y es buzón por buzón, así que contempla ese tiempo desde el principio en lugar de descubrirlo el mismo día. Después deja un reenvío en la cuenta personal por un mes o dos mientras los contactos aprenden la dirección nueva.

Si el dominio de la empresa hoy apunta a una cuenta personal, trata esa limpieza como parte del proyecto. Es el cambio que más mejora la forma en que los servidores que reciben juzgan el correo de la empresa.

El cambio de MX, en orden

48 horas antes. Baja el TTL de los registros MX a 300 segundos. Si lo dejas en una hora o más, los resolvers que guardaron el valor viejo siguen entregando al servidor anterior mucho después de que tú ya cambiaste.
El día antes. Confirma que cada usuario, alias y grupo existe en Workspace y que cada persona ya inició sesión al menos una vez.
Coexistencia, si la necesitas. Si la mudanza va por olas, configura antes la entrega dual o la entrega dividida en los ajustes de enrutamiento de la consola, para que el correo de quienes todavía no se mueven les siga llegando.
El cambio. Borra los registros MX viejos y publica los de Google. Los dominios nuevos pueden usar la forma de un solo registro. Los dominios viejos pueden seguir con el conjunto de cinco, y está bien, pero nunca dejes los registros del proveedor anterior junto a los de Google.

; Google Workspace, forma de un solo registro MX
ejemplo.com.    300    IN    MX    1 smtp.google.com.

Dentro de la primera hora. Manda un mensaje de prueba en cada dirección, uno desde fuera hacia adentro y otro desde un buzón de Workspace hacia afuera.
La semana siguiente. Deja los buzones viejos encendidos y revísalos a diario. Lo que llegue ahí viene de un resolver con caché vieja, y hay que ir a recogerlo.

Antes de decirle al equipo que ya está, revisa qué está respondiendo el dominio en este momento. Una mirada desde fuera a los registros MX, SPF, DKIM y DMARC atrapa los dos errores clásicos del cambio: un registro que quedó del proveedor anterior y un SPF que nunca se actualizó.

Autentica el mismo día, no el mes siguiente

Una migración es un evento de reputación. Tu dominio empieza a enviar desde una infraestructura nueva y los servidores que reciben lo notan. Publica los tres registros el día del cambio.

SPF. Un solo registro para el dominio, con Google más cada sistema de la columna dos de tu inventario, y sin nada que ya no envíe.

ejemplo.com.        3600 IN TXT "v=spf1 include:_spf.google.com ~all"
_dmarc.ejemplo.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@ejemplo.com"

DKIM. En la consola, en Apps, Google Workspace, Gmail, entra a Autenticar correo, genera un registro nuevo y elige la llave de 2048 bits si tu proveedor de DNS acepta un TXT de ese largo. El prefijo de selector por defecto es google. Publica el registro TXT en tu DNS y regresa a iniciar la autenticación. La consola puede seguir mostrando el aviso de "actualiza los registros DNS" hasta 48 horas después de que el registro ya está publicado, así que no regeneres la llave por nervios.

DMARC. Arranca en p=none con una dirección de reportes, lee dos semanas de reportes y después aprieta. Saltar directo a la política estricta recién migrado es la forma más rápida de que desaparezcan las facturas y el correo del CRM. La secuencia está en nuestra guía para pasar DMARC de p=none a p=reject.

Deja el include del proveedor anterior en el SPF hasta confirmar que ya nada envía por ahí, y borra los registros de autodiscover que sobraron solo cuando el último cliente de Outlook haya desaparecido.

Cuánto tarda

La copia de los buzones es la parte larga y corre sola. Las partes que necesitan a una persona son el inventario, la hora del cambio y la autenticación, y se miden en horas, no en semanas. Para una empresa de cinco a veinte personas el proyecto completo suele caber en una semana, y el cambio de DNS en sí toma minutos. Las licencias de Workspace las cobra Google por usuario; el trabajo de migración va aparte, y cómo lo definimos y lo cotizamos está escrito.

Cómo ayuda Guanacos Tech

Somos una consultora independiente con ingenieros certificados por Google, trabajando en español e inglés en Norteamérica y Latinoamérica. Hacemos el inventario, corremos la migración, acompañamos la hora del cambio y publicamos SPF, DKIM y DMARC el mismo día, para que el dominio quede autenticado desde el arranque y no reparado después. Si quieres una segunda opinión antes de tocar el DNS, empieza con el diagnóstico de correo gratuito, revisa qué cubre un proyecto de Workspace o agenda una llamada en calendar.app.google.

Cómo migrar de Hotmail, Outlook o Microsoft 365 a Google Workspace sin perder un solo correo