Migración de datos a Microsoft 365: planificación

Por qué la unidad de migración debe incluir datos y contexto

En una migración de datos a Microsoft 365, el archivo no siempre es la unidad suficiente para definir el trabajo. Un expediente puede necesitar sus documentos, estructura, metadatos, versiones y permisos. Si solo se comprueba que los ficheros llegaron al destino, puede perderse el contexto que permite encontrarlos o utilizarlos correctamente dentro del proceso del departamento.

Un ejemplo ilustrativo es una biblioteca de contratos donde cada documento tiene cliente, fecha y estado de revisión. Esos campos pueden ser más importantes para la búsqueda que la carpeta original. Antes de copiar hay que decidir cómo se representarán en destino y si el método admite el tratamiento requerido. La validación debe incluir búsquedas y consultas que el equipo utiliza en su trabajo habitual.

La migración también ofrece una oportunidad de ordenar accesos, pero cualquier cambio necesita aprobación. Un permiso antiguo no debe conservarse sin revisión ni eliminarse solo porque resulte difícil de interpretar. El propietario identifica quién necesita trabajar con la información y TI comprueba cómo aplicar ese criterio mediante grupos y permisos que puedan mantenerse después del proyecto.

Cómo construir una muestra de aceptación que detecte problemas

La muestra debe representar los casos difíciles, además de los documentos más sencillos. Conviene incluir bibliotecas con metadatos, contenido compartido, permisos diferenciados y archivos que utiliza alguna aplicación. Se registran las características de origen, el resultado esperado y la comprobación en destino. Así se puede distinguir una limitación del método de un error de configuración.

El propietario debe probar apertura, edición, búsqueda y acceso con perfiles diferentes. Si un documento se utiliza desde un enlace en una aplicación o una página interna, ese recorrido se comprueba también. Las incidencias se agrupan por causa y se corrigen antes de repetir la muestra; un reintento masivo no sustituye el análisis y puede complicar el control de versiones o duplicados.

Qué es realmente una migración de datos a Microsoft 365

Una migración consiste en trasladar información desde un sistema origen hacia uno o varios servicios Microsoft 365. Pero esa definición se queda corta porque durante el proyecto también debemos trasladar o reconstruir el contexto de los datos. Un archivo sin su propietario, un buzón sin sus delegaciones o un sitio SharePoint sin sus permisos pueden estar técnicamente migrados y ser funcionalmente inútiles.

Por eso el criterio de aceptación de una migración no debería ser simplemente: “se han copiado 1,8 TB”. Debería ser algo más parecido a: “los usuarios adecuados pueden acceder a la información correcta desde el nuevo entorno y los procesos incluidos siguen funcionando como estaba previsto”.

Tres principios antes de empezar

1. No todo debe migrarse. Una migración es una oportunidad para identificar: datos obsoletos, usuarios inactivos, duplicados, archivos temporales, permisos antiguos y contenido que ya no tiene valor operativo. Mover datos innecesarios consume tiempo, almacenamiento y esfuerzo de validación. 2. El destino no debe copiar automáticamente la estructura del origen. Una unidad de red creada hace quince años no tiene por qué transformarse en una biblioteca SharePoint con exactamente las mismas carpetas y permisos.

Microsoft 365 utiliza un modelo diferente y puede ser preferible reorganizar parte del contenido. 3. “Completed” no significa “validado”. Las herramientas informan del estado técnico de sus trabajos. Pero una tarea completada puede contener: warnings, archivos omitidos, conversiones, permisos no reconstruidos o elementos no soportados. La validación posterior sigue siendo necesaria.

Principales escenarios de migración hacia Microsoft 365

No todos los escenarios necesitan una herramienta de terceros. Microsoft ha ampliado significativamente sus capacidades nativas. Actualmente, su documentación diferencia dos grandes familias:

Las herramientas especializadas siguen teniendo sentido cuando proporcionan capacidades que necesitamos para un proyecto concreto.

Assessment: conocer los datos antes de moverlos

Un buen assessment debería proporcionar suficiente información para responder cuatro preguntas: qué tenemos;, quién lo utiliza;, dónde debería terminar; y qué puede impedir la migración..

