¿Cuánto tarda una migración de Microsoft 365 a Google Workspace?

La copia en sí depende de cuántos buzones tengas y cuántos datos guarde cada uno, y para Exchange Online el servicio de migración de datos trabaja hasta con 250 usuarios a la vez, así que las empresas más grandes lo corren por tandas. Lo que conviene planificar son los tiempos fijos: el TTL actual del registro MX manda sobre qué tan rápido surte efecto el corte, los registros MX nuevos pueden tardar hasta 72 horas en reconocerse, la llave DKIM de Workspace no se puede generar hasta 24 a 72 horas después de activar Gmail, y DKIM puede tardar hasta 48 horas en empezar a funcionar una vez publicado.

¿Vamos a perder correo mientras cambia el registro MX?

No, si las cuentas existen primero y el traslape está armado. Crea todas las cuentas de Workspace antes de tocar el DNS, baja el TTL del MX un día antes y durante la transición usa entrega dual, donde el sistema viejo conserva el registro MX y reenvía a Google, o entrega dividida, donde Google tiene el MX y enruta a ciertos destinatarios hacia el otro lado. Después del cambio, una pasada delta recoge lo que llegó al sistema viejo durante el corte.

¿Qué pasa con nuestros buzones compartidos?

Google no tiene un equivalente idéntico, así que cada uno necesita una decisión. Un grupo de Google configurado como Bandeja de entrada colaborativa le queda bien a una cola que atiende un equipo, porque los miembros reciben en una sola dirección y pueden asignarse conversaciones. Una cuenta delegada le queda bien a una dirección con historia larga que responde casi siempre la misma persona, porque los demás la abren desde su propio Gmail. Decídelo antes de correr la migración, no después, porque la respuesta cambia dónde queda el historial.

Migrar de Microsoft 365 a Google Workspace: lista completa

La semana siguiente a la mudanza es la que manda

Digamos que una distribuidora de 22 personas lleva años en Microsoft 365, desde que lo configuró alguien que ya no trabaja ahí. Decidir el cambio a Google Workspace toma una tarde. La mudanza también sale bien, durante una semana más o menos. Después empiezan las llamadas: la dirección de contabilidad que ya nadie puede abrir, y las notas de entrega del sistema de bodega que ahora caen en spam, porque nadie lo contó como remitente.

Nada de esto es difícil. Sale mal porque los pasos se hacen en el orden equivocado. Se copia el correo antes de ordenar las cuentas, o se cambia el registro MX antes de que alguien liste quién más manda correo con el dominio. Este es el orden que seguimos en una migración para una empresa pequeña o mediana, y lo que revisamos en cada paso.

Paso 1: decide qué se mueve y qué se queda

Antes de abrir cualquier herramienta armamos cuatro listas con el cliente en una sola página.

Buzones, separados en tres: personas reales, direcciones compartidas que abren varios, y direcciones que solo envían (alertas, facturas, avisos de formularios).
Calendarios y salas, incluyendo quién agenda en nombre de quién.
Archivos, separando el contenido personal de OneDrive de los sitios de SharePoint que el equipo de verdad usa. Siempre hay un sitio que nadie toca desde hace tres años.
Grupos y alias: listas de distribución, la dirección que reenvía a dos personas, la que reenvía a alguien que ya se fue.

Después va la lista más corta y más útil: lo que no se mueve. Correo archivado bajo una política de retención, un buzón atado a una aplicación del negocio que nadie va a tocar este trimestre, el historial de chat. Google publica una matriz de productos de migración que dice cuál de sus herramientas cubre cada origen y cada tipo de dato, y la respuesta cambia para correo, para archivos y para un Exchange viejo instalado en la oficina. La leemos al planificar.

Paso 2: primero las cuentas, después el DNS

Todas las cuentas de Workspace se crean antes de tocar los registros del dominio. La propia guía de Google para cambiar registros MX lo pone de primero: a la hora en que el correo empiece a llegar a Google, cualquier dirección sin cuenta detrás no tiene a dónde ir.

Tres detalles ahorran la mayor parte de los dolores de cabeza.

