Cómo migrar a Microsoft 365: plan y comprobaciones

Cómo construir el plan de migración a partir de condiciones de avance

Un plan para migrar a Microsoft 365 resulta más útil cuando cada fase termina con una condición verificable. El inventario se completa cuando se conocen las fuentes y dependencias necesarias, no cuando se entrega una hoja con datos sin revisar. La preparación termina cuando el destino permite ejecutar el piloto. El corte se aprueba cuando las pruebas y los responsables confirman que se cumplen las condiciones acordadas.

Este enfoque evita fijar todas las fechas como si las tareas fueran independientes. Si una aplicación necesita un cambio de autenticación o un departamento debe revisar permisos, esa dependencia aparece en el calendario con su responsable. El equipo puede decidir entonces si se resuelve antes, se separa en otra fase o impide avanzar con la parte del proyecto afectada.

El piloto debe probar los casos que pueden cambiar el plan. Un usuario sencillo ayuda a comprobar la base técnica, pero no representa un buzón delegado, una biblioteca con permisos diferenciados o un dispositivo con una aplicación imprescindible. Los resultados deben utilizarse para corregir alcance y tiempos, en lugar de tratarse como una demostración que se da por aprobada de antemano.

Cómo decidir si una incidencia permite continuar

Antes de la ventana de cambio se acuerdan criterios de gravedad y responsables de decisión. Una incidencia que impide acceder a un proceso crítico puede bloquear el avance aunque afecte a pocos usuarios. Otra diferencia de presentación, comprendida y aceptada, puede resolverse después sin comprometer el funcionamiento. La prioridad depende del impacto real y de las alternativas disponibles.

El registro debe explicar qué falla, a quién afecta y qué prueba demuestra la corrección. También necesita un punto de decisión para detener, continuar o aplicar la contingencia prevista. Un plan de retorno debe revisarse según el método y los cambios realizados: después de que los usuarios generen información nueva en destino, volver atrás no equivale simplemente a deshacer una configuración.

Qué significa realmente migrar a Microsoft 365

Microsoft 365 es un conjunto de servicios relacionados. Una migración puede afectar a uno de ellos o a prácticamente toda la plataforma. En una migración sencilla podemos estar hablando únicamente de sustituir un proveedor de correo IMAP por Exchange Online. En una transformación más amplia pueden intervenir correo, documentos, identidad, seguridad, colaboración, dispositivos y aplicaciones.

Por tanto, una organización no debería utilizar el término “migración a Microsoft 365” como si describiera una única operación técnica. Lo correcto es convertirlo en un alcance concreto: qué servicios se activarán, qué datos se trasladarán, qué elementos no se migrarán, qué se reconstruirá y quién será responsable de cada componente.

Por qué migrar a Microsoft 365

La razón principal no debería ser simplemente “pasar a la nube”. Microsoft 365 puede aportar valor cuando ayuda a simplificar sistemas, mejorar colaboración, centralizar identidad y reducir la dependencia de infraestructuras que la empresa ya no necesita mantener. Correo sin infraestructura Exchange propia. Exchange Online permite utilizar correo empresarial, calendarios, contactos, shared mailboxes, salas y recursos sin mantener los servidores de correo tradicionales de la organización.

Esto no elimina la necesidad de administrar Exchange, pero cambia el tipo de administración: dejamos de gestionar infraestructura y dedicamos más esfuerzo a configuración, seguridad, permisos y gobierno. Documentación empresarial accesible y compartida. SharePoint y OneDrive permiten que la información deje de depender exclusivamente de unidades de red, VPN o archivos enviados por correo. Sin embargo, la ventaja aparece cuando la arquitectura documental está bien diseñada. Subir todas las carpetas históricas a SharePoint sin reorganizarlas no convierte automáticamente un file server en una buena plataforma de colaboración.

Una identidad común. Microsoft Entra ID permite centralizar identidades y proporcionar acceso a Microsoft 365 y otras aplicaciones mediante SSO, MFA y políticas de acceso. Para empresas con Active Directory local, el modelo puede mantenerse híbrido mientras resulte necesario. Colaboración mediante Teams. Teams reúne chat, reuniones y espacios de colaboración, pero también se integra estrechamente con SharePoint, OneDrive, Exchange y Microsoft 365 Groups.