GB y TB no cuentan toda la historia

Un repositorio de 1 TB compuesto por archivos grandes puede migrarse más fácilmente que otro de 300 GB formado por millones de ficheros pequeños. Por eso conviene conocer: volumen total, número de objetos, distribución de tamaños, permisos, complejidad.

Clasificar antes de copiar

Una migración documental debería incluir una fase de clasificación del contenido.

No hace falta limpiar cada archivo manualmente. La limpieza debe ser proporcional al proyecto. En ocasiones bastará con eliminar carpetas claramente obsoletas y corregir los permisos más problemáticos. En otras, especialmente cuando Microsoft 365 va a sustituir un file server utilizado durante décadas, puede merecer la pena dedicar más tiempo al rediseño.

OneDrive o SharePoint: probablemente la decisión documental más importante

OneDrive y SharePoint comparten mucha tecnología, pero no tienen el mismo propósito.

Regla sencilla. Pregúntate: “Si esta persona abandona mañana la empresa, ¿los demás deben seguir trabajando normalmente con estos documentos?” Si la respuesta es sí, probablemente deberíamos evaluar SharePoint. Error habitual. Migrar una carpeta departamental al OneDrive del responsable. Puede funcionar técnicamente, pero crea una dependencia innecesaria de una identidad individual.

Migrar un file server o NAS a Microsoft 365

Es uno de los proyectos documentales más habituales. Microsoft dispone actualmente de herramientas propias para trasladar file shares a SharePoint, OneDrive y otros destinos relacionados. Antes de migrar. Conviene analizar:

No olvides las aplicaciones que utilizan rutas de red. Una aplicación puede depender de: \\servidor\contabilidad\facturas Trasladar esos archivos a SharePoint no garantiza que el software pueda seguir utilizándolos de la misma manera. Estas dependencias deben identificarse antes de retirar el file server.

Migration Manager para file shares

Migration Manager está integrado en el centro de administración de SharePoint y permite administrar migraciones de recursos compartidos de archivos a Microsoft 365. El modelo actual utiliza agentes de migración instalados en equipos o máquinas virtuales Windows con acceso al contenido origen. Qué aporta.

Piloto e incremental. Microsoft recomienda para file shares utilizar un grupo piloto y realizar una migración incremental antes del cutover. Después, durante el cambio definitivo, el origen debe dejar de utilizarse y los usuarios deben trabajar sobre SharePoint o OneDrive. Referencia oficial: Microsoft – Migration Manager for File Shares.

SharePoint Migration Tool (SPMT)

SharePoint Migration Tool continúa siendo una herramienta importante dentro de las capacidades nativas Microsoft. Microsoft la proporciona gratuitamente para migrar contenido hacia Microsoft 365. Orígenes SharePoint soportados. La documentación actual incluye:

SPMT o Migration Manager. Hay escenarios donde ambas herramientas pueden trabajar con file shares. La elección depende del proyecto. Migration Manager resulta especialmente útil para administrar migraciones de file shares a escala desde una consola central y distribuir trabajo entre agentes. SPMT resulta especialmente relevante para proyectos desde SharePoint Server y también puede utilizarse para file shares. Referencia oficial: Microsoft – SharePoint Migration Tool.

SharePoint Server a SharePoint Online

Migrar SharePoint Server requiere más análisis que trasladar documentos. Qué puede existir en un SharePoint antiguo. Por ejemplo: sitios, subsitios, listas, bibliotecas, metadata, content types, workflows, formularios, web parts, soluciones personalizadas, master pages, scripts y aplicaciones. No todo se transforma automáticamente en SharePoint moderno. Un portal desarrollado hace años sobre SharePoint Server puede necesitar: migración de contenido, rediseño funcional. Especialmente cuando utiliza personalizaciones que no tienen equivalente directo en SharePoint Online.

Los workflows merecen una revisión propia. SPMT dispone de capacidades para determinados workflows de SharePoint Server, pero cualquier automatización importante debería probarse específicamente. En algunos casos puede ser preferible modernizarla mediante Power Automate u otra tecnología.