Que las direcciones coincidan exactamente. El servicio de migración de datos empareja usuarios entre las dos cuentas buscando direcciones parecidas. Cada dirección que no coincide se vuelve un emparejamiento manual, y con el tiempo, un buzón que alguien olvidó.
Decide en qué se convierte cada buzón compartido. Google tiene dos formas para esto y se comportan distinto. Un grupo de Google configurado como Bandeja de entrada colaborativa permite que un equipo reciba en una sola dirección y se asigne conversaciones. Una cuenta delegada es un buzón que otras personas abren desde su propio Gmail, y en una cuenta de trabajo admite una cantidad alta de delegados. Las colas de soporte y ventas normalmente piden el grupo. Una dirección con años de historia que responde casi siempre la misma persona normalmente pide delegación.
Resuelve los accesos de administración temprano. Conectar los dos entornos requiere un superadministrador del lado de Workspace y un administrador global del lado de Microsoft 365. En equipos pequeños esa segunda cuenta suele estar en manos de quien montó todo hace años, y recuperarla toma más tiempo que la migración.

Paso 3: el correo, el traslape y la hora del MX

Baja el TTL del registro MX por lo menos un día antes. Google recomienda 3600, una hora, suficientemente corto para que un error en el corte cueste una hora y no un día. El TTL actual manda sobre qué tan rápido surte efecto el cambio que hagas ahora, así que bajarlo va primero.

Copia los datos antes del corte, no después. El servicio de migración de datos copia el correo y el calendario de Exchange Online a las cuentas de Workspace, hasta con 250 usuarios a la vez, así que una empresa más grande lo corre por tandas. La gente sigue trabajando en Microsoft 365 mientras corre.

Durante el traslape hay dos arreglos que conviene distinguir. La entrega dual deja el registro MX apuntando al sistema viejo, que entrega en sus propios buzones y después reenvía todo a Google. La entrega dividida apunta el MX a Google, y Gmail enruta a ciertos destinatarios hacia el otro sistema. Google recomienda Gmail como servidor principal, y dejar el servidor anterior como principal solo durante un piloto o migración, para pasar a Gmail solo cuando todos estén listos.

El corte en sí es un registro. El valor de Workspace es un solo host, y algunos registradores esperan la prioridad y el destino en el mismo campo:

example.com.   3600   IN   MX   1 smtp.google.com.

Si el dominio se configuró en Workspace antes de 2023 puede seguir con los valores aspmx anteriores, y la posición de Google es que los registros que funcionan no necesitan cambiarse. Agenda el cambio para una noche o un fin de semana, cuando perder una hora cuesta menos. Google dice que los registros MX nuevos pueden tardar hasta 72 horas en reconocerse y da hasta 48 horas de propagación, así que nadie debería juzgarla por los primeros diez minutos. Cuando se asiente, corre una pasada delta para recoger el correo que llegó al sistema viejo durante el cambio.

Paso 4: autenticación mientras los dos sistemas todavía envían

Este es el paso que se salta, y el que produce las quejas de spam dos semanas después. Mientras las dos plataformas envían con el dominio, las dos tienen que estar autorizadas, y en cuanto una deja de enviar, sale.

SPF es un solo registro, una sola cadena v=spf1, con los dos includes adentro:

example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

Google publica sus rangos de envío detrás de _spf.google.com y Microsoft publica los suyos detrás de spf.protection.outlook.com, porque ambos envían desde direcciones que cambian. Dos includes más un CRM más una plataforma de facturación es justo donde los dominios se pasan del límite: la evaluación de SPF se detiene a las diez consultas DNS y devuelve permerror, como exige el RFC 7208, y un permerror no es un pass. Cuéntalas antes del corte.

DKIM pide trabajo del lado de Google, porque no firma de entrada. La llave se genera en la consola de administración, dentro de la configuración de Gmail, se publica como registro TXT en el proveedor de DNS y después se activa la autenticación. Hay dos tiempos que importan. Después de activar Gmail para la organización, la llave no se puede generar durante 24 a 72 horas. Y una vez publicado el registro, la autenticación puede tardar hasta 48 horas en empezar a funcionar. Mete los dos en el calendario y no los descubras la mañana del corte. Deja los registros DKIM de Microsoft en su lugar mientras Microsoft siga enviando: usan selectores distintos y no chocan entre sí.

Deja DMARC en p=none mientras la lista de remitentes siga moviéndose, y lee los reportes. Endurecer la política la misma semana del corte significa que el único sistema que olvidaste empieza a fallar justo cuando nadie puede saber cuál cambio lo causó.