Eso permite construir una experiencia de usuario coherente, siempre que exista un mínimo de gobierno sobre equipos, canales, invitados y aplicaciones. Seguridad con más contexto. Una arquitectura Microsoft 365 bien diseñada puede aplicar controles no solo según la contraseña del usuario, sino también según identidad, rol, dispositivo, riesgo, aplicación y otros factores. La tecnología está disponible, pero necesita configuración y licencias adecuadas. Migrar a Microsoft 365 y dejar todas las políticas de seguridad para meses después desaprovecha una parte importante del proyecto.

Antes de migrar: define el entorno que quieres tener después

Una migración es una oportunidad para dejar de mantener decisiones que se tomaron hace años y que quizá ya no tienen sentido. Antes de copiar datos, conviene definir el estado futuro.

Esta fase evita uno de los errores más habituales: reproducir en Microsoft 365 todos los problemas del entorno anterior.

Assessment: qué debemos conocer antes de mover datos

Un buen assessment no es un documento teórico. Su función es convertir el entorno actual en datos que permitan tomar decisiones. El nivel de detalle depende del proyecto, pero deberíamos conocer como mínimo las siguientes áreas.

El número de usuarios no determina la dificultad

Una empresa de 40 usuarios puede tener una migración compleja si dispone de varios dominios, aplicaciones integradas, muchos datos compartidos y una identidad híbrida. Otra con 300 usuarios y un entorno sencillo de correo puede ser más predecible. El esfuerzo depende de volumen, dependencias y excepciones, no únicamente del número de cuentas.

Microsoft Entra ID: la identidad debe diseñarse antes que los datos

Microsoft Entra ID es el servicio de identidad y acceso de Microsoft que anteriormente se denominaba Azure Active Directory. En un proyecto Microsoft 365 afecta prácticamente a todo: inicio de sesión, UPN, grupos, permisos, Teams, SharePoint, aplicaciones, MFA, Conditional Access y dispositivos. Por eso conviene resolver las decisiones de identidad antes de ejecutar migraciones masivas. Cloud-only o híbrido. No todas las empresas necesitan eliminar Active Directory local.

Podemos distinguir dos modelos básicos.

La elección depende de aplicaciones locales, servidores, dispositivos, requisitos de autenticación y estrategia tecnológica. UPN y dominio. El UPN con el que inicia sesión el usuario debería revisarse antes de la migración. En muchos proyectos interesa que el usuario pueda identificarse con una dirección coherente, por ejemplo: nombre.apellido@empresa.com Si Active Directory sigue siendo origen de autoridad para determinados atributos, los cambios deben aplicarse de forma consistente desde allí y no solo desde el portal cloud.

Microsoft Entra Cloud Sync o Connect Sync

En 2026 ya no conviene presentar Microsoft Entra Connect Sync como la única alternativa para sincronizar Active Directory con Microsoft Entra ID. Microsoft está posicionando Microsoft Entra Cloud Sync como su dirección estratégica para la mayoría de nuevos escenarios de sincronización híbrida. Cloud Sync utiliza agentes ligeros en el entorno local mientras la configuración y orquestación se administran desde Microsoft Entra.

Por eso no existe una respuesta universal. Para un nuevo escenario sencillo o con varios bosques desconectados, Cloud Sync puede ser especialmente interesante. Si la organización depende de Hybrid Join de dispositivos o de reglas avanzadas de sincronización que todavía no tienen equivalencia, Connect Sync puede seguir siendo necesario. Referencia oficial: Microsoft – Entra Connect Sync to Cloud Sync decision guide.

Licencias: diseñarlas según usuarios y servicios

El licenciamiento debería revisarse durante la fase de diseño y no la semana anterior al cutover. No todos los usuarios necesitan necesariamente el mismo plan.

No diseñes el proyecto a partir de nombres de planes. Microsoft cambia periódicamente packaging, nombres y condiciones comerciales. Es más seguro comenzar por los requisitos: qué necesita hacer cada perfil de usuario y qué capacidades de seguridad o administración requiere la empresa. Después se selecciona el plan que cumple esas necesidades. Doble licenciamiento durante una transición. En determinadas migraciones puede existir temporalmente un periodo donde algunos usuarios necesiten servicios o licencias en origen y destino.

Ese coste debe formar parte del presupuesto del proyecto.

Migración de correo a Exchange Online