Migración Google Workspace → Microsoft 365

Una migración Google Workspace normalmente se divide en dos grandes proyectos técnicos.

No recomendamos reducir Google Workspace a IMAP. Microsoft dispone de un proceso especializado para Google Workspace que puede tratar más información que un movimiento IMAP convencional. Esto resulta importante para calendarios y contactos. Google Drive. Migration Manager permite realizar assessment, mapping de destinos e identidades y migraciones incrementales. Los documentos Google compatibles pueden convertirse a formatos Office durante la migración.

Los enlaces externos necesitan atención. Los modelos de sharing Google y Microsoft no son idénticos y determinados accesos o enlaces externos deberán reconstruirse. Referencia oficial: Microsoft – Google Workspace Migration with Migration Manager.

Dropbox, Box y otros repositorios cloud

Microsoft ha ampliado Migration Manager para trabajar con diferentes plataformas externas. La documentación actual de migración Microsoft 365 presenta Migration Manager como el punto central para escenarios externos como: Google Workspace, Dropbox, Box y file shares, entre otros orígenes soportados. La misma regla sigue aplicando. No deberíamos decidir automáticamente: “Dropbox de usuario → OneDrive”. Dentro de Dropbox puede existir documentación departamental o compartida que debería terminar en SharePoint.

Qué revisar.

Exchange Server a Exchange Online

Exchange Server puede migrarse utilizando diferentes estrategias. La elección depende de versión, usuarios, coexistencia, Active Directory, aplicaciones y calendario.

El correo no es la única dependencia de Exchange. Debemos revisar: SMTP relay, aplicaciones, impresoras, scanners, connectors, certificados, Autodiscover, shared mailboxes, salas, Archives y permisos delegados.

Exchange Server 2016 y 2019 en 2026

Este artículo debe reflejar un cambio importante. Exchange Server 2016 y Exchange Server 2019 finalizaron su soporte el 14 de octubre de 2025. Microsoft dirige a las organizaciones hacia Microsoft 365 o Exchange Server Subscription Edition. Extended Security Updates. Microsoft mantiene un programa ESU para determinados clientes de Exchange Server 2016 y 2019. Eso no cambia el hecho de que las versiones hayan alcanzado el fin de su ciclo de soporte normal.

Por qué importa en una migración. Si una empresa sigue ejecutando Exchange 2016 o 2019 en 2026, el proyecto debería revisar: CU actual, Security Updates, situación ESU, Active Directory, aplicaciones y ruta definitiva hacia Microsoft 365 o Exchange SE. Referencia oficial: Microsoft – Exchange 2016 and 2019 End of Support.

Migraciones IMAP

IMAP permite migrar principalmente correo y carpetas. No representa un buzón completo como Exchange.

El servidor origen puede limitar la velocidad. Hostings y proveedores suelen imponer límites de conexiones, throughput o sesiones. Por eso una prueba piloto es útil para estimar el rendimiento real. No todos los sistemas IMAP son iguales. Zimbra, cPanel, Dovecot, Courier u otros sistemas pueden ofrecer funcionalidades adicionales fuera de IMAP. Si necesitamos calendarios o contactos hay que comprobar si existe una API, exportación o herramienta especializada capaz de obtenerlos.

POP3, PST y datos almacenados localmente

POP3 añade una dificultad importante: el servidor puede no conservar todo el histórico. Los mensajes pueden haber sido descargados al equipo del usuario. Antes de migrar. Hay que averiguar dónde se encuentran los datos:

Por eso una migración POP puede requerir más esfuerzo operativo que una migración IMAP del mismo número de usuarios.

Migración Tenant-to-Tenant de Microsoft 365

Las migraciones entre tenants aparecen en fusiones, adquisiciones, carve-outs, consolidaciones y reorganizaciones empresariales. Aunque origen y destino sean Microsoft 365, suelen ser proyectos especialmente complejos porque cada tenant dispone de su propio directorio, dominios, objetos, permisos y aplicaciones. No existe una operación universal de “mover tenant”. Los workloads deben tratarse de forma coordinada.

