Errores comunes al migrar tenants de Microsoft 365 y cómo evitarlos
Una migración tenant to tenant de Microsoft 365 puede parecer sencilla cuando se resume como “mover usuarios, correo y archivos de un tenant a otro”. El problema es que Microsoft 365 no funciona como un conjunto de servicios aislados. Exchange Online, Microsoft Entra ID, OneDrive, SharePoint, Teams, grupos, dominios, aplicaciones, permisos y dispositivos están relacionados entre sí.
Por eso, los problemas más serios rara vez aparecen porque un archivo concreto no pueda copiarse. Normalmente surgen porque una dependencia importante no se había identificado antes de empezar: un dominio que todavía está asociado a objetos del tenant origen, una aplicación que autentica contra el antiguo tenant, un buzón compartido cuyos permisos no se han reconstruido o un usuario cuyo UPN no coincide con el objeto previsto en destino.
La buena noticia es que muchos de estos errores pueden detectarse antes del cutover. Una migración bien preparada debería permitir responder con bastante precisión a tres preguntas antes de mover el primer usuario: qué existe, qué se va a migrar y qué tendrá que reconstruirse o configurarse de nuevo.
En esta guía repasamos los errores que encontramos con mayor frecuencia en una migración entre tenants de Microsoft 365, cómo reconocerlos y qué medidas ayudan a evitar que se conviertan en incidencias durante el cambio.
Lo más importante antes de empezar
| Riesgo | Qué suele ocurrir | Prevención principal |
|---|---|---|
| Inventario incompleto | Aparecen datos, aplicaciones o usuarios que nadie había contemplado. | Realizar discovery y assessment antes de contratar o configurar la herramienta. |
| Dominio mal preparado | No puede liberarse del tenant origen durante la ventana de corte. | Localizar previamente todas las referencias al dominio. |
| Mapping incorrecto | Datos o permisos terminan asociados a usuarios equivocados. | Validar UPN, SMTP, identificadores y objetos destino. |
| Licencias insuficientes | El servicio destino no está preparado cuando llega el contenido. | Revisar licenciamiento y requisitos del método de migración. |
| Expectativas incorrectas | Se esperaba que Teams, aplicaciones o permisos quedaran idénticos. | Definir exactamente qué se migra, qué cambia y qué se recrea. |
| Cutover improvisado | DNS, dominio, aplicaciones y usuarios cambian sin una secuencia clara. | Preparar y ensayar un runbook de corte. |
| Validación insuficiente | La herramienta termina correctamente, pero los usuarios no pueden trabajar. | Combinar validación técnica y funcional. |
Índice
- Por qué fallan las migraciones tenant to tenant
- Error 1: empezar sin un inventario fiable
- Error 2: elegir la herramienta antes de definir el alcance
- Error 3: no definir qué significa “migración completada”
- Error 4: utilizar producción como primera prueba
- Error 5: dejar el dominio para el último momento
- Error 6: tratar UPN, SMTP e identidad como si fueran lo mismo
- Error 7: olvidar que la identidad sigue controlada desde Active Directory
- Error 8: preparar mal las licencias del tenant destino
- Error 9: migrar Exchange sin revisar todo lo que rodea al buzón
- Error 10: descubrir demasiado tarde retenciones y requisitos de compliance
- Error 11: tratar OneDrive y SharePoint como simples carpetas
- Error 12: asumir que migrar Teams significa migrarlo todo
- Error 13: copiar permisos sin revisarlos
- Error 14: olvidar aplicaciones, SSO y automatizaciones
- Error 15: dar por hecho que Power Platform seguirá funcionando igual
- Error 16: calcular tiempos como si la velocidad fuera constante
- Error 17: llegar al cutover sin un runbook
- Error 18: pensar solo en la parte técnica
- Error 19: cerrar el proyecto cuando termina la herramienta
- Tabla rápida de síntomas, causas y soluciones
- Checklist antes del cutover
- Preguntas frecuentes
- Documentación oficial recomendada
Por qué fallan las migraciones tenant to tenant de Microsoft 365
Una migración tenant-to-tenant no suele fallar por una única gran decisión equivocada. Es mucho más frecuente que los problemas aparezcan por la acumulación de pequeñas dependencias que no se habían contemplado.
Por ejemplo, el buzón de un usuario puede migrarse correctamente y, aun así, la experiencia final ser mala porque Outlook necesita volver a autenticarse, el usuario ha perdido acceso a un buzón compartido, una aplicación sigue enviando correo mediante el tenant anterior o su equipo de Teams utiliza archivos que todavía residen en otro workload.
Microsoft reconoce precisamente estas dependencias en su planificación actual de migraciones tenant-to-tenant. Por ejemplo, recomienda tener en cuenta que Teams depende de Exchange y que OneDrive y SharePoint comparten modelos de permisos. Las herramientas pueden ayudar a ejecutar la migración, pero la secuencia del proyecto sigue siendo fundamental.
Referencia oficial: Microsoft – Plan a Microsoft 365 tenant-to-tenant migration.
La migración es una cadena de dependencias
| Si cambia… | También deberías revisar… |
|---|---|
| UPN del usuario | Inicio de sesión, Outlook, Teams, OneDrive, SSO y aplicaciones. |
| Dominio corporativo | Exchange, SMTP, MX, SPF, DKIM, DMARC, aliases y aplicaciones. |
| Microsoft 365 Group | Teams, SharePoint, Planner, miembros y propietarios. |
| OneDrive | Archivos compartidos, enlaces, chats de Teams y sincronización local. |
| SharePoint | Teams, permisos, Power Apps, Power Automate y aplicaciones. |
| Microsoft Entra ID | SSO, MFA, Conditional Access, Intune y aplicaciones empresariales. |
Error 1: empezar sin un inventario fiable
El error más caro suele producirse antes de iniciar la migración: asumir que conocemos el entorno porque conocemos el número de empleados.
Una empresa con 200 usuarios no tiene necesariamente 200 buzones, 200 OneDrive y unos cuantos Teams. Puede tener además decenas de buzones compartidos, cientos de grupos, sitios SharePoint históricos, cuentas sin licencia, invitados externos, aplicaciones empresariales, recursos de calendario, archivos online y automatizaciones que nadie había relacionado con el proyecto.
Antes de fijar alcance, licencias o fechas debería existir un inventario que responda al menos a estas preguntas:
| Área | Qué necesitamos conocer |
|---|---|
| Identidad | Usuarios activos, inactivos, invitados, UPN, grupos, administradores e identidad híbrida. |
| Exchange | Buzones, tamaños, archives, shared mailboxes, aliases, delegaciones y recursos. |
| OneDrive | Usuarios con contenido, volumen, sharing y propietarios. |
| SharePoint | Sitios, almacenamiento, propietarios, Teams asociados, permisos y personalizaciones. |
| Teams | Equipos, canales, miembros, owners, invitados, apps y actividad. |
| Aplicaciones | Enterprise Apps, App Registrations, SSO, SCIM, certificados, secretos y Graph. |
| Dominios | UPN, SMTP, DNS y sistemas externos que los utilizan. |
| Compliance | Retention, holds, eDiscovery, DLP, etiquetas y requisitos legales. |
Este assessment es el que permite separar una migración sencilla de una migración aparentemente sencilla que en realidad contiene varios casos especiales.
¿No sabes exactamente qué hay en los tenants?
Antes de contratar licencias de migración o reservar una ventana de corte, podemos realizar un discovery de usuarios, buzones, SharePoint, OneDrive, Teams, dominios y aplicaciones para definir el alcance real.
Solicitar assessment tenant-to-tenantError 2: elegir la herramienta antes de saber qué hay que migrar
Quest On Demand Migration, BitTitan, Cloudiway, ShareGate y las capacidades nativas de Microsoft pueden ser buenas opciones en diferentes situaciones. El error es convertir la elección de herramienta en la primera decisión del proyecto.
La herramienta correcta depende de las cargas de trabajo, el nivel de coexistencia necesario, los tipos de contenido, el calendario y las expectativas sobre aquello que debe conservarse.
En 2026 esta comparación es especialmente importante porque Microsoft continúa ampliando sus capacidades nativas. Actualmente documenta herramientas específicas para Exchange, OneDrive y SharePoint y dispone además de Microsoft 365 Migration Orchestrator para coordinar migraciones multiworkload soportadas.
Referencia oficial: Microsoft – Microsoft 365 migration overview.
La pregunta correcta no es “¿qué herramienta es mejor?”
La pregunta debería ser:
¿qué herramienta resuelve mejor este alcance concreto con estas dependencias y estas limitaciones?
Para una organización que solo necesita mover buzones, la respuesta puede ser una. Para otra que necesita Exchange, chats de Teams, SharePoint, dispositivos y coexistencia durante tres meses, la respuesta puede ser completamente distinta.
Error 3: no definir qué significa que la migración ha terminado
“Migrar todo” es una descripción del alcance, no un criterio de aceptación.
Una herramienta puede mostrar 100 % de tareas completadas y aun así existir un problema serio para el negocio. Por eso deben definirse criterios verificables de éxito antes de comenzar.
| Área | Criterio de aceptación |
|---|---|
| Identidad | El usuario inicia sesión con la identidad definitiva y MFA funciona. |
| Correo | Puede enviar y recibir correo interno y externo. |
| Delegaciones | Los usuarios autorizados acceden a buzones y calendarios compartidos. |
| OneDrive | El usuario encuentra sus datos y el cliente de sincronización funciona. |
| SharePoint | Usuarios y grupos acceden a los sitios que corresponden. |
| Teams | El usuario ve los equipos, canales y contenidos incluidos en alcance. |
| Aplicaciones | Las aplicaciones críticas autentican y ejecutan sus procesos habituales. |
| DNS | Correo y autenticación del dominio se comportan según lo diseñado. |
Es mucho más fácil validar una migración cuando estas condiciones están acordadas de antemano.
Error 4: utilizar producción como primera prueba
El piloto no debería verse como una mini migración cuyo único objetivo es comprobar que “la herramienta conecta”.
Su función es poner a prueba la estrategia completa: identity mapping, licencias, permisos, workloads, clientes, soporte y experiencia del usuario.
Además, los participantes deben representar los casos difíciles. Seleccionar únicamente cinco usuarios con buzones pequeños y sin permisos especiales ofrece poca información sobre cómo se comportará la migración real.
| Perfil de piloto | Qué permite comprobar |
|---|---|
| Usuario estándar | Experiencia habitual. |
| Usuario con buzón grande | Rendimiento y tiempos. |
| Usuario con Archive | Tratamiento del archivo online. |
| Delegado de dirección | Calendarios y permisos de Exchange. |
| Usuario intensivo de Teams | Equipos, canales, chats y archivos. |
| Usuario con OneDrive grande | Volumen y sincronización. |
| Usuario móvil | Outlook, Teams y autenticación en smartphone. |
| Usuario de aplicación crítica | SSO e integraciones empresariales. |
Error 5: dejar el dominio personalizado para el último momento
El dominio corporativo suele ser uno de los elementos con más dependencias y, paradójicamente, uno de los que algunas migraciones dejan para revisar durante la propia ventana de corte.
Antes de poder retirar un dominio del tenant origen, Microsoft exige que deje de ser utilizado por distintos objetos. Entre ellos pueden encontrarse usuarios, administradores, shared mailboxes, resource mailboxes, contactos, Microsoft 365 Groups, listas de distribución y Teams.
Si durante el cutover descubrimos que empresa.com todavía está asociado a un grupo olvidado o a la cuenta del administrador que realiza el cambio, el dominio puede no liberarse cuando estaba previsto.
Referencia oficial: Microsoft – Remove a domain from Microsoft 365.
El dominio debería tener su propio plan de migración
| Antes del cutover | Qué comprobar |
|---|---|
| Usuarios | UPN y proxyAddresses. |
| Exchange | Buzones, aliases, contactos, recursos y grupos. |
| Entra ID | Administradores y aplicaciones que referencien el dominio. |
| DNS | Acceso al proveedor y copia de los registros actuales. |
| Correo externo | ERP, CRM, marketing y otros sistemas que envían como ese dominio. |
Cambiar MX demasiado pronto
Otro error habitual consiste en confundir “preparar el dominio” con “cambiar inmediatamente el correo”.
El MX debería modificarse cuando el tenant destino está realmente preparado para recibir el correo. Si se cambia antes, los mensajes pueden empezar a llegar a un entorno donde faltan destinatarios o donde el mail flow todavía no ha sido validado.
SPF, DKIM, DMARC y Autodiscover también deberían formar parte del runbook, no revisarse cuando comienzan a aparecer problemas.
Error 6: tratar UPN, correo e identidad como si fueran lo mismo
El UPN y la dirección de correo pueden tener el mismo aspecto —por ejemplo ana@empresa.com—, pero cumplen funciones diferentes.
| Dato | Función |
|---|---|
| UPN | Identificador de inicio de sesión del usuario. |
| Primary SMTP | Dirección principal de correo. |
| proxyAddresses | Direcciones y aliases relacionados con el objeto. |
| Object ID | Identificador del objeto dentro de Microsoft Entra ID. |
Esto importa especialmente cuando se prepara el mapping. Dos usuarios pueden llamarse igual y tener correos parecidos, pero ser objetos distintos.
Un mapping fiable debería utilizar varios atributos para confirmar la correspondencia entre origen y destino y no basarse exclusivamente en el nombre mostrado.
Síntomas de un mapping incorrecto
Los problemas pueden aparecer como permisos de SharePoint asociados a otra cuenta, archivos de OneDrive sin el propietario esperado, participantes de Teams que no se resuelven correctamente o datos migrados hacia un usuario distinto del previsto.
La solución es revisar los mappings antes del primer lote importante y tratar manualmente las excepciones.
Error 7: olvidar que algunos atributos siguen controlados desde Active Directory
En un tenant cloud-only el administrador tiene mucho más control directo sobre los objetos de Microsoft Entra ID.
En un entorno híbrido, atributos como UPN o proxyAddresses pueden seguir administrándose desde Active Directory local y sincronizarse mediante Microsoft Entra Connect.
Cambiar un atributo únicamente en la nube puede no ser posible o puede provocar que el valor anterior reaparezca en la siguiente sincronización.
Antes de migrar deberían identificarse claramente:
usuarios cloud-only, usuarios sincronizados, source of authority, OUs sincronizadas, sufijos UPN, proxyAddresses, dispositivos híbridos y estrategia futura de Entra Connect.
Error 8: preparar mal las licencias del tenant destino
El usuario puede existir en Microsoft Entra ID y, sin embargo, determinados servicios todavía no estar preparados.
Además, no todos los métodos de migración tienen los mismos requisitos de licenciamiento. Por ejemplo, Microsoft establece actualmente un Cross Tenant User Data Migration license para sus movimientos nativos de buzones entre tenants.
Por tanto, el diseño de licencias debe responder a dos necesidades diferentes:
| Tipo | Ejemplo |
|---|---|
| Licencia del servicio | Exchange Online, Microsoft 365 Business Premium, E3, E5, etc. |
| Licencia de migración | Licencia nativa cross-tenant o licencia de una herramienta de terceros. |
También conviene calcular el periodo en el que coexistirán licencias en ambos tenants. Retirarlas demasiado pronto del origen puede afectar a servicios que todavía necesita el proyecto; mantenerlas indefinidamente provoca costes innecesarios.
Error 9: pensar que migrar Exchange significa únicamente copiar mensajes
El buzón es solo una parte de Exchange Online.
Muchas empresas utilizan de forma intensiva calendarios compartidos, permisos Full Access, Send As, Send on Behalf, buzones compartidos, salas, aliases y aplicaciones que envían correo.
Todo ello debe formar parte del inventario y, cuando corresponda, de la reconstrucción en destino.
| Elemento | Por qué puede fallar después |
|---|---|
| Shared mailbox | El buzón existe, pero sus delegaciones no son correctas. |
| Calendario compartido | El usuario ha migrado, pero las relaciones de acceso han cambiado. |
| Transport rule | Las reglas pertenecen al tenant y necesitan recrearse. |
| Connector | Servicios externos siguen enviando al tenant antiguo. |
| Aplicación SMTP | ERP, impresoras u otros sistemas siguen autenticando en origen. |
| Outlook | Puede necesitar nueva autenticación o ajustes de perfil. |
Un error frecuente: validar Exchange únicamente desde Outlook Web
OWA puede funcionar correctamente mientras un perfil de Outlook, una aplicación móvil o un escáner siguen utilizando configuraciones antiguas.
La validación debe incluir los métodos de acceso que utiliza realmente la organización.
Error 10: descubrir demasiado tarde retenciones, holds y requisitos legales
El compliance debe revisarse al inicio del proyecto porque puede cambiar la propia estrategia de migración.
Un buen ejemplo es la migración nativa cross-tenant de Exchange Online. Microsoft documenta actualmente que los buzones sometidos a cualquier tipo de hold no pueden migrarse mediante ese procedimiento.
Referencia oficial: Microsoft – Cross-tenant mailbox migration.
Antes de seleccionar el método deberían revisarse:
Litigation Hold, retention policies, eDiscovery, retention labels, requisitos jurídicos, políticas de Purview y obligaciones de conservación.
La respuesta correcta no suele ser “quitar el hold para migrar”. Primero debe entenderse por qué existe y quién puede autorizar cualquier cambio.
Error 11: tratar OneDrive y SharePoint como simples carpetas
Los documentos son la parte visible, pero una migración de SharePoint o OneDrive también tiene que considerar estructura, propietarios, metadata, versiones, sharing, permisos, links y aplicaciones relacionadas.
Además, existen limitaciones técnicas que deberían detectarse durante el assessment.
Microsoft mantiene actualmente un máximo de 400 caracteres para la ruta completa de un archivo en OneDrive y SharePoint en Microsoft 365. El límite de carga para un archivo individual es actualmente de 250 GB.
Referencia oficial: Microsoft – SharePoint limits.
El error más común no es técnico: migrar basura histórica
Una migración es una oportunidad excelente para decidir qué información sigue siendo útil.
Mover sitios abandonados, documentos duplicados, OneDrive de antiguos empleados y permisos acumulados durante diez años aumenta el volumen y deja el nuevo tenant con los mismos problemas del anterior.
| Antes de migrar | Pregunta útil |
|---|---|
| Sitios SharePoint | ¿Sigue existiendo un propietario responsable? |
| Contenido antiguo | ¿Debe migrarse, archivarse o eliminarse? |
| Permisos únicos | ¿Siguen siendo necesarios? |
| Invitados | ¿Siguen colaborando con la empresa? |
| OneDrive de exempleados | ¿Quién será propietario del contenido? |
No mezcles los prerrequisitos de diferentes herramientas
Otro error menos evidente es aplicar la documentación de una tecnología a otra.
El comportamiento de provisioning, delta migration, permisos o tratamiento del destino puede variar entre Microsoft nativo, Quest, BitTitan, Cloudiway y otras herramientas.
Los prerrequisitos deben validarse siempre contra el método concreto que se va a utilizar.
¿SharePoint o OneDrive son la parte más compleja de tu migración?
Podemos analizar volumen, estructura, sitios, propietarios, permisos y posibles incidencias antes de ejecutar la migración para evitar descubrirlas cuando el proyecto ya está en producción.
Analizar SharePoint y OneDriveError 12: asumir que migrar Teams significa migrarlo todo
Microsoft Teams no almacena toda su información en un único lugar. Esa es una de las razones por las que sus migraciones son más complejas.
Un Team puede relacionarse con:
| Elemento | Servicio relacionado |
|---|---|
| Miembros y propietarios | Microsoft Entra ID / Microsoft 365 Group. |
| Archivos de canales | SharePoint Online. |
| Archivos compartidos por chat | OneDrive. |
| Calendario y reuniones | Exchange Online. |
| Planner | Planner / Microsoft 365 Group. |
| Apps y tabs | Microsoft o proveedores externos. |
Por eso una propuesta no debería indicar únicamente “migración de Teams”. Es mejor especificar qué ocurre con equipos, canales, conversaciones, chats, archivos, reuniones, apps, pestañas, canales privados y shared channels.
Las capacidades también dependen de la tecnología utilizada. Microsoft 365 Migration Orchestrator incorpora actualmente soporte multiworkload, incluido contenido de Teams, mientras que las herramientas de terceros disponen de sus propios alcances y limitaciones.
Lo importante es comprobar el comportamiento actual antes del proyecto y explicárselo al cliente y a los usuarios.
Error 13: copiar todos los permisos sin preguntarse si siguen siendo correctos
Una migración no debería convertirse en un mecanismo para perpetuar automáticamente años de acumulación de accesos.
Cuando trasladamos permisos sin revisarlos pueden producirse dos problemas opuestos:
usuarios que pierden accesos necesarios y usuarios que conservan accesos que ya no deberían tener.
Ambos son importantes, pero el segundo puede convertirse además en un problema de seguridad o cumplimiento.
Los permisos que merece la pena revisar primero
No es necesario auditar manualmente cada documento. Conviene priorizar:
sitios sensibles, bibliotecas con permisos únicos, equipos con invitados, buzones de dirección, RRHH, Finanzas, grupos privilegiados y accesos externos.
La validación funcional con los propietarios de cada área suele detectar problemas que no aparecen en un log de migración.
Error 14: olvidar aplicaciones, SSO e integraciones
Una migración puede copiar correctamente todos los datos y aun así provocar una interrupción importante porque el ERP ya no puede enviar facturas o el sistema de RRHH no puede aprovisionar usuarios.
Antes del cutover hay que inventariar tanto aplicaciones Microsoft como aplicaciones de terceros.
| Elemento | Qué puede necesitar cambiar |
|---|---|
| Enterprise Applications | SSO, assignments, claims y permisos. |
| App Registrations | Client ID, tenant ID, API permissions, secretos y certificados. |
| SCIM | Endpoint, token y mapping de usuarios. |
| Microsoft Graph | Consentimientos y service principals. |
| SMTP / OAuth | Credenciales, buzón remitente y tenant. |
| Backup | Tenant registrado y permisos de aplicación. |
| Herramientas de seguridad | Conectores, API y fuentes de logs. |
Los secretos y certificados tampoco deberían aparecer como una sorpresa el día del cambio. Deben identificarse con suficiente antelación para recrearlos o rotarlos cuando corresponda.
Error 15: asumir que Power Platform seguirá funcionando sin cambios
Power Apps y Power Automate suelen apoyarse en conexiones a SharePoint, Exchange, Teams, SQL, Dataverse y otros servicios.
Migrar el sitio SharePoint utilizado por una aplicación no significa que la aplicación haya quedado automáticamente preparada para el nuevo tenant.
Microsoft dispone actualmente de una funcionalidad tenant-to-tenant para determinados entornos de Power Platform. La documentación vigente permite mover entornos de producción y sandbox con Dataverse entre tenants y exige preparar usuarios y un fichero de mapping.
Después de la migración siguen existiendo tareas importantes. Microsoft indica, por ejemplo, que los grupos de seguridad no se migran y que las referencias de conexión de Power Automate deben revisarse y volver a autenticarse o asociarse en el destino.
Referencia oficial: Microsoft – Power Platform tenant-to-tenant migrations.
Error 16: calcular la duración suponiendo una velocidad constante
“Tenemos 10 TB y la herramienta copia X GB por hora, así que tardaremos Y días” parece un cálculo lógico, pero suele simplificar demasiado la realidad.
Microsoft 365 utiliza diferentes mecanismos de throttling para proteger la disponibilidad del servicio y gestionar la carga. El rendimiento puede variar según workload, tamaño, número de objetos, método de migración, concurrencia, servicio Microsoft y tecnología utilizada.
Microsoft distingue, entre otros, throttling de usuario, throttling del servicio de migración y throttling basado en la salud de los recursos.
Referencia oficial: Microsoft – Migration performance and best practices.
Una migración “stalled” tampoco está necesariamente rota
En algunos procedimientos de Exchange, Microsoft puede poner movimientos en espera para proteger la disponibilidad del servicio. Por eso los estados deben interpretarse junto con los informes y logs, no simplemente contar cuánto tiempo lleva un job sin avanzar.
Cómo hacer previsiones más realistas
| Medida | Por qué ayuda |
|---|---|
| Piloto real | Obtiene métricas de tu propio entorno. |
| Pre-stage | Reduce datos pendientes durante el cutover. |
| Oleadas | Evita lanzar toda la organización simultáneamente. |
| Monitorización | Permite detectar patrones de error o throttling. |
| Margen operativo | Evita diseñar fechas basadas en el mejor escenario posible. |
Error 17: llegar al cutover sin un runbook
El cutover concentra los cambios que no pudieron completarse antes. Precisamente por eso no debería depender de decisiones improvisadas durante la noche de migración.
Un buen runbook indica:
acción, responsable, hora prevista, prerrequisito, resultado esperado, método de validación y plan alternativo si algo falla.
| Fase | Ejemplos de acciones |
|---|---|
| Antes de la ventana | Revisar errores, mappings, licencias, DNS, comunicaciones y soporte. |
| Inicio | Ejecutar sincronizaciones finales y aplicar restricciones de cambio si proceden. |
| Identidad | Aplicar UPN o cambios necesarios. |
| Dominio | Liberar origen, verificar destino y actualizar objetos. |
| Correo | Actualizar MX, routing, SPF, DKIM y configuraciones relacionadas. |
| Aplicaciones | Habilitar configuraciones preparadas para el nuevo tenant. |
| Validación | Ejecutar batería de pruebas técnica. |
| Go / No-Go | Confirmar si el entorno está preparado para volver a operación normal. |
¿Tienes una fecha de cutover pero todavía no un plan detallado?
Podemos ayudarte a revisar dependencias, preparar la secuencia técnica y convertir el cambio en un runbook ejecutable y verificable.
Preparar mi cutover Microsoft 365Error 18: pensar que una migración es únicamente un proyecto técnico
Un usuario que llega el lunes y descubre que su contraseña no funciona, Outlook le pide una nueva cuenta y OneDrive ha dejado de sincronizar entiende que “la migración ha fallado”, aunque técnicamente todos sus datos estén en destino.
La comunicación debe explicar únicamente lo que el usuario necesita saber y hacerlo antes de que lo necesite.
| Momento | Qué comunicar |
|---|---|
| Antes | Fecha, posible impacto y acciones previas. |
| Justo antes del corte | Qué no debería modificarse y cuándo comienza el cambio. |
| Después | Nuevas credenciales, Outlook, Teams, OneDrive y canal de soporte. |
| Hypercare | Cómo reportar incidencias y qué información facilitar. |
La formación tampoco tiene que convertirse necesariamente en un curso completo. A menudo una guía clara sobre autenticación, Outlook, Teams y OneDrive evita gran cantidad de tickets.
Error 19: cerrar el proyecto cuando la herramienta muestra “Completed”
Una tarea finalizada indica que la herramienta ha terminado una operación. No significa necesariamente que el usuario pueda trabajar.
El cierre debería producirse después de dos tipos de validación.
Validación técnica
| Área | Comprobación |
|---|---|
| Microsoft Entra ID | Login, MFA, UPN y grupos. |
| Exchange Online | Envío, recepción, shared mailboxes y calendarios. |
| OneDrive | Datos, sharing y sync client. |
| SharePoint | Contenido, metadata y permisos. |
| Teams | Equipos, canales y contenido incluido. |
| Aplicaciones | SSO, APIs, automatizaciones y SMTP. |
| Dominio | MX, SPF, DKIM, DMARC y mail flow. |
Validación funcional
La segunda parte debe realizarla el negocio.
Un responsable de Finanzas puede confirmar si sus documentos están accesibles. Un asistente puede comprobar el calendario del director. El responsable de RRHH puede validar la aplicación de personal. El propietario de un sitio SharePoint sabe qué personas deberían acceder.
Estas comprobaciones encuentran problemas que una herramienta de migración no puede detectar por sí sola.
Hypercare
Durante los primeros días es normal recibir incidencias relacionadas con perfiles, móviles, permisos, accesos directos, favoritos, aplicaciones o sincronización.
Conviene reservar un periodo de soporte reforzado y no desmontar inmediatamente el tenant origen o las herramientas de migración hasta haber completado las validaciones previstas.
Tabla rápida: síntomas frecuentes y dónde buscar
| Síntoma | Causa probable | Primer punto de revisión |
|---|---|---|
| El dominio no puede añadirse al destino | Todavía tiene dependencias en origen. | Usuarios, mailboxes, groups, Teams, admins y aplicaciones. |
| El usuario no puede iniciar sesión | UPN, contraseña, MFA o Conditional Access. | Microsoft Entra ID y sign-in logs. |
| El correo no llega | Mail flow, MX o destinatario incorrecto. | Message Trace y DNS. |
| Un alias ha dejado de funcionar | No fue recreado en el nuevo objeto. | proxyAddresses de Exchange. |
| Buzón compartido inaccesible | Delegación no reconstruida. | Full Access / Send As / Send on Behalf. |
| OneDrive no sincroniza | Cliente todavía asociado al entorno anterior. | Cuenta de OneDrive del dispositivo. |
| Faltan archivos | Errores, exclusiones o limitaciones. | Informe de migración y source data. |
| Usuario sin acceso a SharePoint | Mapping o grupo incorrecto. | Permisos del sitio y usuario destino. |
| Team incompleto | Alcance o limitación de la herramienta. | Informe por workload. |
| Aplicación deja de autenticar | Tenant ID, secret, certificate o SSO antiguo. | App Registration / Enterprise App. |
| Migración aparentemente parada | Throttling o recursos del servicio. | Logs y estado detallado de la herramienta. |
| Flujo de Power Automate falla | Connection Reference no válida. | Conexiones del entorno destino. |
Checklist antes de una migración tenant to tenant
Esta lista no sustituye un plan de proyecto, pero sirve como comprobación final antes del piloto o el cutover.
| Área | Comprobación |
|---|---|
| Alcance | Está documentado qué se migra, qué no y qué debe recrearse. |
| Usuarios | Origen y destino están correctamente mapeados. |
| Dominios | Se conocen todas las dependencias y la secuencia de liberación. |
| Licencias | Existen licencias suficientes y correctas. |
| Exchange | Buzones, archives, shared mailboxes y delegaciones están inventariados. |
| SharePoint | Sitios, owners, permisos y aplicaciones relacionadas están revisados. |
| OneDrive | Usuarios, volumen y sharing están identificados. |
| Teams | El alcance está definido por componentes, no solo por “Teams”. |
| Aplicaciones | SSO, SCIM, Graph, SMTP y APIs están inventariados. |
| Power Platform | Flows, Apps, Dataverse y conexiones tienen un plan específico. |
| Compliance | Retention, holds y eDiscovery han sido revisados. |
| DNS | Hay acceso probado y registros documentados. |
| Piloto | Se ha ejecutado con usuarios representativos. |
| Runbook | Las acciones del cutover tienen responsable y validación. |
| Usuarios | Existe comunicación antes y después del cambio. |
| Hypercare | Hay recursos disponibles durante los primeros días. |
| Rollback | Se ha definido qué cambios pueden revertirse y cuáles no. |
Preguntas frecuentes sobre errores en migraciones tenant to tenant
Empezar sin conocer realmente el entorno.
El número de usuarios no refleja por sí solo la complejidad de una migración. Hay que inventariar buzones, OneDrive, SharePoint, Teams, grupos, dominios, aplicaciones, permisos, invitados, dispositivos y requisitos de compliance.
Normalmente porque todavía está asociado al tenant origen o existen objetos que lo utilizan.
Antes de retirarlo deben revisarse usuarios, administradores, shared mailboxes, resource mailboxes, contactos, Microsoft 365 Groups, listas de distribución, Teams y otras dependencias.
El mismo dominio personalizado exacto debe liberarse del tenant origen antes de poder quedar verificado en el destino.
Por eso la transferencia de dominio debe planificarse como una fase propia del cutover.
Los servidores externos pueden empezar a entregar mensajes al tenant destino cuando todavía no todos los destinatarios o configuraciones están preparados.
El MX debe modificarse siguiendo la estrategia de mail flow definida para la ventana de corte.
No. Aunque a menudo tengan el mismo valor, el UPN se utiliza principalmente para la identidad e inicio de sesión, mientras que la dirección SMTP corresponde al correo.
Ambos elementos deben revisarse durante la migración.
Hay que respetar el origen de autoridad de los atributos.
Si UPN, proxyAddresses u otros atributos se administran desde Active Directory, modificarlos únicamente en Microsoft Entra ID puede no ser suficiente o puede provocar que el cambio se revierta durante la sincronización.
Depende del workload y del método utilizado, pero el tenant destino debe disponer de los servicios y licencias que requiere la arquitectura.
Además, algunas tecnologías de migración —incluidas determinadas funciones cross-tenant nativas de Microsoft— tienen licenciamiento específico.
Existen diferentes requisitos y restricciones. Microsoft documenta actualmente, por ejemplo, que los buzones sujetos a cualquier tipo de hold no pueden moverse mediante Cross-Tenant Mailbox Migration.
Los requisitos deben revisarse antes de seleccionar el método.
Entre las causas posibles están rutas demasiado largas, nombres no admitidos, permisos, objetos problemáticos o limitaciones de la tecnología empleada.
Microsoft establece actualmente un máximo de 400 caracteres para la ruta completa de archivos de OneDrive y SharePoint en Microsoft 365.
No debería darse por hecho.
El resultado depende de la herramienta, del tipo de permiso, del mapping de identidades, grupos, invitados, enlaces y características del entorno. Los sitios críticos deberían validarse funcionalmente después de la migración.
Depende del método y de la herramienta utilizados.
Teams tiene dependencias con Exchange, SharePoint, OneDrive, Microsoft 365 Groups y otras aplicaciones. El alcance debería especificar equipos, canales, chats, archivos, apps, tabs y otros componentes por separado.
Sí. Microsoft documenta actualmente Microsoft 365 Migration Orchestrator para movimientos tenant-to-tenant coordinados de workloads compatibles.
También siguen existiendo herramientas específicas por workload y soluciones especializadas de terceros.
Las causas más frecuentes son mapping incorrecto, grupos no recreados, usuarios invitados, permisos únicos o diferencias entre el modelo de acceso del origen y el destino.
Los permisos deberían probarse con propietarios de sitios y usuarios reales durante el piloto y la validación final.
La velocidad depende del volumen, número de objetos, workload, método y disponibilidad del servicio. Microsoft 365 aplica throttling para proteger la disponibilidad y estabilidad de la plataforma.
Por eso las estimaciones deberían basarse en pilotos reales y contemplar margen operativo.
No necesariamente.
Completed significa que la herramienta ha terminado una operación. Después deben validarse usuarios, correo, permisos, datos, Teams, aplicaciones, DNS y experiencia de usuario.
No es técnicamente obligatorio en todos los escenarios, pero es una de las medidas más útiles para reducir riesgos.
Permite descubrir errores de permisos, mappings, licencias, Outlook, OneDrive, Teams, rendimiento o aplicaciones antes de afectar al conjunto de usuarios.
El objetivo debe ser reducir el impacto al mínimo, pero no es responsable garantizar impacto cero en todos los escenarios.
Dominios, DNS, autenticación, perfiles, aplicaciones y dispositivos pueden necesitar una ventana de transición o acciones por parte de los usuarios.
No.
Una buena herramienta facilita discovery, mapping, transferencia de datos y reporting, pero no decide por sí sola la arquitectura, la estrategia de dominio, los criterios de aceptación, las aplicaciones que deben reconfigurarse o la comunicación con usuarios.
Cuando la migración incluye varias cargas de trabajo, muchos usuarios, varios dominios, identidad híbrida, SharePoint o Teams complejos, aplicaciones críticas, coexistencia o una ventana de cutover reducida.
También resulta recomendable cuando todavía no existe un inventario fiable del tenant.
Conclusión: la mayoría de los errores se evitan antes de empezar a migrar
Los mayores problemas en una migración tenant to tenant de Microsoft 365 suelen tener un origen bastante predecible: inventario incompleto, dependencias no detectadas, alcance ambiguo, mapping incorrecto, expectativas poco realistas o falta de validación.
La tecnología de migración importa, pero no es lo primero. El orden más seguro es analizar, definir el alcance, diseñar la arquitectura, seleccionar la herramienta, probar, premigrar, ejecutar el cutover y validar.
También es importante reconocer que Microsoft 365 sigue evolucionando. Las capacidades nativas de migración actuales son más amplias que hace unos años y Microsoft dispone ya de herramientas específicas para Exchange, SharePoint, OneDrive, Power Platform y un Migration Orchestrator para determinados escenarios multiworkload.
Esto hace todavía más importante revisar la documentación vigente antes de diseñar el proyecto en lugar de reutilizar automáticamente el procedimiento de una migración anterior.
Una migración correctamente ejecutada no se limita a trasladar datos. Debería dejar un tenant destino más ordenado, con identidades bien definidas, permisos revisados, aplicaciones documentadas y usuarios que puedan volver a trabajar sin tener que entender toda la complejidad técnica que ha habido detrás.
¿Estás preparando una migración tenant to tenant de Microsoft 365?
En Kloudeal podemos ayudarte desde el análisis inicial hasta el soporte posterior al cambio.
Revisamos usuarios, Exchange Online, OneDrive, SharePoint, Teams, dominios, Microsoft Entra ID, licencias, permisos, aplicaciones, identidad híbrida, DNS, herramientas de migración y dependencias antes de ejecutar el proyecto.
También podemos comparar las opciones nativas de Microsoft con herramientas especializadas como Quest On Demand Migration para definir qué arquitectura encaja mejor con el alcance real.
Hablar con Kloudeal sobre mi migraciónDocumentación oficial recomendada
Planificación de migraciones tenant-to-tenant
- Microsoft – Plan a Microsoft 365 tenant-to-tenant migration
- Microsoft – Microsoft 365 Migration Overview
- Microsoft – Migration Orchestrator Overview
Exchange Online
Dominios y DNS
- Microsoft – Remove a Domain from Microsoft 365
- Microsoft – Add a Custom Domain
- Microsoft – Connect Your Domain by Adding DNS Records