El correo es normalmente el componente con menor tolerancia a errores. El usuario puede aceptar que un documento histórico tarde unas horas más en aparecer, pero espera poder enviar y recibir correo inmediatamente después del cambio. Por eso Exchange necesita su propio assessment.

Rutas de migración posibles. El procedimiento depende del origen.

Referencia oficial: Microsoft – Ways to migrate multiple email accounts to Microsoft 365.

Migrar correo IMAP a Microsoft 365

IMAP es uno de los métodos más sencillos conceptualmente, pero también tiene una limitación fundamental: está diseñado principalmente para correo. Una migración IMAP permite trasladar mensajes y carpetas, pero no debemos esperar que migre automáticamente:

Esta diferencia debe comunicarse antes de empezar porque para un usuario “mi buzón” puede significar correo, agenda y calendario, mientras que técnicamente una migración IMAP cubre solo una parte.

Exchange Server y migración híbrida

Cuando el origen es Exchange Server, el diseño puede ser considerablemente más sofisticado. En entornos medianos o grandes puede tener sentido establecer una configuración híbrida entre Exchange Server y Exchange Online. Esto permite mantener una coexistencia durante la transición y mover buzones progresivamente. Cuándo una estrategia híbrida puede tener sentido. Por ejemplo cuando: hay muchos usuarios, la migración durará semanas, necesitamos coexistencia de calendarios o todavía existen dependencias relevantes con Exchange Server.

No todos los Exchange Server necesitan un híbrido complejo. En organizaciones más pequeñas pueden existir otras rutas de migración. La versión de Exchange, el número de buzones, la coexistencia requerida y las aplicaciones relacionadas deberían decidir el método. Referencia oficial: Microsoft – Exchange hybrid deployments.

Migración desde Google Workspace a Microsoft 365

Migrar desde Google Workspace puede implicar bastante más que mover Gmail. Hay que separar los diferentes servicios.

Google Drive no debería copiarse sin rediseñar el destino. Una carpeta compartida en Google no siempre tiene una equivalencia directa en OneDrive. Si la documentación pertenece a un departamento o proceso empresarial, SharePoint suele ser un destino más lógico. Por eso el mapping debería realizarse antes del job de migración.

Migrar archivos a Microsoft 365

Las migraciones documentales generan muchas incidencias cuando se tratan como una copia masiva de carpetas. Microsoft 365 no es simplemente un file server alojado en Internet. SharePoint y OneDrive trabajan con conceptos como: sitios, bibliotecas, permisos, metadata, versiones, sharing, sincronización y colaboración. Antes de mover contenido conviene decidir qué información pertenece a cada servicio.

OneDrive o SharePoint: una decisión fundamental

La forma más sencilla de diferenciarlos es pensar en la propiedad de la información.

Un error habitual. Mover una unidad compartida del servidor al OneDrive del responsable del departamento. Técnicamente puede funcionar, pero convierte información de empresa en datos dependientes de una cuenta individual. Cuando el contenido pertenece al equipo, normalmente debería evaluarse SharePoint.

Migración a SharePoint Online

SharePoint puede recibir contenido desde file servers, SharePoint Server, Dropbox, Google Drive, Box y otras plataformas. Pero antes de migrar debemos evaluar la estructura del origen.

Herramientas Microsoft. Microsoft ofrece actualmente varias rutas. SharePoint Migration Tool continúa siendo una opción para SharePoint Server y file shares. Migration Manager permite administrar migraciones desde diferentes orígenes externos hacia Microsoft 365, incluyendo file shares y plataformas cloud soportadas. Referencia oficial: Microsoft – Migrate your content to Microsoft 365.

Migración a OneDrive

OneDrive suele utilizarse para sustituir carpetas personales o almacenamiento ligado a cada usuario. En una migración conviene comprobar no solo cuántos gigabytes tiene cada persona, sino también qué está compartiendo. Por qué el sharing importa. Un usuario puede tener pocos archivos, pero cientos de enlaces compartidos con compañeros y proveedores. Si el contenido cambia de ubicación, esos accesos pueden necesitar revisión.

Usuarios inactivos. También hay que decidir qué hacer con las cuentas de empleados que ya no trabajan en la organización. No siempre tiene sentido crear una nueva cuenta únicamente para replicar un OneDrive antiguo. En ocasiones es preferible consolidar la información relevante en una ubicación corporativa.

Microsoft Teams: colaboración, no solo chat

Teams es la capa visible de varios servicios Microsoft 365.