Microsoft ofrece actualmente tres enfoques. Su documentación distingue:

Referencia oficial: Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration.

Qué mueve realmente Microsoft Migration Orchestrator

En 2026 conviene ser muy preciso con esta funcionalidad porque está evolucionando rápidamente. La documentación actual de Microsoft especifica cuatro workloads soportados dentro de una migración orquestada de datos de usuario:

Qué no debemos asumir que migra. Microsoft indica expresamente que esta solución no migra los datos compartidos como Teams/Channels ni los sitios SharePoint. Estos componentes necesitan la ruta correspondiente de SharePoint o la herramienta que se haya definido para el proyecto. Mueve contenido, no identidades. Los usuarios deben existir y estar correctamente preparados en el tenant destino. El identity mapping forma parte de los prerrequisitos.

Dependencias. Teams Meetings depende de Exchange y Teams Chats dentro del batch correspondiente. El propio Orchestrator secuencia los workloads soportados para respetar sus dependencias. OneDrive no funciona como una premigración tradicional. En la migración cross-tenant nativa de OneDrive se realiza un movimiento y Microsoft indica que no existen pasadas incrementales o delta posteriores. Esto debe tenerse en cuenta al diseñar el cutover.

Referencia oficial: Microsoft – Migration Orchestrator Overview.

Herramientas cross-tenant específicas por workload

Microsoft también dispone de procedimientos independientes. Cross-Tenant Mailbox Migration. Permite trasladar buzones Exchange Online entre tenants. Necesita una preparación adecuada de identidades y atributos en destino. Los buzones sujetos a determinados holds pueden quedar bloqueados para este procedimiento. Cross-Tenant OneDrive Migration. Permite mover OneDrive entre tenants. Es un movimiento definitivo y tiene requisitos específicos sobre la preparación del destino. Cross-Tenant SharePoint Migration.

Permite mover sitios SharePoint entre tenants. También tiene requisitos sobre identidad, destino y estructura. Referencias oficiales:

• Cross-Tenant Mailbox Migration
• Cross-Tenant OneDrive Migration
• Cross-Tenant SharePoint Migration

Migrar Microsoft Teams exige entender qué hay detrás de Teams

Teams utiliza varios servicios Microsoft 365.

Por eso “migrar Teams” debería descomponerse en componentes. Hay que especificar qué incluye el alcance. Por ejemplo: Teams, canales, archivos, chats 1:1, chats grupales, reuniones, Planner, tabs, apps, invitados y permisos. No todas las herramientas trasladan todos estos elementos ni con la misma fidelidad.

Microsoft Entra ID: los datos necesitan propietarios

Una migración de datos depende de identidades. Antes de mover contenido deberíamos disponer de usuarios y grupos adecuados en el destino. Qué revisar.

Microsoft Entra Cloud Sync o Connect Sync

Si la empresa mantiene Active Directory local, ya no deberíamos plantear Microsoft Entra Connect Sync como la única opción. Microsoft define actualmente Entra Cloud Sync como su dirección estratégica para la sincronización de identidad híbrida. Las nuevas capacidades de sincronización se desarrollan principalmente sobre Cloud Sync y Microsoft lo recomienda como ruta futura para la mayoría de organizaciones cuando el escenario es compatible.

Por tanto, la decisión depende de las funcionalidades utilizadas actualmente. Referencia oficial: Microsoft – Connect Sync to Cloud Sync Decision Guide.

Permisos, propietarios y acceso externo

Migrar documentos sin sus permisos puede ser un problema. Migrarlos conservando todos los permisos históricos también puede serlo. Una migración es una oportunidad para revisar accesos. Especialmente: usuarios inactivos, proveedores antiguos, accesos temporales, cuentas personales y grupos sin propietario. Permisos NTFS y SharePoint. No existe una equivalencia conceptual perfecta entre una estructura NTFS muy granular y un diseño moderno de permisos SharePoint.

