Dos empresas, dos tenants y un lunes por la mañana
Imagina una empresa de logística de 40 personas que compra una agencia aduanal de 12. El trato se cierra un viernes. Para el lunes, el equipo que llega debe responder correo en el dominio del comprador, abrir las mismas carpetas compartidas y aparecer en el mismo calendario que el resto. La parte de TI nunca entró en el contrato de compra, así que cae en quien administra el correo.
Todo el mundo llama a esto migración entre tenants, y el nombre crea una expectativa equivocada. Ninguna herramienta mueve un tenant. Lo que se mueve son los datos de cada usuario, un tipo de dato a la vez, cada uno con su propia herramienta y su propia lista de cosas que se quedan atrás. El trabajo está en conocer esa lista antes de que se cierre el trato, no durante el fin de semana del corte. Corremos estos proyectos como servicio, y la primera hora siempre se va en las mismas dos decisiones.
Define qué tenant sobrevive y qué pasa con el dominio
Antes de abrir una consola resolvemos tres cosas: qué organización conserva su identidad, dónde tienen que terminar los datos y en qué dominio va a responder correo la gente en seis meses. Esas respuestas definen la dirección de cada copia posterior, y cambiarlas después significa migrar dos veces.
El dominio sorprende, porque se mueve una sola vez y en una sola dirección. Del lado de Google, un dominio que ya es dominio principal o alias en otra cuenta de Google Workspace no se puede agregar sin más a una segunda: la ayuda de Google indica quitarlo primero de la cuenta que lo tiene, y advierte que después de quitarlo puede tomar hasta 24 horas antes de poder agregarlo de nuevo, o hasta siete días si la cuenta se compró a través de un revendedor. Verificado el 27 de octubre de 2026.
Microsoft marca el mismo límite. Su documentación dice que un dominio está asociado a un solo tenant de Microsoft Entra ID o Exchange Online, y su guía de migración de buzones entre tenants indica que el dominio principal debe quitarse de todos los objetos del tenant de origen antes de que el tenant de destino pueda tomarlo.
Es decir, no existe una ventana en la que los dos tenants respondan por el mismo dominio, y quedan dos planes sensatos. O la empresa adquirida mantiene su dominio vivo en su propio tenant mientras corren las copias y el dominio se mueve al final, cuando los buzones que atiende ya están en el tenant que sobrevive. O todos reciben una dirección en el dominio sobreviviente desde el primer día y el dominio viejo llega después como dominio secundario para el correo entrante, sin apagar nada hasta comprobar que el reenvío funciona. Descubrir esta regla la noche del corte es lo que convierte el proyecto en una semana perdida.
De Google Workspace a Google Workspace: qué mueven las herramientas
Unir dos cuentas de Workspace es la ruta más sencilla, siempre que aceptes para qué sirve la importación incluida. La herramienta de importación de datos de la consola de administración de Google copia correo desde otra cuenta de Workspace: mensajes, borradores y enviados, con etiquetas, subetiquetas y destacados. Los adjuntos se omiten cuando el mensaje más su adjunto pasa de 25 MB, así que un buzón lleno de archivos grandes necesita una revisión antes de cerrar la cuenta vieja.
Un superadministrador de la cuenta de destino configura la importación, en Datos, luego Importación y exportación de datos, luego Importación de datos. Ahí se escribe el correo de un superadministrador de la cuenta de origen, y solo esa persona puede autorizar la conexión desde el enlace que Google le envía. Ese enlace expira en 24 horas, y hay que esperar 24 horas después de enviar una solicitud para poder reenviarla, una forma lenta de perder un día si el administrador indicado está de vacaciones. Los revendedores no pueden correr la importación por el cliente. La herramienta admite hasta 1,000 usuarios por importación, y el mapa de importación que relaciona direcciones de origen con cuentas de destino está limitado a 1,000 usuarios de origen y 128 MB.
Todo lo que no es correo es un trabajo aparte, con una ruta por tipo de dato. Arriba de 1,000 usuarios de origen, la matriz de productos de Google apunta a Google Workspace Migrate, que corre en servidores Windows propios y requiere Business Standard o superior, o a Domain Transfer, que no es autogestionado.
| Qué hay que mover | Ruta entre dos cuentas de Workspace | Qué llega | Qué sigue siendo manual |
|---|---|---|---|
| Correo | Herramienta de importación de datos, en Importación y exportación de datos del destino | Mensajes, borradores, enviados, etiquetas, subetiquetas y destacados | Filtros, delegación y respuestas automáticas, uno por uno |
| Adjuntos grandes | La misma importación | El mensaje, sin el archivo cuando mensaje más adjunto pasa de 25 MB | Sacar esos archivos del origen antes de cerrarlo |
| Calendarios | Transferencia de calendario del usuario, o compartir y luego ceder | Eventos en el calendario del nuevo propietario | Salas, recursos y páginas de citas recreados en el destino |
| Contactos | Exportar CSV, importar CSV | Contactos personales | El directorio compartido, que sale de las cuentas y grupos que creas |
| Archivos de Drive | Compartición, transferencia de propiedad o la API de Drive | Archivos en la cuenta de destino | Estructura y membresía de las unidades compartidas, diseñadas antes |
| Más de 1,000 usuarios de origen | Google Workspace Migrate, o Domain Transfer con Google | El alcance que defina el proyecto | Un servidor Windows para Migrate, con Business Standard o superior |
De Microsoft 365 a Microsoft 365: la licencia, los hold y el único pase de OneDrive
Unir dos tenants de Microsoft 365 se ve más ordenado en papel y tiene más trampas. La migración de buzones entre tenants mueve correo, contactos, calendario, tareas y notas, pero no es algo que se active en una tarde.
Tres detalles definen si el proyecto es viable. Primero, cada usuario que muevas necesita una licencia Cross Tenant User Data Migration además de una licencia de Exchange Online en el tenant de destino, y Microsoft recomienda aplicarla solo después de que el objeto preparado tenga el ExchangeGUID correcto, porque licenciar antes crea un buzón nuevo y vacío. Segundo, los buzones con cualquier tipo de hold no se migran y el movimiento queda bloqueado para ellos, así que los hold por litigio o retención hay que encontrarlos y resolverlos en el origen antes de prometer una fecha. Tercero, cada usuario debe existir por adelantado en el destino como mail user con un ExchangeGUID que coincida con el buzón de origen, con las direcciones x500 del origen, una dirección SMTP principal de la nueva organización y una dirección de destino que apunte al buzón que todavía está en el origen.
Alrededor de eso va la plomería: un registro de aplicación en el destino, el consentimiento de administrador otorgado por el origen, una relación de organización entrante en el destino y otra saliente en el origen con los movimientos de correo habilitados, y un endpoint de migración. Cuando un buzón termina de moverse, el objeto de origen se convierte en un mail user cuya dirección de destino apunta al nuevo buzón, que mantiene el correo llegando a la persona mientras se actualizan las libretas de direcciones.
Los archivos son otro ejercicio, con una restricción más dura. La migración de OneDrive entre tenants se maneja desde PowerShell, con Set-SPOCrossTenantRelationship para crear la confianza y Start-SPOCrossTenantUserContentMove para mover cada cuenta, en lotes de hasta 4,000 usuarios. Microsoft dice de forma explícita que es una actividad de una sola vez y que no se pueden hacer pases incrementales ni delta, y deja un redireccionamiento en el origen. Un solo pase, así que el contenido tiene que estar quieto cuando corre. También falla en cuentas con OneDrive en solo lectura y en tenants de origen que usan Customer Key, y no está disponible para GCC, GCC High, DoD ni cuentas de consumidor.
La hora del corte es el cambio de dominio
El orden que sigue es nuestro método, no una regla del proveedor, y es la parte por la que normalmente nos contratan. Los dos pasos irreversibles, el cambio de dominio y el único pase de OneDrive, quedan al final y no se pueden ensayar con datos reales.
Copiamos primero y cambiamos al final. El correo se copia mientras el tenant viejo sigue siendo el que lo recibe, por eso importan los pases delta del lado de Google y por eso el lado de Microsoft necesita sus objetos preparados con tiempo. La autenticación se prepara antes de cambiar el registro MX, no después: el SPF del dominio sobreviviente actualizado para incluir a cada remitente que seguirá enviando por él, DKIM firmando con el dominio sobreviviente y no con el de un proveedor, y un registro DMARC con una dirección de reportes que alguien lea. Después se libera el dominio de un lado y se reclama del otro, dentro de los plazos que cada proveedor documenta, y solo entonces el MX apunta a la nueva casa.
Lo que rompe la primera semana después de una adquisición son los remitentes que nadie recuerda, porque la empresa adquirida trajo los suyos: un sistema de facturación, un CRM, un plugin de la tienda, un escáner en una bodega que todavía reenvía por el proveedor viejo. Cada uno hay que autorizarlo para enviar por el dominio sobreviviente o sacarlo de ahí. Si después del corte tu correo ya está cayendo en spam del otro lado, empieza por los registros de autenticación antes que por el contenido.
Personas, grupos y unidades compartidas después del primer día
Que los datos lleguen no es la meta, y la semana siguiente es donde una adquisición se acomoda o se queda doliendo. Los buzones compartidos y las listas de distribución casi nunca sobreviven intactos: del lado de Google una dirección compartida es un grupo con su propia membresía y sus reglas de publicación, y eso se reconstruye en lugar de copiarse. El acceso que vivía en la estructura de carpetas de un tenant hay que volverlo a expresar como unidades compartidas y membresía de grupos en el tenant que sobrevive, y por eso diseñamos esa estructura antes de mover archivos, no después.
Deja el tenant de origen vivo y pagado un tiempo. Guarda la única copia de lo que la importación omitió, es donde sigue apuntando el redireccionamiento de las cuentas de OneDrive movidas, y responde la pregunta que alguien hará en la tercera semana sobre un hilo de hace dos años. Planifica el re-enrolamiento de la verificación en dos pasos del equipo que llega, confirma que cada persona puede entrar y enviar la primera mañana, y mantén una lista corta de lo que no vino. El recorrido completo está en nuestra página de migración entre tenants, y las demás rutas, incluidas las de hosting y Microsoft 365, están en el hub de migración de correo.
Cómo ayuda Guanacos Tech
Corremos migraciones por adquisición de punta a punta con las herramientas de los propios proveedores: definir el tenant que sobrevive y el plan del dominio, preparar objetos y licencias, copiar correo y archivos en pases, cambiar MX, SPF, DKIM y DMARC en el orden correcto, y quedarnos en el dominio mientras se acomodan la reputación y el enrutamiento. Si prefieres delegarlo, eso es lo que hacen nuestros consultores de migración a Google Workspace. Agenda una llamada de 30 minutos con el calendario del trato a la vista y te decimos qué pasos son irreversibles y dónde está la fecha límite real.
Fuentes
- Google Workspace Help: Import email from a Google Workspace account
- Google Workspace Help: About importing email with the data import tool
- Google Workspace Help: Copy data between Google Workspace accounts
- Google Workspace Help: Google Workspace migration product matrix
- Google Workspace Help: Can't add new domain to Google account
- Microsoft Learn: Cross-tenant mailbox migration
- Microsoft Learn: Cross-tenant OneDrive migration overview
- Microsoft Learn: Migrate mailboxes across Microsoft 365 organizations