Esta arquitectura tiene dos consecuencias. La primera es que no deberíamos implantar Teams sin pensar en SharePoint y OneDrive. La segunda es que una migración de Teams entre tenants o plataformas puede involucrar varios workloads. Gobierno básico antes de abrir Teams a toda la organización. No es necesario construir un sistema burocrático, pero conviene definir al menos:

Referencia oficial: Microsoft – Microsoft Teams overview.

La seguridad debe diseñarse dentro de la migración

Durante años muchas migraciones siguieron este orden: primero mover datos y después ya configuraremos seguridad. Es mejor evitar ese enfoque. El tenant debería estar preparado con una base de seguridad antes de que los usuarios empiecen a trabajar en él.

MFA y Conditional Access en 2026

MFA ya no debería tratarse como una mejora opcional para “más adelante”. Microsoft ha ido introduciendo MFA obligatorio para sus portales y herramientas administrativas, y cualquier proyecto nuevo debería diseñarse asumiendo que los accesos administrativos utilizarán autenticación multifactor. Security Defaults. Para entornos que no utilizan Microsoft Entra ID P1 o P2, Security Defaults proporciona una base de protección gestionada por Microsoft.

Es una opción sencilla cuando la empresa no necesita excepciones o políticas detalladas. Conditional Access. Cuando la organización dispone del licenciamiento adecuado, Conditional Access permite crear políticas más granulares. Por ejemplo: requerir MFA, bloquear autenticación heredada, exigir determinados dispositivos o aplicar controles adicionales según el riesgo. No actives políticas complejas directamente en producción. Para políticas de acceso condicional es recomendable utilizar primero Report-only, revisar qué usuarios y aplicaciones quedarían afectados y activar posteriormente la política.

Administradores: MFA resistente al phishing

Para cuentas privilegiadas merece la pena avanzar más allá del MFA tradicional. Microsoft recomienda métodos resistentes al phishing para roles administrativos, mediante tecnologías como passkeys/FIDO2 cuando el escenario y la organización están preparados. Referencia oficial: Microsoft – Require phishing-resistant MFA for administrators.

SPF, DKIM y DMARC durante la migración

El cambio de plataforma de correo debería aprovecharse para revisar la autenticación del dominio.

No olvides las aplicaciones. El problema suele aparecer cuando SPF se modifica únicamente pensando en Exchange Online y se olvidan: ERP, CRM, impresoras, aplicaciones web, ticketing, newsletters y otros sistemas que envían correo como la empresa. Estos remitentes deben inventariarse antes del cambio.

Microsoft Purview: cumplimiento y protección de información

Microsoft Purview reúne diferentes capacidades relacionadas con gobierno, seguridad y cumplimiento de datos. Dependiendo del licenciamiento y necesidades de la organización pueden entrar en juego:

Una migración no implica que todas estas funciones deban implantarse desde el primer día. Pero si existen políticas legales o de retención en el sistema anterior, deben identificarse antes de mover o eliminar datos. Referencia oficial: Microsoft – Purview documentation.

Microsoft Intune y la gestión de dispositivos

Si la transformación Microsoft 365 también incluye dispositivos, Microsoft Intune puede utilizarse para administrar políticas, aplicaciones y cumplimiento. Pero la migración de correo y datos y la transformación de dispositivos no tienen necesariamente que realizarse el mismo día.

Qué debería decidirse

Esta fase debe coordinarse con el equipo que gestione los endpoints. Una migración Microsoft 365 no debería asumir automáticamente soporte físico o configuración individual de todos los puestos de trabajo salvo que se haya incluido expresamente en alcance.

Aplicaciones e integraciones: el área que más fácilmente se olvida

Una organización puede migrar correctamente todos los buzones y archivos y, aun así, tener un problema importante el lunes si su ERP ya no puede enviar correo o la aplicación de RRHH deja de autenticar usuarios.

Aplicaciones con cuentas de usuario como servicio. También es un buen momento para detectar automatizaciones que dependen de una cuenta de usuario y contraseña. Cuando sea posible, las nuevas integraciones deberían utilizar identidades de carga de trabajo, managed identities, service principals o certificados en lugar de mantener usuarios interactivos con contraseñas permanentes.

Herramientas para migrar a Microsoft 365