En muchos casos es preferible utilizar: grupos, propietarios claros y permisos por sitio o biblioteca en lugar de reproducir cientos de ACL distintas. Sharing externo. Los enlaces externos y permisos invitados deben validarse individualmente según la herramienta y origen. No deberíamos asumir que un enlace creado en Google, Dropbox o SharePoint origen seguirá funcionando después del cambio.

Metadata, versiones y tipos de archivo

El contenido empresarial no es solo el archivo binario.

Google Workspace. Por ejemplo, los formatos nativos Google pueden convertirse a Word, Excel o PowerPoint mediante las capacidades soportadas de Migration Manager. Esa conversión debería probarse con documentos complejos.

Límites técnicos: no memorices cifras antiguas

Los límites de Microsoft cambian y deberían verificarse antes de cada proyecto. A fecha de actualización de esta guía, Microsoft documenta un tamaño máximo de archivo de 250 GB para las principales rutas de migración mediante Migration Manager y SPMT:

Esta cifra no significa que un archivo de ese tamaño sea siempre conveniente ni que sea el único límite relevante. También debemos revisar: paths, nombres, número de elementos, caracteres, quota del destino, throttling, velocidades y restricciones específicas del origen. Referencia oficial: Microsoft – File Size Limitations for Migration.

Aplicaciones e integraciones: datos que no aparecen en una carpeta

Hay dependencias que no se ven mirando el tamaño de los repositorios.

Especialmente importante en file servers. Antes de retirar un servidor de archivos hay que comprobar si existen aplicaciones que utilizan rutas UNC directamente. Especialmente importante en tenant-to-tenant. Una App Registration del tenant origen no aparece automáticamente en el nuevo tenant con sus secretos, permisos y consentimientos. Debe planificarse independientemente.

Seguridad antes, durante y después de la migración

Una migración puede requerir permisos administrativos y consentimientos elevados. Eso debe controlarse. Principios básicos.

No actives seguridad compleja durante el cutover sin probarla. Si utilizamos Conditional Access, conviene realizar pruebas y utilizar Report-only cuando corresponda antes de aplicar una política que podría bloquear usuarios o administradores.

Retención, holds y Microsoft Purview

Los requisitos de compliance pueden modificar completamente una migración. No eliminar información sometida a conservación sin analizarla. Especialmente en Exchange y tenant-to-tenant, determinados holds pueden incluso bloquear ciertos métodos nativos. Antes de migrar. Conviene conocer: retention policies, retention labels, Litigation Hold, eDiscovery cases, auditoría y obligaciones legales. Después de migrar. Las políticas del entorno destino deben validarse para confirmar que los nuevos datos reciben el tratamiento adecuado.

Cómo elegir una herramienta de migración

No existe una “mejor herramienta” universal.

Preguntas que utilizamos para elegir. Principalmente: origen, destino, volumen, número de objetos, permisos, deltas, coexistencia, reporting, fidelidad necesaria, calendario y coste.

PowerShell y Microsoft Graph durante una migración

PowerShell y Microsoft Graph son especialmente útiles para: assessment, preparación, automatización, reporting y validación. Pero no deberían presentarse como una herramienta universal de copia de datos.

Microsoft Graph PowerShell

Puede utilizarse para inventariar usuarios:

Install-Module Microsoft.Graph -Scope CurrentUser

Connect-MgGraph -Scopes "User.Read.All","Directory.Read.All"

Get-MgUser -All -Property DisplayName,UserPrincipalName,Mail,AccountEnabled |
    Select-Object DisplayName,UserPrincipalName,Mail,AccountEnabled |
    Export-Csv "C:\Temp\usuarios-microsoft-365.csv" -NoTypeInformation -Encoding UTF8

Exchange Online PowerShell

Install-Module ExchangeOnlineManagement -Scope CurrentUser

Connect-ExchangeOnline

Get-EXOMailbox -ResultSize Unlimited |
    Select-Object DisplayName,PrimarySmtpAddress,RecipientTypeDetails |
    Export-Csv "C:\Temp\buzones-exchange-online.csv" -NoTypeInformation -Encoding UTF8

