Migrar a Microsoft 365: guía completa para empresas, planificación, herramientas y buenas prácticas
Migrar a Microsoft 365 no consiste simplemente en crear usuarios en la nube y copiar correo y documentos. En una empresa, Microsoft 365 puede convertirse en la plataforma sobre la que funcionan la identidad, el correo electrónico, los documentos, la colaboración, las reuniones, las aplicaciones empresariales, la seguridad y parte de la gestión de dispositivos.
Por eso una migración bien planteada comienza mucho antes de mover el primer dato.
Hay que entender cómo trabaja actualmente la organización, qué información existe, qué servicios dependen de otros, qué debería conservarse, qué merece la pena reorganizar y qué experiencia esperamos que tengan los usuarios cuando empiecen a trabajar en el nuevo entorno.
Una empresa que migra 200 buzones IMAP necesita una estrategia muy diferente de otra que quiere sustituir Exchange Server, file servers y Active Directory por una arquitectura híbrida o cloud. Del mismo modo, migrar desde Google Workspace no plantea los mismos retos que consolidar dos tenants de Microsoft 365 después de una adquisición.
Además, las herramientas disponibles han evolucionado. Microsoft dispone actualmente de diferentes rutas para migraciones desde plataformas externas y de capacidades específicas para movimientos entre tenants. A ellas se suman plataformas especializadas como Quest, ShareGate, AvePoint, BitTitan o Cloudiway.
Esta guía explica cómo planificar una migración empresarial a Microsoft 365 en 2026, qué decisiones deben tomarse antes, cómo tratar Exchange Online, OneDrive, SharePoint, Teams, Microsoft Entra ID y seguridad, qué herramientas existen y qué errores conviene evitar.
Migrar a Microsoft 365 no significa moverlo todo de la misma manera
| Origen | Destino habitual | Consideración principal |
|---|---|---|
| Exchange Server | Exchange Online | Correo, calendarios, coexistencia, identidad y aplicaciones. |
| IMAP | Exchange Online | Principalmente correo; contactos y calendarios requieren otro tratamiento. |
| Google Workspace | Microsoft 365 | Gmail, Drive, calendarios, identidades y colaboración. |
| File server / NAS | SharePoint y OneDrive | Decidir primero dónde debe vivir cada tipo de información. |
| Dropbox / Box / Google Drive | SharePoint y OneDrive | Mapping, estructura, permisos y contenido compartido. |
| Microsoft 365 | Otro tenant Microsoft 365 | Dependencias entre Exchange, OneDrive, SharePoint, Teams, identidad y dominios. |
La primera decisión no es qué herramienta utilizar. Es definir cómo debe quedar el entorno después de la migración.
¿Estás preparando una migración a Microsoft 365?
Podemos analizar el entorno actual, identificar usuarios, datos, correo, repositorios, permisos, dominios y aplicaciones y ayudarte a definir una estrategia antes de adquirir licencias o fijar el cutover.
Analizar mi migración a Microsoft 365Índice
- Qué significa realmente migrar a Microsoft 365
- Por qué migrar a Microsoft 365
- Qué decidir antes de empezar
- Assessment e inventario del entorno
- Microsoft Entra ID e identidad
- Entra Cloud Sync o Connect Sync
- Licencias y costes
- Migración de correo a Exchange Online
- Migraciones IMAP
- Exchange Server y migraciones híbridas
- Google Workspace a Microsoft 365
- Migración de archivos
- OneDrive o SharePoint: dónde debe ir cada dato
- Migración a SharePoint Online
- Migración a OneDrive
- Microsoft Teams y colaboración
- Seguridad antes, durante y después de la migración
- MFA y acceso condicional
- SPF, DKIM, DMARC y seguridad del correo
- Microsoft Purview y cumplimiento
- Microsoft Intune y dispositivos
- Aplicaciones e integraciones
- Herramientas de migración
- Fases de una migración Microsoft 365
- Cómo diseñar el piloto
- Cutover y cambio final
- Comunicación y adopción de usuarios
- Validación posterior
- Cuánto tarda una migración
- Cuánto cuesta migrar a Microsoft 365
- Errores habituales
- Checklist de migración
- Preguntas frecuentes
- Documentación oficial
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.
| Área | Servicios habituales | Qué cambia |
|---|---|---|
| Correo | Exchange Online | Buzones, calendarios, shared mailboxes, dominios y mail flow. |
| Documentación | SharePoint Online / OneDrive | Almacenamiento, colaboración, permisos y estructura. |
| Colaboración | Microsoft Teams | Chat, reuniones, equipos, canales y aplicaciones. |
| Identidad | Microsoft Entra ID | Usuarios, grupos, MFA, SSO y acceso a aplicaciones. |
| Dispositivos | Microsoft Intune | Administración, cumplimiento y aplicaciones. |
| Seguridad | Entra, Defender, Purview | Acceso, protección, auditoría y gobierno de datos. |
| Productividad | Microsoft 365 Apps | Word, Excel, Outlook, PowerPoint y aplicaciones relacionadas. |
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.
| Pregunta | Ejemplo de decisión |
|---|---|
| ¿Dónde estará el correo? | Exchange Online para todos los usuarios. |
| ¿Dónde estarán los documentos? | Información personal en OneDrive y documentación de equipo en SharePoint. |
| ¿Existirá Active Directory local? | Mantener identidad híbrida temporalmente. |
| ¿Cómo se protegerá el acceso? | MFA y Conditional Access según licenciamiento. |
| ¿Quién podrá crear Teams? | Definir modelo de gobierno y propietarios. |
| ¿Cómo se gestionarán dispositivos? | Intune cuando forme parte de la estrategia. |
| ¿Qué datos no merece la pena migrar? | Duplicados, temporales y contenido obsoleto. |
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.
| Área | Información que buscamos |
|---|---|
| Usuarios | Activos, inactivos, externos, cuentas de servicio, grupos y administradores. |
| Correo | Número y tamaño de buzones, Archives, shared mailboxes, permisos, recursos y dominios. |
| Archivos | File servers, NAS, Dropbox, Google Drive, Box, SharePoint Server y volumen. |
| Permisos | ACL, permisos únicos, usuarios externos y propietarios. |
| Aplicaciones | SSO, OAuth, SMTP, SCIM, Graph, ERP, CRM y otras integraciones. |
| Identidad | Active Directory, dominios, UPN, grupos, sincronización y autenticación. |
| Red | Conectividad y capacidad disponible para mover datos. |
| Seguridad | MFA, políticas de acceso, antivirus, protección de correo, retención y auditoría. |
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.
¿No tienes un inventario completo?
No es necesario conocer todos los detalles antes de empezar. Podemos realizar un discovery del entorno y obtener la información necesaria para definir arquitectura, herramientas, costes y calendario.
Solicitar assessment de Microsoft 365Microsoft 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.
| Modelo | Características |
|---|---|
| Cloud-only | Los usuarios y grupos se administran principalmente desde Microsoft Entra ID. |
| Híbrido | Parte de las identidades continúa teniendo Active Directory como origen y se sincroniza con Microsoft Entra ID. |
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.
| Característica | Cloud Sync | Connect Sync |
|---|---|---|
| Usuarios, grupos y contactos | Sí | Sí |
| Varios bosques | Sí | Sí |
| Bosques desconectados | Sí | No de forma equivalente |
| Agentes activos múltiples | Sí | Modelo diferente |
| Sincronización de dispositivos | No actualmente | Sí |
| Reglas avanzadas de sincronización | Más limitada | Mayor flexibilidad |
| Gestión cloud | Sí | Servidor de sincronización local |
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.
| Necesidad | Qué debe comprobarse |
|---|---|
| Solo correo | Capacidad de Exchange Online necesaria. |
| Correo + Office | Aplicaciones de escritorio y servicios incluidos. |
| Conditional Access | Licencia Microsoft Entra ID adecuada. |
| Intune | Licenciamiento de administración de dispositivos. |
| Defender | Plan de seguridad requerido. |
| Purview | Funcionalidades concretas de compliance necesarias. |
| Copilot | Licencia base compatible y licencia adicional cuando proceda. |
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.
| Elemento | Qué debemos revisar |
|---|---|
| Buzones | Número, tamaño y crecimiento. |
| Archive | Volumen y método de migración. |
| Shared Mailboxes | Contenido, propietarios y delegaciones. |
| Salas y recursos | Calendarios y configuración. |
| Dominios | SMTP principal y aliases. |
| Permisos | Full Access, Send As y Send on Behalf. |
| Reglas | Inbox Rules y reglas de transporte. |
| Aplicaciones | SMTP, OAuth y relays. |
| DNS | MX, Autodiscover, SPF, DKIM y DMARC. |
Rutas de migración posibles
El procedimiento depende del origen.
| Origen | Enfoques habituales |
|---|---|
| Exchange Server | Cutover, staged o híbrido dependiendo de versión y entorno. |
| IMAP | Migración de mensajes y carpetas mediante IMAP. |
| Google Workspace | Métodos Microsoft o plataformas especializadas. |
| Otro tenant Microsoft 365 | Cross-Tenant Mailbox Migration o herramientas especializadas. |
| PST | Importación cuando es el método adecuado para el escenario. |
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:
| Elemento | IMAP |
|---|---|
| Correo | Sí |
| Carpetas de correo | Sí |
| Contactos | No mediante IMAP |
| Calendarios | No mediante IMAP |
| Tareas | No |
| Reglas del cliente | No |
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 Workspace | Destino Microsoft habitual |
|---|---|
| Gmail | Exchange Online |
| Google Calendar | Exchange Online / Outlook |
| Google Contacts | Exchange Online |
| My Drive | OneDrive |
| Shared Drives | SharePoint |
| Google Groups | Grupos, listas u objetos Microsoft 365 según uso. |
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.
| Pregunta | OneDrive | SharePoint |
|---|---|---|
| ¿De quién es el contenido? | Principalmente del usuario. | Del equipo o de la organización. |
| ¿Quién trabaja con él? | Usuario y personas con las que comparte. | Equipos, departamentos o proyectos. |
| ¿Debe sobrevivir a la salida del usuario? | No debería ser el repositorio principal de información corporativa compartida. | Sí, está diseñado para contenido organizativo. |
| Ejemplo | Documentos de trabajo personales. | Documentación de RRHH, Finanzas, proyectos o procedimientos. |
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.
| Elemento | Decisión |
|---|---|
| Carpetas antiguas | Migrar, archivar o eliminar. |
| Duplicados | Consolidar cuando sea posible. |
| Permisos NTFS | Diseñar equivalencia en SharePoint. |
| Profundidad de carpetas | Simplificar cuando aporte valor. |
| Metadata | Conservar o rediseñar. |
| Propietarios | Asignar responsables de negocio. |
| Acceso externo | Validar quién debe conservarlo. |
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.
| Lo que ve el usuario | Servicio relacionado |
|---|---|
| Equipo | Microsoft 365 Group / Microsoft Entra ID |
| Archivos de canales | SharePoint Online |
| Archivos compartidos por chat | OneDrive |
| Reuniones | Teams + Exchange Online |
| Miembros e invitados | Microsoft Entra ID y configuración de Teams |
| Apps y tabs | Teams y servicios asociados |
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:
| Área | Decisión recomendada |
|---|---|
| Propietarios | Cada Team debería tener responsables identificados. |
| Nombres | Usar una nomenclatura comprensible. |
| Invitados | Definir cuándo se permite colaboración externa. |
| Apps | Controlar qué aplicaciones pueden utilizarse. |
| Ciclo de vida | Revisar equipos abandonados o proyectos terminados. |
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.
| Área | Objetivo |
|---|---|
| MFA | Reducir riesgo por robo de credenciales. |
| Conditional Access | Aplicar controles según usuario, dispositivo, riesgo y recurso. |
| Roles | Reducir privilegios administrativos permanentes. |
| Break-glass | Mantener acceso de emergencia controlado. |
| Correo | Configurar protección y autenticación del dominio. |
| Acceso externo | Controlar invitados y sharing. |
| Auditoría | Disponer de visibilidad sobre acciones relevantes. |
| Datos sensibles | Aplicar políticas de protección cuando correspondan. |
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.
¿Vas a activar Microsoft 365 y todavía no tienes definida la seguridad?
Podemos integrar en el proyecto una revisión de identidad y seguridad para evitar que el nuevo entorno empiece a funcionar con administradores, usuarios o aplicaciones sin los controles adecuados.
Revisar seguridad de Microsoft 365SPF, DKIM y DMARC durante la migración
El cambio de plataforma de correo debería aprovecharse para revisar la autenticación del dominio.
| Control | Función |
|---|---|
| SPF | Indica qué sistemas están autorizados a enviar correo para el dominio. |
| DKIM | Firma criptográficamente los mensajes enviados. |
| DMARC | Define cómo tratar mensajes que no superan correctamente SPF/DKIM y proporciona reporting. |
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:
| Área | Ejemplo |
|---|---|
| Information Protection | Etiquetas de sensibilidad. |
| DLP | Prevención de pérdida de información. |
| Endpoint DLP | Controles sobre dispositivos compatibles. |
| Retention | Conservación y eliminación de información. |
| eDiscovery | Búsqueda y gestión de información para procesos legales. |
| Audit | Investigación de actividad. |
| Insider Risk | Escenarios de riesgo interno cuando proceda. |
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
| Pregunta | Ejemplo |
|---|---|
| ¿Qué dispositivos se administrarán? | Windows, macOS, iOS o Android. |
| ¿Empresa o BYOD? | Modelos de administración distintos. |
| ¿Qué define un dispositivo compliant? | Cifrado, versión, protección y otras políticas. |
| ¿Conditional Access dependerá del dispositivo? | Requerir dispositivo compliant en determinadas aplicaciones. |
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.
| Dependencia | Qué revisar |
|---|---|
| SSO | Tenant, claims, certificados y grupos. |
| SCIM | Provisioning, endpoint, token y mappings. |
| Microsoft Graph | App Registration, permisos y tenant ID. |
| OAuth | Client ID, secretos, certificados y redirect URIs. |
| SMTP | Método de autenticación y relay. |
| Backup | Nuevo tenant y permisos de aplicación. |
| Power Automate | Conexiones y connection references. |
| Power Apps | Entornos, conexiones y usuarios. |
| Power BI | Workspaces, permisos, gateways y fuentes. |
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:
| Workload | Herramienta Microsoft |
|---|---|
| Exchange Online | Cross-Tenant Mailbox Migration |
| OneDrive | Cross-Tenant OneDrive Migration |
| SharePoint | Cross-Tenant SharePoint Migration |
| Varios datos de usuario | Microsoft 365 Migration Orchestrator |
Herramientas especializadas
También existen plataformas de terceros que pueden ser más adecuadas para determinados proyectos.
| Herramienta | Puede resultar especialmente útil para |
|---|---|
| Quest On Demand Migration | Tenant-to-tenant multiworkload, Teams, SharePoint, Exchange, OneDrive e identidad. |
| ShareGate | SharePoint, OneDrive, Teams y reorganización de contenido, además de sus capacidades tenant-to-tenant actuales. |
| AvePoint Fly | Migraciones enterprise y proyectos con varias cargas o gobierno. |
| BitTitan MigrationWiz | Correo y otros workloads mediante proyectos SaaS. |
| Cloudiway | Microsoft 365 y escenarios cross-platform. |
| CodeTwo | Migraciones donde Exchange es la carga principal. |
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.
| Fase | Objetivo |
|---|---|
| 1. Discovery | Entender el entorno actual. |
| 2. Diseño | Definir el entorno Microsoft 365 futuro. |
| 3. Preparación | Configurar tenant, identidad, dominios, licencias y seguridad base. |
| 4. Piloto | Validar herramienta, tiempos y experiencia. |
| 5. Premigración | Mover previamente los datos que sea posible. |
| 6. Migración | Ejecutar oleadas o lotes. |
| 7. Cutover | Realizar cambios finales de servicio, identidad o DNS. |
| 8. Validación | Comprobar técnica y funcionalmente el entorno. |
| 9. Hypercare | Resolver incidencias posteriores al cambio. |
| 10. Optimización | Retirar elementos temporales y mejorar el entorno. |
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.
| Caso piloto | Qué permite comprobar |
|---|---|
| Buzón estándar | Flujo habitual. |
| Buzón grande | Rendimiento. |
| Shared mailbox | Permisos y delegaciones. |
| Usuario con Archive | Histórico de correo. |
| Usuario con mucho OneDrive | Datos y sharing. |
| SharePoint complejo | Permisos, metadata y versiones. |
| Usuario con aplicaciones | SSO y dependencias. |
| Usuario remoto | Experiencia fuera de la oficina. |
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é
| Momento | Ejemplo |
|---|---|
| T-24 h | Revisión de jobs, usuarios, permisos y backups necesarios. |
| T-4 h | Comprobación de herramientas y últimas comunicaciones. |
| T0 | Inicio del procedimiento de corte. |
| T+1 h | Cambios de DNS o dominios según estrategia. |
| T+2 h | Sincronizaciones finales y validación técnica. |
| Antes de apertura | Pruebas con usuarios seleccionados. |
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.
| Antes de la migración | Después de la migración |
|---|---|
| Fecha del cambio. | Cómo iniciar sesión. |
| Qué servicios estarán afectados. | Dónde encontrar correo y documentos. |
| Qué debe evitar durante la ventana. | Cómo utilizar Teams y OneDrive. |
| Si cambiará su identidad. | Qué hacer si una aplicación pide autenticarse. |
| Canal de soporte. | Cómo reportar una incidencia. |
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.
| Área | Prueba |
|---|---|
| Identidad | Inicio de sesión y MFA. |
| Exchange | Enviar y recibir correo interno y externo. |
| Calendario | Crear y recibir reuniones. |
| Shared mailboxes | Acceso y envío. |
| OneDrive | Abrir, modificar y compartir archivos. |
| SharePoint | Contenido, permisos y navegación. |
| Teams | Equipos, reuniones y archivos. |
| Aplicaciones | SSO e integraciones incluidas. |
| DNS | MX, SPF, DKIM, DMARC y Autodiscover. |
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.
| Factor | Impacto |
|---|---|
| Número de usuarios | Aumenta tareas de preparación y soporte. |
| Tamaño de buzones | Afecta al tiempo de copia. |
| Volumen de archivos | Impacta en SharePoint y OneDrive. |
| Número de elementos | Puede importar tanto como el volumen en GB. |
| Aplicaciones | Añaden validaciones y cambios. |
| Identidad híbrida | Añade dependencias. |
| Coexistencia | Puede alargar la duración total. |
| Herramienta | Determina concurrencia, deltas y automatización. |
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.
| Coste | Ejemplo |
|---|---|
| Consultoría y assessment | Análisis del entorno y diseño. |
| Licencias Microsoft | Planes Microsoft 365 y servicios adicionales. |
| Licencias de migración | Quest, BitTitan, ShareGate u otras si se utilizan. |
| Trabajo técnico | Preparación, ejecución y troubleshooting. |
| Aplicaciones | Reconfiguración de integraciones. |
| Coexistencia | Configuraciones o licenciamiento temporal. |
| Soporte | Hypercare y estabilización. |
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.
¿Quieres una valoración de vuestra migración?
Con unos datos iniciales —usuarios, buzones, origen del correo, volumen documental, SharePoint, Teams, identidad y fecha objetivo— podemos revisar el escenario y determinar qué información adicional necesitamos para preparar el alcance.
Solicitar valoración de migración Microsoft 365Errores habituales al migrar a Microsoft 365
| Error | Consecuencia | Mejor enfoque |
|---|---|---|
| Comprar licencias antes de diseñar | Planes incorrectos o sobredimensionados. | Definir perfiles primero. |
| Migrar sin inventario | Objetos y datos olvidados. | Discovery previo. |
| Copiar todo el file server | SharePoint hereda el desorden anterior. | Clasificar antes. |
| Usar OneDrive para documentación departamental | Información corporativa dependiente de una persona. | Evaluar SharePoint. |
| No revisar shared mailboxes | Usuarios pierden permisos. | Inventariar delegaciones. |
| Olvidar aplicaciones SMTP | ERP, webs o dispositivos dejan de enviar. | Inventariar remitentes. |
| Activar Conditional Access sin probar | Usuarios o administradores bloqueados. | Utilizar Report-only y validar. |
| No preparar MFA | Problemas de acceso y menor seguridad. | Registrar y comunicar previamente. |
| Activar Teams sin gobierno | Proliferación de equipos y permisos. | Definir reglas simples. |
| No revisar aplicaciones | SSO, SMTP o integraciones dejan de funcionar. | Inventariarlas antes del cutover. |
| No hacer piloto | Los problemas aparecen durante la migración masiva. | Probar casos complejos. |
| Prometer impacto cero | Expectativas poco realistas. | Explicar cambios previstos. |
| Cerrar cuando el job está verde | Incidencias funcionales no detectadas. | Validación técnica y funcional. |
Checklist para una migración a Microsoft 365
| Área | Comprobación |
|---|---|
| Objetivos | Está definido por qué migramos y cómo debe quedar el entorno. |
| Usuarios | Activos, inactivos, externos y cuentas especiales inventariados. |
| Licencias | Perfiles de usuario y necesidades revisados. |
| Identidad | Cloud-only o híbrida definido. |
| Sincronización | Cloud Sync o Connect Sync evaluado si hay AD local. |
| Dominios | Verificados y estrategia DNS preparada. |
| Correo | Buzones, Archives, compartidos y permisos inventariados. |
| Mail flow | Conectores, aplicaciones SMTP y relays revisados. |
| DNS de correo | MX, SPF, DKIM, DMARC y Autodiscover preparados. |
| Archivos | Repositorios y volumen conocidos. |
| OneDrive / SharePoint | Destino definido según propiedad de la información. |
| Permisos | Usuarios, grupos e invitados revisados. |
| Teams | Modelo de colaboración y gobierno definido. |
| Aplicaciones | SSO, Graph, OAuth, SMTP y SCIM inventariados. |
| Seguridad | MFA y políticas básicas preparadas. |
| Conditional Access | Políticas probadas antes de activarse. |
| Purview | Requisitos de retención y compliance revisados. |
| Herramienta | Seleccionada según origen y workload. |
| Piloto | Usuarios y datos representativos seleccionados. |
| Runbook | Secuencia y responsables documentados. |
| Comunicación | Usuarios informados. |
| Validación | Criterios de aceptación definidos. |
| Hypercare | Soporte posterior planificado. |
Preguntas frecuentes sobre migrar a Microsoft 365
Significa trasladar servicios, datos o procesos de una organización a la plataforma Microsoft 365.
Puede incluir Exchange Online, OneDrive, SharePoint, Microsoft Teams, Microsoft Entra ID, seguridad, aplicaciones y otros servicios dependiendo del proyecto.
No exactamente.
Office 365 fue utilizado durante años para denominar diferentes planes centrados en productividad. Microsoft 365 engloba actualmente una propuesta más amplia que puede incluir productividad, identidad, seguridad, administración de dispositivos y otros servicios según el plan.
Sí.
Microsoft dispone de diferentes métodos para trasladar buzones de Exchange Server a Exchange Online, incluyendo modelos híbridos cuando la coexistencia y el entorno lo requieren.
Sí, pero el procedimiento debe definirse según versión, número de buzones, coexistencia necesaria, autenticación, aplicaciones y arquitectura.
No conviene escoger automáticamente el mismo método para todos los Exchange Server.
Sí.
IMAP permite trasladar fundamentalmente correo y carpetas. Calendarios, contactos, tareas y otras funciones no forman parte del protocolo IMAP y necesitan otro tratamiento cuando deben conservarse.
Sí.
Puede migrarse correo de Gmail y contenido de Google Drive hacia los servicios correspondientes de Microsoft 365 mediante herramientas nativas o plataformas especializadas.
El alcance exacto debe definirse para Gmail, Calendar, Contacts, My Drive, Shared Drives y Groups.
Sí.
Microsoft Migration Manager dispone actualmente de una ruta de migración para Dropbox y también existen herramientas especializadas.
Antes de iniciar los jobs conviene decidir qué información debe terminar en OneDrive y cuál en SharePoint.
Sí.
Microsoft dispone de herramientas como SharePoint Migration Tool y Migration Manager.
Antes de migrar recomendamos revisar carpetas obsoletas, permisos, profundidad, volumen y estructura de destino.
OneDrive es normalmente el destino de información de trabajo personal.
SharePoint resulta más apropiado para documentación que pertenece a departamentos, proyectos, equipos o procesos de la organización.
Técnicamente puede ser posible en determinados casos, pero no siempre es una buena arquitectura.
Si la información pertenece al departamento y no al usuario, SharePoint suele ser un destino más adecuado.
No necesariamente.
Depende de aplicaciones, servidores, dispositivos y requisitos de la organización.
Algunas empresas evolucionan hacia un modelo cloud-only y otras mantienen identidad híbrida durante años.
Microsoft Entra ID es el servicio de identidad y acceso de Microsoft anteriormente denominado Azure Active Directory.
Gestiona usuarios, grupos, autenticación, aplicaciones, MFA y otras capacidades de acceso.
Es el servicio moderno de Microsoft para sincronizar usuarios, grupos y contactos entre Active Directory y Microsoft Entra ID utilizando agentes ligeros y administración cloud.
Microsoft lo posiciona actualmente como dirección estratégica para la mayoría de nuevos escenarios de sincronización.
No todavía en todos los escenarios.
Connect Sync mantiene capacidades que Cloud Sync no cubre actualmente de la misma manera, como sincronización de dispositivos y determinadas reglas avanzadas.
La elección debe hacerse utilizando la comparativa vigente de Microsoft.
MFA debe considerarse un requisito básico de seguridad.
Además, Microsoft ha ido introduciendo MFA obligatorio en sus portales y herramientas administrativas.
La organización debe decidir si utilizar Security Defaults, Conditional Access u otros mecanismos según su licenciamiento y arquitectura.
Security Defaults proporciona una configuración de seguridad base gestionada y sencilla.
Conditional Access permite crear políticas mucho más granulares basadas en usuarios, roles, dispositivos, riesgos, ubicaciones y recursos, pero requiere licenciamiento de Microsoft Entra adecuado.
No necesariamente.
Es preferible preparar las políticas previamente, utilizar Report-only para evaluar el impacto y activar progresivamente los controles una vez validados.
Sí conviene revisar los tres.
SPF, DKIM y DMARC ayudan a proteger la identidad del dominio y la autenticidad del correo.
La implantación debe tener en cuenta todas las aplicaciones y servicios que envían correo como la organización.
Depende del plan y configuración, pero técnicamente disponer del servicio no significa que exista una estrategia de Teams.
Conviene definir propietarios, equipos, canales, invitados, aplicaciones y ciclo de vida.
Los archivos de canales se almacenan principalmente en SharePoint Online.
Los archivos compartidos en chats se relacionan normalmente con OneDrive.
Por eso Teams, SharePoint y OneDrive deben diseñarse conjuntamente.
Sí existen herramientas y APIs para distintos componentes, pero “migrar Teams” debe definirse con precisión.
Hay que distinguir equipos, canales, archivos, conversaciones, chats, Planner, aplicaciones e invitados.
Microsoft utiliza actualmente Migration Manager para centralizar diferentes migraciones de contenido externo hacia Microsoft 365, además de herramientas específicas como SharePoint Migration Tool.
Microsoft 365 Migration Orchestrator está orientado a coordinar determinados workloads en migraciones tenant-to-tenant.
Debe diferenciarse de Migration Manager, que está orientado a otros escenarios de incorporación de contenido.
Sí.
Herramientas como Quest On Demand Migration, ShareGate, AvePoint, BitTitan MigrationWiz y Cloudiway pueden ser adecuadas dependiendo del origen, destino y workloads.
La herramienta debería seleccionarse después del assessment.
No.
Una buena herramienta automatiza muchas operaciones, pero no decide la arquitectura, limpia los datos por sí sola ni identifica automáticamente todas las aplicaciones y dependencias del negocio.
Es muy recomendable en proyectos con cierta complejidad.
El piloto permite conocer tiempos reales y probar buzones, archivos, permisos, aplicaciones y usuarios antes de ejecutar la migración masiva.
El proyecto puede diseñarse para reducir el impacto, pero no conviene garantizar interrupción cero.
DNS, correo, identidad, aplicaciones, perfiles o autenticación pueden requerir una transición.
Depende del workload y de la tecnología utilizada.
Muchas herramientas permiten realizar premigraciones mientras los usuarios siguen trabajando y ejecutar posteriormente deltas o sincronizaciones finales.
Otros métodos utilizan un movimiento definitivo y necesitan otro diseño de cutover.
Depende de usuarios, tamaño de buzones, volumen y número de archivos, herramientas, aplicaciones, identidad, red y alcance.
El assessment y el piloto permiten estimar el calendario con mayor precisión.
Depende del alcance.
El coste puede incluir assessment, licencias Microsoft, licencias de herramientas, trabajo técnico, aplicaciones, coexistencia y soporte posterior.
No necesariamente.
Los planes deberían asignarse según las necesidades de cada perfil y las funcionalidades de seguridad y administración que requiere la organización.
Es recomendable.
Una migración es una buena oportunidad para archivar información antigua, eliminar duplicados y evitar trasladar contenido que ya no aporta valor.
Deben inventariarse.
Las aplicaciones que dependen de SMTP, OAuth, Microsoft Graph, SSO, SCIM o cuentas de servicio pueden necesitar reconfiguración durante la migración.
Deben analizarse como aplicaciones y no simplemente como documentos.
Pueden existir dependencias de entorno, conexiones, owners, connection references, Dataverse y permisos.
Sí, cuando la gestión de dispositivos forma parte de la estrategia.
Intune puede administrar dispositivos, aplicaciones y compliance, pero debe diseñarse conjuntamente con identidad y Conditional Access.
Es recomendable ofrecer formación adaptada a los cambios reales.
Los temas más útiles suelen ser Teams, OneDrive, SharePoint, sharing, MFA y las nuevas formas de inicio de sesión.
No basta con revisar que la herramienta muestre todos los jobs como completados.
Hay que validar inicio de sesión, correo, calendarios, documentos, permisos, Teams, aplicaciones y otros componentes incluidos.
Especialmente cuando existen varios workloads, Exchange Server, identidad híbrida, muchos datos, SharePoint complejo, Teams, aplicaciones críticas, varios dominios o poco margen para incidencias.
También puede resultar útil cuando todavía no está claro qué herramientas o licencias necesita el proyecto.
Conclusión: 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.
¿Necesitas migrar vuestra empresa a Microsoft 365?
En Kloudeal podemos ayudarte a analizar el entorno actual y preparar un proyecto de migración adaptado a vuestra organización.
Podemos trabajar sobre Exchange Online, migraciones IMAP, Google Workspace, OneDrive, SharePoint, Microsoft Teams, Microsoft Entra ID, identidad híbrida, dominios, DNS, seguridad, herramientas de migración, aplicaciones y validación posterior.
El primer paso puede ser simplemente revisar vuestro escenario y determinar qué información necesitamos para preparar el alcance, las herramientas y la estrategia.
Hablar con Kloudeal sobre mi migración a Microsoft 365Documentación oficial recomendada
Microsoft 365 Migration
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