No hay una única herramienta válida para todos los orígenes. Microsoft ha organizado actualmente sus herramientas según el tipo de migración. Migraciones desde plataformas externas. Migration Manager es actualmente una de las herramientas principales de Microsoft para administrar migraciones de contenido externo hacia Microsoft 365. Microsoft documenta soporte para orígenes como: file shares, Google Workspace/Drive, Dropbox, Box y otros escenarios soportados.

SharePoint Migration Tool. SPMT sigue teniendo un papel importante para SharePoint Server y file shares. Tenant-to-Tenant. Para movimientos entre tenants Microsoft 365, Microsoft dispone actualmente de herramientas específicas para:

Herramientas especializadas

También existen plataformas de terceros que pueden ser más adecuadas para determinados proyectos.

La elección debería hacerse después del inventario y no antes. Referencia oficial: Microsoft – Microsoft 365 Migration Overview.

Fases recomendadas de una migración Microsoft 365

El procedimiento exacto cambia según el entorno, pero un proyecto empresarial suele beneficiarse de una secuencia estructurada.

Discovery. Debe proporcionar una imagen suficientemente fiable del origen. No necesitamos documentar hasta el último archivo antes de empezar, pero sí entender los factores que cambian arquitectura, presupuesto y calendario. Diseño. Aquí decidimos el destino de la información, identidad, licencias, seguridad, dominios y método de migración. Preparación. Es preferible crear el tenant correctamente antes de empezar a mover datos que intentar corregirlo durante el cutover.

Migración por oleadas. En empresas medianas y grandes suele ser más práctico agrupar usuarios por departamentos o dependencias funcionales. Esto facilita soporte y permite aprender de una oleada antes de ejecutar la siguiente.

Cómo diseñar un piloto que realmente detecte problemas

El piloto no debería estar formado únicamente por el director de TI y dos buzones pequeños. Hay que seleccionar casos representativos.

Después del piloto deberían documentarse: tiempos reales, errores, diferencias funcionales, acciones manuales y cambios necesarios en el runbook.

El cutover: preparar el cambio, no improvisarlo

El cutover es la fase donde se ejecutan las operaciones que no podían realizarse con normalidad antes. Puede incluir cambios de DNS, activación final de usuarios, modificaciones de dominios y sincronizaciones delta. Un buen runbook debe indicar quién hace qué.

Los tiempos reales deben definirse para cada proyecto. La tabla anterior representa una estructura de trabajo, no una duración garantizada.

Comunicación y adopción: la migración vista por el usuario

El usuario no ve el dashboard de la herramienta. Ve Outlook, Teams y sus documentos. Por eso necesita saber qué va a cambiar.

No conviertas la migración en un curso de Microsoft 365 de ocho horas. La formación más útil suele estar relacionada con los cambios reales que experimentará el usuario. Por ejemplo: cómo compartir un documento correctamente, dónde guardar archivos, cómo usar Teams, cómo registrarse para MFA o cómo distinguir OneDrive de SharePoint.

Cómo validar que la migración ha terminado correctamente

Un job en estado Completed no es un criterio suficiente de aceptación. La validación debe combinar datos técnicos con pruebas funcionales.

Validación funcional. También deberían participar usuarios clave. El equipo técnico puede confirmar que una biblioteca contiene 20.000 archivos, pero el responsable de Finanzas sabe si los documentos que necesita para cerrar el mes están donde esperaba.

Cuánto tarda una migración a Microsoft 365

No existe una duración estándar. Dos proyectos con 100 usuarios pueden tener calendarios completamente diferentes.

El calendario debería estimarse después del discovery y ajustarse con los resultados del piloto.

Cuánto cuesta migrar a Microsoft 365

El coste tampoco debería calcularse únicamente multiplicando el número de usuarios por una tarifa. Hay varios componentes.

Una herramienta gratuita no siempre produce el proyecto más barato si obliga a invertir muchas más horas en procesos manuales. Y una herramienta avanzada tampoco es necesariamente necesaria para un entorno sencillo.

Errores habituales al migrar a Microsoft 365

Checklist para una migración a Microsoft 365

Preguntas frecuentes sobre migrar a Microsoft 365

¿Cuál debe ser el primer paso para migrar a Microsoft 365?

Definir el objetivo y revisar el entorno que sostiene el trabajo de la empresa. El inventario debe incluir datos, identidades, aplicaciones y dependencias relevantes, con responsables capaces de validar decisiones. Esa base permite seleccionar el destino y el método; elegir primero una herramienta puede dejar fuera requisitos que condicionan todo el proyecto.