Estos ejemplos son orientativos. Los permisos, módulos y comandos deben revisarse antes de utilizarlos en producción. Automatización útil. PowerShell también resulta especialmente útil para:

Fases de una migración de datos bien estructurada

El piloto debe buscar problemas

Un piloto formado únicamente por tres usuarios con buzones pequeños y diez documentos no aporta demasiada información. Casos representativos.

Qué obtenemos del piloto. Velocidad real, tipos de error, tareas manuales, cambios para usuarios y ajustes necesarios en el runbook.

Premigraciones y migraciones incrementales

Cuando la tecnología lo soporta, trasladar datos antes del corte ayuda a reducir la ventana final. Modelo habitual. En este caso se contemplan: migración inicial, usuarios continúan trabajando en origen, delta, cutover, última sincronización y validación. No todos los métodos admiten delta. Este punto es especialmente importante. Las herramientas de terceros y Migration Manager pueden disponer de modelos incrementales en determinados workloads.

Algunas migraciones cross-tenant nativas de Microsoft, como OneDrive, funcionan como un movimiento definitivo y no admiten una secuencia clásica de premigración, delta. El runbook debe diseñarse según el comportamiento real de la herramienta.

Cutover: el momento en el que cambia el sistema de trabajo

El cutover puede ser diferente según el tipo de dato.

Un buen runbook indica. qué se hace, quién lo hace, en qué orden, cómo se valida y qué condiciones obligan a detener el proceso.

Validar datos, no únicamente jobs

La validación debería tener varias capas. 1. Validación cuantitativa. Comparar: archivos, tamaño, buzones, objetos, sitios y errores. 2. Validación técnica. Comprobar: permisos, versiones, metadata, correo, DNS y aplicaciones. 3. Validación funcional. Usuarios reales deberían confirmar que pueden realizar sus tareas habituales.

Los informes deben conservarse. Resulta útil guardar: inventario inicial, mappings, errores, excepciones y validaciones finales como documentación del proyecto.

Comunicación a usuarios

Una migración técnicamente impecable puede generar frustración si el usuario no sabe dónde están sus documentos el lunes. Qué debe saber antes.

La migración cloud y el soporte de puestos son alcances distintos. Puede ser necesario que un usuario vuelva a iniciar sesión, configure Outlook o cambie accesos. Pero intervenir individualmente sobre cada ordenador es una tarea diferente de mover datos en Microsoft 365 y debería aparecer expresamente en el alcance cuando sea necesaria.

Cuánto tarda una migración de datos a Microsoft 365

No existe una fórmula basada únicamente en TB o usuarios.

El piloto es la mejor fuente para estimar rendimiento. Una vez observada una muestra real podemos ajustar: concurrencia, oleadas, ventana de cambio y duración total.

Qué determina el coste

Una migración de datos puede incluir varios componentes de coste.

Una herramienta gratuita no siempre significa un proyecto más barato

Puede ser completamente adecuada si cubre bien el escenario. Pero si una solución especializada reduce semanas de trabajo manual, su licencia puede resultar económicamente razonable.

Errores frecuentes en una migración de datos a Microsoft 365

Checklist antes de migrar datos a Microsoft 365

Preguntas frecuentes sobre migración de datos a Microsoft 365

¿Qué debe incluir el alcance de una migración de datos?

Debe identificar las fuentes y los destinos, pero también el contexto que se necesita conservar: permisos, propietarios, metadatos, versiones y procesos relacionados cuando corresponda. Cada elemento debe vincularse con el método y la prueba de aceptación. De ese modo queda claro qué se copiará y qué requiere adaptación o reconstrucción.

¿Conviene limpiar la información antes de migrarla?

Puede reducir complejidad, pero necesita criterios y responsables. El departamento debe decidir qué contenido sigue siendo necesario y qué tratamiento dar a información obsoleta o sujeta a conservación. La limpieza no debe basarse únicamente en antigüedad o tamaño; esos indicadores ayudan a localizar candidatos, pero no sustituyen la decisión del propietario.

¿Cómo se comprueba que los permisos son correctos?

