Migración de datos a Microsoft 365: guía completa para correo, archivos, SharePoint, OneDrive y Teams

Una migración de datos a Microsoft 365 puede implicar desde trasladar unos pocos buzones de correo hasta transformar por completo la forma en la que una empresa almacena documentos, gestiona identidades y colabora.

El error más habitual es reducir el proyecto a una pregunta demasiado sencilla: “¿qué herramienta utilizamos para copiar los datos?”

La pregunta debería ser otra:

¿qué información tenemos, quién debería ser su propietario y dónde debe vivir cuando termine la migración?

Un documento personal puede terminar en OneDrive. Una carpeta de departamento probablemente encaje mejor en SharePoint. El correo puede trasladarse a Exchange Online. Los archivos asociados a un Team terminarán relacionados con SharePoint. Las identidades deberán existir correctamente en Microsoft Entra ID y las aplicaciones que dependen del sistema anterior pueden necesitar una reconfiguración independiente.

Además, el procedimiento cambia completamente según el origen. Microsoft dispone actualmente de rutas específicas para file shares, SharePoint Server, Google Workspace, Exchange Server y migraciones entre tenants. También existen plataformas especializadas como Quest, ShareGate, AvePoint, BitTitan o Cloudiway.

Por eso una migración empresarial no debería comenzar copiando información, sino realizando un assessment que permita conocer volumen, número de objetos, permisos, propietarios, aplicaciones, dominios y requisitos de negocio.

En Kloudeal planteamos las migraciones a Microsoft 365 con este enfoque: analizamos el origen, diseñamos la arquitectura destino, seleccionamos las herramientas adecuadas, ejecutamos un piloto, realizamos las cargas previas posibles, coordinamos el cutover y validamos que la información y los servicios incluidos funcionan correctamente después del cambio.

En esta guía explicamos cómo abordar una migración de datos a Microsoft 365 en 2026, qué tecnologías ofrece actualmente Microsoft, cuándo utilizar OneDrive o SharePoint, qué cambia en correo, identidad y tenant-to-tenant y qué errores conviene evitar.

Índice

1. Qué es realmente una migración de datos a Microsoft 365
2. Tres principios antes de migrar
3. Principales escenarios de migración
4. Assessment e inventario
5. Clasificar antes de copiar
6. OneDrive o SharePoint
7. File server y NAS a Microsoft 365
8. Migration Manager para file shares
9. SharePoint Migration Tool
10. SharePoint Server a SharePoint Online
11. Google Workspace a Microsoft 365
12. Dropbox, Box y otros repositorios cloud
13. Exchange Server a Exchange Online
14. Exchange 2016 y 2019 en 2026
15. IMAP y otros proveedores de correo
16. POP3 y PST
17. Migración Tenant-to-Tenant
18. Microsoft Migration Orchestrator
19. Herramientas cross-tenant por workload
20. Microsoft Teams
21. Microsoft Entra ID e identidad
22. Cloud Sync o Connect Sync
23. Permisos, propietarios y sharing
24. Metadata, versiones y tipos de archivo
25. Límites técnicos y archivos grandes
26. Aplicaciones e integraciones
27. Seguridad durante una migración
28. Retención, Purview y cumplimiento
29. Cómo elegir herramienta
30. PowerShell y Microsoft Graph
31. Fases recomendadas
32. Piloto
33. Premigraciones y deltas
34. Cutover
35. Validación
36. Comunicación a usuarios
37. Cuánto tarda
38. Qué determina el coste
39. Errores frecuentes
40. Checklist
41. Preguntas frecuentes
42. Documentación oficial

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:

1. qué tenemos;
2. quién lo utiliza;
3. dónde debería terminar;
4. 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

Por ejemplo:

1. migración inicial;
2. usuarios continúan trabajando en origen;
3. delta;
4. cutover;
5. última sincronización;
6. 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

Conclusión: 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