¿Cómo se eligen los usuarios del piloto?

Se seleccionan perfiles que representen el uso real y los casos que pueden generar dificultades. Además de un usuario estándar, pueden incluirse delegaciones, movilidad, aplicaciones o información compartida. El piloto debe tener pruebas y resultados esperados, y sus conclusiones deben incorporarse al plan antes de ampliar la migración.

¿Qué permite aprobar la ventana de cambio?

La aprobación debe apoyarse en condiciones acordadas: destino preparado, pruebas del piloto resueltas, responsables disponibles y procedimientos de validación y contingencia conocidos. También hay que revisar dependencias externas y comunicación a usuarios. La finalización de una transferencia inicial es una evidencia útil, pero no cubre por sí sola todas esas condiciones.

¿Puede prepararse un retorno automático para cualquier migración?

No debe suponerse. La reversibilidad depende del método, de los cambios de identidad y dominio y de los datos nuevos generados en destino. El plan debe documentar qué se puede revertir, hasta cuándo y con qué consecuencias. Esas condiciones deben entenderse antes del corte, cuando todavía se pueden ajustar alcance y estrategia.

Recomendaciones finales: migrar a Microsoft 365 es diseñar el nuevo entorno, no solo trasladar datos

Una migración a Microsoft 365 puede comenzar con una necesidad aparentemente sencilla —cambiar el correo, eliminar un file server o adoptar Teams— y terminar afectando a identidad, documentos, aplicaciones y seguridad. Por eso el mejor enfoque consiste en separar el proyecto en decisiones manejables. Primero entendemos el entorno actual. Después definimos cómo debería funcionar el futuro. A continuación diseñamos identidad, licencias, seguridad y arquitectura documental. Solo entonces seleccionamos herramientas y empezamos a mover información.

Microsoft ofrece actualmente más capacidades de migración nativas que hace unos años: Migration Manager para diferentes fuentes externas, SharePoint Migration Tool y herramientas cross-tenant para varios workloads, además de Migration Orchestrator para determinados movimientos coordinados. Las herramientas de terceros siguen teniendo un papel importante cuando aportan mejores capacidades de discovery, transformación, migraciones incrementales, reporting, Teams, coexistencia o soporte multiworkload. También ha evolucionado la identidad. Microsoft Entra Cloud Sync es actualmente la dirección estratégica de Microsoft para muchos nuevos escenarios híbridos, aunque Connect Sync sigue teniendo un papel cuando se necesitan funcionalidades todavía no disponibles en Cloud Sync.

Y la seguridad ya no debería dejarse para después del proyecto. MFA, Conditional Access, roles administrativos, seguridad del correo y protección de datos deberían formar parte del diseño inicial. Una migración bien ejecutada termina cuando los usuarios pueden iniciar sesión, enviar correo, encontrar sus documentos, colaborar y utilizar sus aplicaciones con los controles de seguridad previstos.

Documentación oficial recomendada

Microsoft 365 Migration.

• Microsoft – Microsoft 365 Migration Overview
• Microsoft – Microsoft 365 Migration Documentation

Exchange Online.

• Microsoft – Ways to migrate multiple email accounts to Microsoft 365
• Microsoft – Exchange Hybrid Deployments
• Microsoft – Cross-Tenant Mailbox Migration

SharePoint, OneDrive y contenido.

• Microsoft – Migrate your content to Microsoft 365
• Microsoft – SharePoint Migration Tool
• Microsoft – Migration Manager

Microsoft Entra ID e identidad híbrida.

• Microsoft – Microsoft Entra ID name change
• Microsoft – What is Microsoft Entra Cloud Sync?
• Microsoft – Connect Sync to Cloud Sync decision guide

MFA y Conditional Access.

• Microsoft – Mandatory Multifactor Authentication
• Microsoft – Conditional Access Overview
• Microsoft – Security Defaults
• Microsoft – Require Phishing-Resistant MFA for Administrators

Microsoft Teams.

• Microsoft – Microsoft Teams Overview

Microsoft Purview.

• Microsoft – Microsoft Purview Documentation

Tenant-to-Tenant.

• Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration
• Microsoft – Migration Orchestrator
• Microsoft – Cross-Tenant OneDrive Migration
• Microsoft – Cross-Tenant SharePoint Migration