Se utiliza una matriz de perfiles y recursos para probar accesos permitidos y accesos que deben impedirse. El recuento de asignaciones no demuestra que el resultado sea adecuado. Las pruebas deben hacerse con cuentas representativas, incluyendo colaboración externa cuando exista, y dejar evidencia de las excepciones aprobadas.

¿Por qué no basta con comparar gigabytes copiados?

El tamaño informa sobre el volumen, pero no confirma estructura, metadatos, búsqueda ni uso. Un destino puede contener la misma cantidad de datos y seguir sin servir para un proceso importante. La aceptación debe combinar informes técnicos, revisión de diferencias y pruebas del trabajo que realizan los usuarios con esa información.

Recomendaciones finales: migrar datos a Microsoft 365 es decidir primero y copiar después

Una migración de datos a Microsoft 365 puede involucrar correo, documentos, usuarios, SharePoint, OneDrive, Teams, aplicaciones e identidad. La tecnología de Microsoft ha evolucionado mucho y actualmente existen rutas nativas para una gran cantidad de escenarios. Migration Manager permite centralizar migraciones desde file shares y diversas plataformas externas. SharePoint Migration Tool continúa siendo especialmente útil para SharePoint Server y file shares. Exchange Online dispone de sus propias rutas de migración. Y las capacidades cross-tenant de Microsoft permiten abordar Exchange, OneDrive, SharePoint y determinados datos de Teams mediante herramientas específicas.

Pero ninguna herramienta sustituye la fase de diseño. Antes de mover un archivo deberíamos saber si pertenece al usuario o a la empresa. Antes de trasladar un sitio deberíamos conocer sus propietarios y permisos. Antes de mover un buzón deberíamos entender sus delegaciones y aplicaciones. Y antes de consolidar tenants deberíamos definir identidad, dominios y dependencias entre workloads.

También hay cambios tecnológicos que conviene incorporar a cualquier proyecto actual. Exchange Server 2016 y 2019 están fuera de su ciclo de soporte normal desde octubre de 2025. Microsoft Entra Cloud Sync es ahora la dirección estratégica para gran parte de los nuevos escenarios de identidad híbrida. Y Migration Orchestrator ofrece nuevas posibilidades tenant-to-tenant, pero su alcance debe interpretarse correctamente y no como un botón que traslada todo Microsoft 365.

Una buena metodología empieza con discovery y assessment, continúa con clasificación y arquitectura, selecciona después la herramienta, ejecuta un piloto y utiliza premigraciones cuando son posibles. El cutover debería estar documentado y la aceptación final debería combinar métricas técnicas con pruebas funcionales. Una migración termina cuando los usuarios y procesos adecuados pueden acceder a los datos correctos en Microsoft 365 con la identidad, permisos y estructura previstos.

Documentación oficial recomendada

Microsoft 365 Migration.

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

Migration Manager.

• Microsoft – Migration Manager for File Shares
• Microsoft – How Migration Manager Works
• Microsoft – File Share to SharePoint and OneDrive Migration Guide
• Microsoft – File Size Limitations for Migration

SharePoint Migration Tool.

• Microsoft – SharePoint Migration Tool
• Microsoft – How to Use SPMT

Google Workspace.

• Microsoft – Google Workspace Mail Migration
• Microsoft – Google Workspace Migration with Migration Manager

Exchange Online.

• Microsoft – Ways to Migrate Email to Microsoft 365
• Microsoft – Exchange Hybrid Deployments
• Microsoft – Exchange Server 2016 and 2019 End of Support
• Microsoft – Exchange Supportability Matrix

IMAP.

• Microsoft – IMAP Mailbox Migration

Tenant-to-Tenant.

• Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration
• Microsoft – Migration Orchestrator Overview
• Microsoft – Running a Migration with Migration Orchestrator
• Microsoft – Cross-Tenant Mailbox Migration
• Microsoft – Cross-Tenant OneDrive Migration
• Microsoft – Cross-Tenant SharePoint Migration

Microsoft Entra ID.

• Microsoft – What is Microsoft Entra Cloud Sync?
• Microsoft – Connect Sync to Cloud Sync Decision Guide