Al resultado le aplican dos conjuntos de reglas. Desde febrero de 2024, Google le pide a todo remitente, a cualquier volumen, SPF o DKIM y DNS directo e inverso válidos, y a quienes envían más de 5,000 mensajes diarios a cuentas de Gmail les pide SPF y DKIM juntos, un registro DMARC, alineación con el encabezado From y una tasa de spam por debajo de 0.30% en Postmaster Tools. Microsoft publica sus propios requisitos para remitentes de alto volumen hacia sus servicios de consumo, también trazados en 5,000 mensajes diarios desde el mismo dominio del From, con SPF, DKIM y DMARC en p=none o más estricto, y dice que el correo que no cumple se enruta primero a Correo no deseado. La mayoría de empresas de este tamaño está muy por debajo de esos umbrales. El primer nivel les aplica igual.

Paso 5: calendario, delegaciones y salas

Los datos de calendario viajan junto con el correo en la misma corrida de migración. Lo que no viaja es el cableado alrededor. Los permisos de delegación, la asistente que agenda para dos directores, los recursos de sala y sus reglas de reserva: todo eso se reconstruye en Workspace, y reconstruirlo a propósito es mejor que recrear un arreglo que creció por accidente durante seis años. Lo agendamos para el día siguiente al corte del correo, con las personas que de verdad lo usan.

Las invitaciones enviadas desde el sistema viejo antes del cambio pueden comportarse raro después, casi siempre las reuniones recurrentes con historia larga. Para una llamada fija con un cliente, cancelarla y volverla a crear desde Workspace es más rápido que depurarla.

Paso 6: archivos, con la forma decidida primero

El servicio de migración de datos copia el contenido de OneDrive a Mi unidad de cada usuario, y los sitios de SharePoint Online a Drive. Google Workspace Migrate cubre casos más pesados y otros orígenes, la segunda razón para leer la matriz de productos temprano.

La decisión que importa no es cuál herramienta usas, es si una carpeta le pertenece a una persona o a la empresa. El contenido que cae en Mi unidad de alguien se va con esa persona. El contenido que le pertenece al negocio va en una unidad compartida. Decidir eso antes de la copia cuesta una reunión. Decidirlo después cuesta una segunda migración. Los permisos y los enlaces tampoco sobreviven la copia sin cambios, y los accesos externos merecen una pasada de revisión, porque una migración es el único momento en que todos están dispuestos a mirar.

Paso 7: da de baja Microsoft 365 sin romper tus envíos

No canceles las licencias la misma semana. Consérvalas el tiempo suficiente para comprobar que ya nada depende de ellas, y después trabaja hacia atrás.

Encuentra todo sistema que envía con el dominio: el software contable, el CRM, el formulario de contacto del sitio, la impresora de la oficina, las alertas de un servidor que alguien todavía mantiene.
Pasa cada uno a Workspace o a su propia ruta autenticada, de uno en uno, y confirma cada uno con un mensaje real y no con una herramienta de consulta.
Quita el include de Microsoft del SPF solo cuando ya nada envíe por Microsoft. Lo mismo con sus registros DKIM.
Lee los reportes agregados de DMARC durante al menos dos semanas después de mover el último remitente. Son el único lugar donde un remitente olvidado se anuncia antes de que lo haga un cliente.
Exporta lo que haya que conservar por razones legales o contables antes de cerrar el entorno viejo, y anota dónde quedó.
Hasta entonces, y solo entonces, endurece la política DMARC.

Cómo ayuda Guanacos Tech

Esto lo corremos como un solo proyecto con un orden de operaciones escrito, porque aquí las fallas caras son de secuencia y no de técnica. Eso significa el inventario primero, las cuentas después, un corte agendado a una hora que tu negocio pueda darse el lujo de perder, la autenticación abierta mientras las dos plataformas todavía envían, y los reportes vigilados hasta que el dominio quede limpio. Si estás evaluando el cambio, nuestra página de migración a Google Workspace tiene el alcance con el que trabajamos. Lleva tu número de buzones y la lista de cosas que envían correo en tu nombre a una llamada de 30 minutos, y sales con el orden, los riesgos y la semana en que debería hacerse.

Migrar de Microsoft 365 a Google Workspace: la lista que seguimos, en orden