Guía completa de migración a Microsoft 365: pasos, costes, riesgos, seguridad y checklist para hacerlo sin perder datos

Resumen rápido: migración a Microsoft 365 en 15 puntos

1. No empieces por la herramienta: empieza por el assessment. Primero hay que saber qué se va a migrar, cuánto ocupa, quién lo usa y qué riesgos tiene.
2. Define el alcance real: correo, calendarios, contactos, archivos, Teams, usuarios, grupos, dispositivos, aplicaciones, permisos, DNS y seguridad.
3. El correo es lo más visible: si Outlook no funciona el primer día, el usuario percibe que todo el proyecto ha fallado.
4. IMAP no lo migra todo: sirve para correo y carpetas, pero no para calendarios, contactos, tareas, reglas o firmas.
5. OneDrive no sustituye a SharePoint: OneDrive es para archivos personales de trabajo; SharePoint es para información compartida por equipos o departamentos.
6. Teams necesita gobierno: si se despliega sin normas, aparecen equipos duplicados, canales vacíos y archivos dispersos.
7. La identidad manda: UPN, alias, grupos, roles, MFA y Acceso Condicional deben estar definidos antes del corte.
8. DNS es crítico: MX, SPF, DKIM, DMARC y Autodiscover deben prepararse y probarse antes del cambio final.
9. La seguridad debe activarse desde el principio: MFA, bloqueo de autenticación heredada, Defender, políticas de compartición y auditoría.
10. No todos los usuarios necesitan la misma licencia: combinar planes según perfil puede reducir costes sin perder seguridad.
11. Power Platform puede romperse: flujos, conectores y apps dependen de cuentas, permisos y rutas que pueden cambiar.
12. Intune mejora el control: especialmente si hay portátiles, móviles, BYOD o acceso remoto a información sensible.
13. La comunicación evita tickets: el usuario necesita instrucciones breves, no un documento técnico de veinte páginas.
14. Un piloto real vale más que muchas suposiciones: debe incluir usuarios con correo, archivos, móvil, permisos y casos de negocio reales.
15. La migración termina cuando el negocio valida: no cuando la herramienta dice “completed”.

¿Para quién es esta guía?

Esta guía está pensada para responsables de IT, dirección, gerentes, responsables de operaciones y equipos que tienen que tomar decisiones sobre una migración a Microsoft 365. No es solo una guía técnica: también explica las decisiones de negocio que conviene tomar antes de mover datos.

Te resultará útil si…

• Tu empresa quiere dejar un servidor de correo antiguo o un hosting IMAP.
• Quieres migrar desde Google Workspace, Zoho u otra suite de productividad.
• Tienes archivos repartidos en un file server, NAS, Dropbox, Google Drive o carpetas locales.
• Quieres implantar Teams de forma ordenada, no como “otra herramienta más”.
• Necesitas mejorar seguridad con MFA, Acceso Condicional, Defender, Intune o Purview.
• Quieres estimar esfuerzo, coste, riesgos y plazos antes de arrancar.
• Necesitas justificar internamente por qué conviene hacerlo con un partner especializado.

¿Cuándo conviene migrar a Microsoft 365?

La decisión de migrar suele aparecer cuando el entorno actual empieza a quedarse corto: falta de seguridad, demasiadas herramientas, problemas de acceso remoto, servidores antiguos, poca trazabilidad, archivos duplicados o usuarios que trabajan cada uno “a su manera”.

Motivos habituales para migrar

• Correo inestable o limitado: buzones pequeños, falta de antiphishing, mala experiencia móvil o problemas de entregabilidad.
• Demasiadas herramientas dispersas: correo en un proveedor, archivos en otro, reuniones en otra plataforma y documentos locales.
• Trabajo híbrido o remoto: necesidad de acceder de forma segura desde cualquier lugar.
• Servidores locales en fin de vida: Exchange, file server o infraestructura que ya no compensa mantener.
• Crecimiento de la empresa: más usuarios, más sedes, más colaboración y más necesidad de gobierno.
• Fusiones o reorganizaciones: unificar dominios, usuarios y datos en una plataforma común.
• Seguridad insuficiente: ausencia de MFA, contraseñas débiles, accesos externos sin control o poca auditoría.
• Requisitos de cumplimiento: retención, eDiscovery, DLP, clasificación de información o auditorías.
• Adopción de Teams: centralizar reuniones, chat, documentos y colaboración en una experiencia integrada.

Cuándo conviene esperar

Migrar con prisa rara vez sale bien. Puede convenir esperar o preparar mejor el proyecto si no existe inventario, si el dominio está mal documentado, si hay aplicaciones críticas sin dueño, si nadie sabe qué permisos hay en el file server o si la dirección no ha aprobado una ventana de cambio.

Desde dónde se suele migrar a Microsoft 365

No todas las migraciones empiezan en el mismo punto. El origen condiciona el método, la herramienta, los riesgos y el esfuerzo.

Introducción: migrar a Microsoft 365 es un proyecto de negocio

Una migración a Microsoft 365 se suele vender como un proyecto técnico, pero el impacto real lo nota el negocio. Si el correo falla, ventas se bloquea. Si los permisos se migran mal, finanzas se expone. Si los usuarios no entienden Teams, vuelven al correo y a los adjuntos. Si SharePoint se diseña como un volcado de carpetas, nadie encuentra nada.

Por eso conviene plantear la migración como un proyecto transversal. IT ejecuta y coordina, pero negocio debe validar qué información es crítica, quién puede acceder a qué, qué procesos dependen del correo, qué carpetas se archivan y qué usuarios requieren soporte especial.

1. Decisiones clave antes de empezar

En la práctica: las decisiones importantes se toman antes de migrar. Después del corte, cada duda se convierte en incidencia.

Preguntas que conviene responder por escrito

• ¿Qué cargas se migran: correo, archivos, Teams, dispositivos, aplicaciones?
• ¿Quién aprueba el cambio de dominio?
• ¿Qué usuarios se consideran críticos?
• ¿Qué información no debe migrarse porque está obsoleta?
• ¿Qué datos requieren retención o cumplimiento?
• ¿Quién decide permisos en SharePoint?
• ¿Qué nivel de soporte habrá el día del corte?
• ¿Cuándo se puede retirar el entorno antiguo?

2. Metodología recomendada: de assessment a estabilización

En la práctica: una migración ordenada se divide en fases. Cada fase tiene entregables, responsables y criterios de salida.

2.1 Descubrimiento y assessment

Se recopila información técnica y funcional. No basta con contar usuarios: hay que entender buzones, calendarios, permisos, archivos, dispositivos, aplicaciones y dependencias. Esta fase permite estimar esfuerzo, riesgos y herramientas necesarias.

2.2 Diseño del destino

Se define cómo quedará Microsoft 365: licencias, usuarios, grupos, dominios, políticas de seguridad, Teams, sitios de SharePoint, estructura de OneDrive, retención y modelo de soporte.

2.3 Preparación del tenant

Se configura el entorno: dominios, usuarios, licencias, grupos, Exchange Online, OneDrive, SharePoint, Teams, seguridad base, roles administrativos y políticas iniciales.

2.4 Piloto

Se migran usuarios representativos. El piloto debe probar correo, Outlook, móvil, archivos, Teams, MFA, permisos y procesos reales. Un piloto con usuarios “fáciles” no sirve para detectar problemas.

2.5 Precarga y oleadas

Se migran datos antes del corte final para reducir tiempos. En correo, puede hacerse sincronización inicial e incremental. En archivos, se pueden ejecutar cargas previas y sincronizar cambios antes de la ventana final.

2.6 Corte controlado

Se actualiza DNS, se cambia el flujo de correo, se validan servicios y se comunica a usuarios. Debe haber responsables, checklist y plan de reversa.

2.7 Estabilización

Se revisan incidencias, permisos, accesos, adopción, seguridad y experiencia de usuario. Esta fase es clave para que el proyecto se cierre bien y no quede una lista larga de “pendientes”.

3. Roles y responsabilidades: quién decide qué

En la práctica: muchos retrasos no son técnicos, son de decisión. Por eso conviene definir roles desde el principio.

La migración debe tener un comité breve y operativo. No hace falta una reunión larga cada día, pero sí un canal claro para decisiones: aprobar ventanas, resolver excepciones, priorizar incidencias y decidir si se avanza o se pospone un corte.

4. Assessment: inventario técnico y funcional

En la práctica: el assessment evita sorpresas. Cada dato que no se revise antes puede convertirse en incidencia después.

4.1 Inventario de correo

• Buzones de usuario activos e inactivos.
• Buzones compartidos.
• Buzones de recursos: salas, equipos, calendarios compartidos.
• Alias y direcciones secundarias.
• Listas de distribución y grupos.
• Reglas de transporte.
• Conectores SMTP.
• Reenvíos automáticos.
• Permisos delegados: Full Access, Send As, Send on Behalf.
• Tamaño de buzones y número de elementos.
• Calendarios críticos y calendarios compartidos.
• Clientes usados: Outlook, webmail, móvil, apps de terceros.

4.2 Inventario de archivos

• Repositorios de origen: file server, NAS, Google Drive, Dropbox, Zoho WorkDrive, Box u otros.
• Volumen total y crecimiento estimado.
• Número de archivos y carpetas.
• Rutas largas.
• Nombres no compatibles o problemáticos.
• Duplicados.
• Permisos heredados.
• Carpetas sin propietario claro.
• Datos obsoletos o históricos.
• Información sensible: datos personales, nóminas, contratos, datos financieros.
• Enlaces externos.
• Necesidad de retención o archivo.

4.3 Inventario de identidad

• Usuarios actuales.
• Usuarios externos o invitados.
• Grupos de seguridad.
• Grupos de distribución.
• Roles administrativos.
• UPN actual y UPN deseado.
• Dominios verificados.
• Aplicaciones con SSO.
• Cuentas de servicio.
• Active Directory local, si existe.
• Necesidad de sincronización con Entra ID.

4.4 Inventario de dispositivos

• Portátiles corporativos.
• Equipos compartidos.
• Móviles corporativos.
• BYOD.
• Versiones de Windows, macOS, iOS y Android.
• Antivirus actual.
• Cifrado de disco.
• Necesidad de VPN.
• Aplicaciones instaladas.
• Perfiles de correo en móviles.

4.5 Inventario de aplicaciones y automatizaciones

• Aplicaciones que envían correo mediante SMTP.
• ERP, CRM, software de facturación o ticketing.
• Flujos de Power Automate.
• Power Apps.
• Informes de Power BI.
• Gateways de datos.
• Conectores con SharePoint, Exchange, SQL o servicios externos.
• Scripts internos.
• Aplicaciones registradas en Entra ID.

5. Licencias Microsoft 365: cómo elegir sin pagar de más

En la práctica: el licenciamiento bien diseñado puede ahorrar costes y evitar limitaciones. El error típico es dar la misma licencia a todo el mundo sin mirar perfiles.

La licencia no debe elegirse solo por precio. Debe responder a una pregunta sencilla: ¿qué necesita hacer este usuario y qué nivel de seguridad requiere? Un usuario administrativo, un comercial, un técnico de campo y un directivo no tienen las mismas necesidades.

Errores frecuentes al elegir licencias

• Comprar el plan más barato y descubrir después que falta gestión de dispositivos o seguridad.
• Comprar el plan más alto para todos sin analizar perfiles.
• No reservar licencias para buzones compartidos que realmente necesitan licencia por funciones avanzadas.
• No prever crecimiento de almacenamiento.
• No considerar Defender, Intune o Purview desde el diseño.
• No revisar complementos necesarios para telefonía, audioconferencia, compliance o seguridad.

Servicio relacionado: Suministro y venta de licencias para empresas.

6. Preparación del tenant Microsoft 365

En la práctica: el tenant debe estar listo antes de migrar. Si se configura sobre la marcha, aparecen errores de permisos, licencias, DNS y seguridad.

Elementos a preparar

• Tenant creado y administradores definidos.
• Dominio corporativo verificado.
• Usuarios creados o sincronizados.
• Licencias asignadas.
• Exchange Online preparado.
• OneDrive aprovisionado para usuarios.
• Sitios de SharePoint base creados.
• Teams configurado con políticas mínimas.
• MFA y Acceso Condicional definidos.
• Política de compartición externa revisada.
• Roles administrativos asignados con privilegio mínimo.
• Cuentas de emergencia documentadas.
• Auditoría habilitada.

Buenas prácticas para administradores

• No usar cuentas personales de trabajo diario para administración global.
• Asignar roles específicos en lugar de Global Admin a todo el equipo.
• Proteger administradores con MFA fuerte.
• Registrar cambios relevantes durante la migración.
• Documentar configuraciones iniciales.

7. Identidad con Microsoft Entra ID

En la práctica: la identidad es el cimiento de Microsoft 365. Si el usuario no puede entrar bien, nada más importa.

Microsoft Entra ID gestiona inicio de sesión, usuarios, grupos, roles, aplicaciones, MFA y Acceso Condicional. En una migración, define quién es cada usuario, cómo entra, qué permisos tiene y desde dónde puede acceder.

Modelo cloud-only

En un modelo cloud-only, los usuarios se gestionan directamente en Microsoft 365 / Entra ID. Es más sencillo y suele encajar en empresas sin Active Directory local o que quieren reducir dependencia de servidores internos.

Modelo híbrido con Active Directory

Si existe Active Directory local y sigue siendo importante para aplicaciones, equipos o autenticación interna, puede ser necesario sincronizar identidades con Entra ID. Esto requiere revisar UPN, atributos, OU, grupos, contraseñas y ciclo de vida de usuarios.

Checklist de identidad

• Definir UPN final.
• Revisar dominios y alias.
• Eliminar duplicados.
• Crear grupos por rol y departamento.
• Definir administradores y roles.
• Aplicar MFA.
• Crear políticas de Acceso Condicional.
• Revisar aplicaciones empresariales.
• Documentar cuentas de servicio.
• Definir ciclo de altas, bajas y cambios.

8. Migrar correo a Exchange Online

En la práctica: el correo es la parte más sensible porque afecta a todos. El objetivo es que el usuario abra Outlook y pueda seguir trabajando.

Exchange Online es el servicio de correo empresarial de Microsoft 365. Permite buzones en la nube, calendarios, reglas, buzones compartidos, listas, protección de correo y administración centralizada. La forma de migrar depende del origen.

8.1 Migración IMAP

La migración IMAP se usa cuando el origen es un sistema de correo compatible con IMAP: hosting tradicional, algunos servidores antiguos, Zoho Mail u otros proveedores. Es útil para mover mensajes y carpetas, pero no migra calendarios, contactos, tareas, reglas ni firmas.

• Ventaja: sencilla y compatible con muchos orígenes.
• Limitación: solo correo y carpetas.
• Cuándo usarla: cuando el origen no es Exchange o Google y el objetivo es migrar correo básico.

8.2 Migración cutover

Una migración cutover mueve todos los buzones en una ventana única o muy concentrada. Puede funcionar en entornos pequeños y controlados, pero requiere una preparación impecable.

8.3 Migración staged

Una migración staged permite mover usuarios por fases. Reduce presión, pero exige coexistencia y buena comunicación. Es útil cuando no conviene cambiar a toda la empresa a la vez.

8.4 Migración híbrida

La migración híbrida encaja cuando Exchange local seguirá conviviendo con Exchange Online durante un tiempo. Aporta coexistencia avanzada, pero también más complejidad: certificados, conectores, Autodiscover, directorio y flujo de correo.

8.5 Herramientas de terceros

Herramientas como BitTitan, Quest, Cloudiway u otras pueden ayudar cuando hay varios orígenes, necesidad de reporting, plazos ajustados o escenarios complejos.

Checklist de correo

• Inventario de buzones.
• Tamaño de buzones y archivo online.
• Revisión de buzones compartidos.
• Permisos delegados.
• Alias y dominios.
• Reglas de transporte.
• Conectores SMTP.
• Aplicaciones que envían correo.
• Usuarios críticos.
• Método de migración elegido.
• Prueba piloto.
• Sincronización previa.
• Plan de corte DNS.
• Pruebas de envío y recepción.
• Reconfiguración de Outlook y móviles.

Connect-ExchangeOnline

Get-MigrationBatch |
  Select-Object Name,Status,TotalCount,ActiveCount,StoppedCount,FailedCount

Get-MigrationUser |
  Get-MigrationUserStatistics -IncludeReport |
  Select-Object Identity,Status,PercentComplete,ItemsTransferred,BytesTransferred,ErrorSummary |
  Export-Csv ".\estado-migracion-exchange.csv" -NoTypeInformation -Encoding UTF8

Connect-ExchangeOnline

Get-EXOMailbox -ResultSize Unlimited |
  Get-EXOMailboxStatistics |
  Select-Object DisplayName,TotalItemSize,ItemCount,LastLogonTime |
  Export-Csv ".\buzones-tamano.csv" -NoTypeInformation -Encoding UTF8

9. Calendarios, contactos, reglas y firmas

En la práctica: estos elementos parecen secundarios hasta que faltan. Para el usuario, su calendario y sus contactos son parte esencial del correo.

Calendarios

Los calendarios deben revisarse con especial cuidado si hay reuniones recurrentes, salas, calendarios compartidos, delegaciones o usuarios que organizan muchas reuniones externas. Según el origen y el método de migración, puede ser necesario exportar/importar calendarios o recrear determinadas reuniones.

Contactos

Los contactos personales, contactos compartidos y listas corporativas no son lo mismo. Antes de migrar conviene decidir qué contactos van al buzón del usuario, cuáles deben ser contactos de organización y cuáles pertenecen a un CRM.

Reglas

Las reglas de correo pueden ser útiles, pero también peligrosas. Durante una migración aparecen reglas antiguas que reenvían correo, mueven mensajes o dependen de carpetas que cambian. Conviene revisarlas y limpiar las que ya no tengan sentido.

Firmas

Las firmas no siempre se migran automáticamente. Si la empresa quiere una firma corporativa común, la migración es un buen momento para estandarizarla.

Checklist específico

• Identificar calendarios compartidos.
• Revisar delegaciones de calendario.
• Validar salas y recursos.
• Exportar/importar contactos si el método no los migra.
• Revisar reglas de reenvío.
• Documentar firmas corporativas.
• Probar usuarios con alta actividad de calendario.

10. Migrar archivos a OneDrive y SharePoint

En la práctica: migrar archivos no es subir carpetas. Es decidir dónde debe vivir la información y quién debe acceder a ella.

OneDrive y SharePoint no son lo mismo. Uno de los errores más frecuentes es meter todo en OneDrive porque parece más rápido, o copiar un file server completo a un único sitio de SharePoint. Eso suele generar confusión, permisos mal planteados y poca adopción.

Destino correcto

• OneDrive: archivos personales de trabajo, borradores, documentos que todavía no pertenecen a un equipo.
• SharePoint: documentación de áreas, departamentos, procesos, clientes, proyectos o conocimiento corporativo.
• Teams: colaboración diaria asociada a un grupo de trabajo. Los archivos de Teams se almacenan en SharePoint.

Qué revisar antes de migrar

• Volumen total.
• Número de archivos.
• Tipos de archivo.
• Rutas largas.
• Nombres no compatibles.
• Permisos heredados.
• Carpetas sin propietario.
• Contenido duplicado.
• Contenido obsoleto.
• Datos sensibles.
• Enlaces externos.
• Necesidad de metadatos.

Herramientas habituales

• Migration Manager: útil para migrar file shares y otros orígenes hacia Microsoft 365.
• SharePoint Migration Tool: herramienta de Microsoft para migrar contenido de SharePoint Server y file shares hacia Microsoft 365.
• Herramientas de terceros: útiles para permisos complejos, reporting, reorganización o múltiples orígenes.

11. Diseño de SharePoint: estructura, permisos y gobierno

En la práctica: SharePoint funciona muy bien cuando está diseñado; funciona mal cuando se usa como un cajón gigante de carpetas.

Principios de diseño

• Crear sitios por área, proceso o proyecto estable.
• Evitar una única biblioteca para toda la empresa.
• Usar grupos en lugar de permisos usuario a usuario.
• Definir propietarios de sitio.
• Separar documentación activa de documentación histórica.
• Evitar herencias de permisos demasiado profundas.
• Usar metadatos cuando aporten valor, no por moda.
• Definir normas de compartición externa.

Modelo básico de sitios

Gobierno mínimo recomendable

• Política de creación de sitios.
• Nomenclatura de sitios y Teams.
• Propietarios obligatorios.
• Revisión periódica de permisos.
• Normas de compartición externa.
• Retención por tipo de información.
• Plantillas de bibliotecas y metadatos.

12. Microsoft Teams: despliegue, migración y adopción

En la práctica: Teams puede ordenar la colaboración o multiplicar el caos. Depende del gobierno.

Teams no es solo una herramienta de chat. Cada equipo puede tener miembros, propietarios, canales, archivos, pestañas, aplicaciones, reuniones, grabaciones y conexiones con SharePoint. Por eso, antes de desplegarlo o migrarlo conviene definir una estrategia.

Qué decidir antes de usar Teams

• Quién puede crear equipos.
• Cómo se nombran los equipos.
• Cuándo se usa chat y cuándo canal.
• Qué canales se crean por defecto.
• Cómo se gestionan invitados.
• Cuándo se archiva un equipo.
• Qué apps se permiten.
• Cómo se integran Planner, OneNote, SharePoint o Power BI.

Tipos de equipos recomendados

Errores habituales en Teams

• Crear demasiados equipos sin propósito claro.
• No asignar propietarios.
• Usar chats para decisiones que deberían estar en canales.
• Subir archivos al chat en vez de usar bibliotecas de equipo.
• No gestionar invitados.
• No formar a usuarios en la diferencia entre Teams, SharePoint y OneDrive.

13. Power Platform, Power BI y aplicaciones conectadas

En la práctica: una migración puede dejar de funcionar aunque el correo esté perfecto si se rompen flujos, conectores o informes.

Muchas empresas tienen pequeñas automatizaciones que nadie considera “críticas” hasta que fallan: aprobaciones, avisos por correo, formularios, informes, integraciones con SharePoint o exportaciones a Excel. Durante una migración, estas piezas deben revisarse.

Qué inventariar

• Flujos de Power Automate.
• Power Apps.
• Listas de SharePoint usadas por apps.
• Conectores con Outlook, SharePoint, SQL, ERP o CRM.
• Cuentas propietarias de flujos.
• Gateways de datos.
• Workspaces de Power BI.
• Datasets y credenciales.
• Aplicaciones registradas en Entra ID.

Buenas prácticas

• Evitar que un flujo crítico dependa de una cuenta personal.
• Asignar co-propietarios.
• Documentar conectores y permisos.
• Probar flujos con usuarios de negocio.
• Revisar credenciales después de la migración.
• Separar desarrollo, pruebas y producción cuando aplique.

14. Dispositivos, Intune y experiencia de primer día

En la práctica: para el usuario, la migración se resume en si su portátil y su móvil funcionan.

Microsoft Intune permite gestionar dispositivos, aplicaciones, políticas de cumplimiento y acceso a datos corporativos. En una migración a Microsoft 365, Intune es especialmente importante si hay trabajo remoto, móviles, BYOD o necesidad de controlar acceso por dispositivo.

Escenarios de dispositivos

• Equipos corporativos Windows: pueden gestionarse con Intune y, si aplica, Autopilot.
• Equipos personales: se puede aplicar gestión de aplicaciones sin controlar todo el dispositivo.
• Móviles corporativos: gestión completa del dispositivo.
• BYOD: protección de datos corporativos en aplicaciones como Outlook y Teams.
• Equipos compartidos: requieren perfiles y políticas específicas.

Checklist de Intune

• Inventario de dispositivos.
• Políticas de cumplimiento.
• Perfiles de configuración.
• Aplicaciones requeridas.
• Políticas de protección de aplicaciones.
• Requisitos de cifrado.
• Windows Autopilot si aplica.
• Guía de inscripción para usuarios.
• Pruebas con usuarios piloto.

15. DNS: MX, SPF, DKIM, DMARC y Autodiscover

En la práctica: el cambio de DNS es el momento en el que el mundo empieza a enviar correo a Microsoft 365. Hay que llegar con todo preparado.

Para conectar un dominio a Microsoft 365 hay que verificar la propiedad y añadir los registros necesarios. Microsoft recomienda crear usuarios y buzones antes de actualizar el registro MX para evitar interrupciones en la entrega de correo.

# MX hacia Exchange Online Protection
MX @ 0 empresa-com.mail.protection.outlook.com

# SPF
TXT @ "v=spf1 include:spf.protection.outlook.com -all"

# DKIM (los valores concretos los genera Microsoft 365)
CNAME selector1._domainkey selector1-empresa-com._domainkey.empresa.onmicrosoft.com
CNAME selector2._domainkey selector2-empresa-com._domainkey.empresa.onmicrosoft.com

# DMARC inicial en modo observación
TXT _dmarc "v=DMARC1; p=none; rua=mailto:dmarc@empresa.com"

# Autodiscover
CNAME autodiscover autodiscover.outlook.com

Errores frecuentes con DNS

• Cambiar MX antes de tener buzones preparados.
• No incluir todos los remitentes legítimos en SPF.
• Activar DMARC estricto sin revisar informes.
• No configurar DKIM.
• Olvidar Autodiscover.
• No documentar los registros anteriores.

16. Seguridad y cumplimiento en Microsoft 365

En la práctica: una migración es el mejor momento para subir el nivel de seguridad. Después cuesta más cambiar hábitos y cerrar excepciones.

Controles mínimos recomendados

• MFA para todos los usuarios.
• MFA fuerte para administradores.
• Acceso Condicional para controlar acceso por ubicación, dispositivo, riesgo y aplicación.
• Bloqueo de autenticación heredada cuando no sea necesaria.
• Defender for Office 365 para Safe Links, Safe Attachments y antiphishing.
• SPF, DKIM y DMARC para autenticación de correo.
• Políticas de compartición externa en SharePoint y OneDrive.
• Auditoría y revisión de roles administrativos.
• Políticas de retención para información crítica.
• DLP para evitar fugas de información sensible.

Acceso Condicional: políticas base

• MFA para todos los usuarios.
• Bloqueo de autenticación heredada.
• MFA obligatoria para administradores.
• Bloqueo o control de países no esperados.
• Requerir dispositivo conforme para datos sensibles.
• Control de sesión para aplicaciones críticas.

Defender for Office 365

Defender for Office 365 añade protección frente a amenazas de correo y colaboración. Safe Links ayuda a proteger frente a enlaces maliciosos y Safe Attachments analiza adjuntos en un entorno seguro antes de entregarlos según la política configurada.

17. Gobierno de datos: retención, DLP, etiquetas y eDiscovery

En la práctica: migrar datos sin gobierno solo traslada el riesgo a otra plataforma.

Retención

Las políticas de retención permiten conservar o eliminar información según criterios de negocio, legales o regulatorios. Conviene definirlas antes de que SharePoint y Exchange empiecen a crecer sin control.

DLP

Las políticas de prevención de pérdida de datos ayudan a detectar y controlar información sensible, como datos personales, financieros o confidenciales, en correo, SharePoint, OneDrive y Teams.

Etiquetas de sensibilidad

Las etiquetas permiten clasificar documentos y correos como público, interno, confidencial o restringido. Pueden aplicar cifrado, marcas visuales o restricciones de acceso.

eDiscovery

eDiscovery permite buscar, preservar y exportar información en escenarios legales o de auditoría. Si la empresa tiene requisitos regulatorios, debe incluirse en el diseño.

18. Comunicación y adopción de usuarios

En la práctica: la adopción no se improvisa el día del corte. Si el usuario no entiende el cambio, lo vivirá como un problema.

Qué comunicar

• Por qué se migra.
• Qué cambia y qué no cambia.
• Cuándo se hará el cambio.
• Cómo acceder a Microsoft 365.
• Cómo usar Outlook.
• Cómo configurar el móvil.
• Dónde estarán los archivos.
• Cómo usar Teams.
• Cómo aprobar MFA.
• Dónde pedir soporte.

Guías recomendadas

• Primer acceso a Microsoft 365.
• Guía rápida de Outlook.
• Guía rápida de Teams.
• Cómo encontrar archivos en OneDrive y SharePoint.
• Cómo compartir documentos de forma segura.
• Cómo configurar Outlook en el móvil.
• Qué hacer si MFA no funciona.

19. Costes de migración a Microsoft 365

En la práctica: el coste depende menos del número de usuarios de lo que parece y más de la complejidad del entorno.

Factores que impactan el coste

• Número de usuarios.
• Tamaño de buzones.
• Número de buzones compartidos.
• Origen del correo.
• Volumen de archivos.
• Complejidad de permisos.
• Número de sitios y Teams.
• Necesidad de herramientas de terceros.
• Seguridad y cumplimiento requeridos.
• Dispositivos a gestionar.
• Power Platform e integraciones.
• Soporte y formación.
• Ventanas de trabajo fuera de horario.

Cómo evitar sobrecostes

• Hacer assessment antes de contratar herramientas.
• Limpiar datos antes de migrar.
• No migrar contenido obsoleto.
• Agrupar usuarios por oleadas inteligentes.
• Elegir licencias por perfil.
• Automatizar inventario y validaciones.
• Evitar cambios de alcance a mitad del corte.

20. KPIs de proyecto, calidad y adopción

En la práctica: una migración sin métricas se gestiona por sensaciones. Y las sensaciones suelen llegar tarde.

21. Riesgos frecuentes y cómo mitigarlos

22. Checklists operativos

22.1 Checklist previo

• Dominio verificado en Microsoft 365.
• Usuarios creados o sincronizados.
• Licencias asignadas.
• Usuarios piloto seleccionados.
• MFA preparado.
• Acceso Condicional diseñado.
• Inventario de buzones.
• Inventario de archivos.
• Inventario de aplicaciones.
• Plan DNS preparado.
• Plan de comunicación preparado.
• Plan de reversa escrito.

22.2 Checklist de correo

• Método de migración elegido.
• Endpoint de migración validado.
• Buzones destino creados.
• Prueba piloto completada.
• Lotes definidos.
• Errores revisados.
• Calendarios validados.
• Buzones compartidos revisados.
• Outlook y móvil probados.

22.3 Checklist de archivos

• Origen identificado.
• Destino definido: OneDrive, SharePoint o Teams.
• Permisos revisados.
• Contenido obsoleto separado.
• Rutas largas revisadas.
• Usuarios propietarios definidos.
• Migración piloto ejecutada.
• Validación de acceso completada.

22.4 Checklist del día del corte

• Equipo de soporte disponible.
• Comunicación enviada.
• Última sincronización revisada.
• DNS preparado.
• Plan de reversa disponible.
• Usuarios críticos informados.
• Pruebas de envío y recepción listas.
• Registro de incidencias abierto.

22.5 Checklist post-migración

• Correo validado.
• Outlook validado.
• Móviles validados.
• Archivos críticos validados.
• Teams validado.
• Permisos revisados.
• Seguridad revisada.
• Incidencias recurrentes analizadas.
• Documentación actualizada.
• Origen retirado o pasado a solo lectura cuando sea seguro.

23. Snippets y scripts útiles

En la práctica: los scripts ayudan a inventariar, validar y controlar, pero deben probarse antes en piloto.

Connect-ExchangeOnline

Get-EXOMailbox -ResultSize Unlimited |
  Select-Object DisplayName,UserPrincipalName,PrimarySmtpAddress,RecipientTypeDetails |
  Export-Csv ".\inventario-buzones.csv" -NoTypeInformation -Encoding UTF8

Get-MigrationBatch |
  Select-Object Name,Status,TotalCount,FailedCount

Get-MigrationUser |
  Get-MigrationUserStatistics -IncludeReport |
  Select-Object Identity,Status,PercentComplete,ItemsTransferred,ErrorSummary |
  Export-Csv ".\estado-migracion.csv" -NoTypeInformation -Encoding UTF8

Get-CASMailbox -ResultSize Unlimited |
  Set-CASMailbox -ImapEnabled:$false -PopEnabled:$false

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 ".\usuarios.csv" -NoTypeInformation -Encoding UTF8

Connect-SPOService -Url "https://tenant-admin.sharepoint.com"

Get-SPOSite -Limit All |
  Select-Object Url,Owner,Template,StorageUsageCurrent,LastContentModifiedDate |
  Export-Csv ".\sitios-sharepoint.csv" -NoTypeInformation -Encoding UTF8

Connect-MicrosoftTeams

Get-Team |
  Select-Object GroupId,DisplayName,Visibility,Archived |
  Export-Csv ".\inventario-teams.csv" -NoTypeInformation -Encoding UTF8

EmailAddress
ana.perez@empresa.com
juan.garcia@empresa.com
soporte@empresa.com

24. Plantillas de comunicación y go/no-go

Comunicación previa: anuncio del proyecto

Asunto: Próxima migración a Microsoft 365

Hola,

Vamos a migrar nuestras herramientas de correo, archivos y colaboración a Microsoft 365. El objetivo es trabajar con más seguridad, mejorar la colaboración y ordenar el acceso a la información.

No tienes que hacer nada todavía. Te iremos avisando con instrucciones sencillas antes del cambio.

Gracias,
Equipo de IT

Comunicación de instrucciones

Asunto: Instrucciones para el cambio a Microsoft 365

Hola,

Durante la ventana de migración se moverá tu correo a Microsoft 365. Cuando te avisemos, deberás abrir Outlook, iniciar sesión con tu cuenta corporativa y aprobar MFA si se solicita.

También tendrás acceso a Teams, OneDrive y SharePoint. Si necesitas ayuda, tendrás soporte disponible en los canales habituales.

Gracias,
Equipo de IT

Comunicación del día del corte

Asunto: Estamos realizando el cambio a Microsoft 365

Hola,

Estamos realizando el cambio de correo y servicios a Microsoft 365. Puede haber pequeños cortes o solicitudes de inicio de sesión durante la transición.

Si necesitas ayuda, contacta con soporte. Avisaremos cuando la validación haya finalizado.

Gracias por tu paciencia,
Equipo de IT

Go/No-Go: puntos de revisión

• Usuarios destino creados y licenciados.
• Última sincronización revisada.
• Errores críticos resueltos.
• DNS preparado.
• Soporte disponible.
• Comunicación enviada.
• Plan de reversa preparado.
• Negocio informado.

25. Plan de reversa y contingencia

En la práctica: el rollback no debe improvisarse cuando algo falla. Debe existir antes del corte.

Cuándo activar contingencia

• El correo no entra o no sale.
• Los usuarios críticos no pueden acceder.
• La tasa de errores supera el umbral acordado.
• DNS no se comporta como se esperaba.
• La herramienta de migración devuelve errores generalizados.
• No hay tiempo suficiente para validar antes del horario de negocio.

Qué debe incluir el plan

• Responsable de decisión.
• Pasos para pausar lotes.
• Registros DNS anteriores documentados.
• Procedimiento para volver temporalmente al origen si aplica.
• Mensaje de comunicación a usuarios.
• Validaciones tras reversa.
• Análisis de causa raíz antes de reintentar.

26. Qué hacer después de migrar

En la práctica: el proyecto no termina el día del corte. La semana posterior suele decidir cómo percibe el usuario la migración.

Acciones post-migración

• Revisar incidencias repetidas.
• Validar buzones compartidos y calendarios.
• Revisar permisos de SharePoint.
• Recertificar accesos externos.
• Comprobar políticas de seguridad.
• Revisar adopción de Teams.
• Eliminar reglas temporales.
• Deshabilitar protocolos heredados si ya no son necesarios.
• Actualizar documentación.
• Retirar o archivar el sistema antiguo de forma controlada.

Mejoras recomendadas tras estabilizar

• Implantar etiquetas de sensibilidad.
• Activar DLP por fases.
• Revisar Secure Score.
• Implantar Intune si no estaba incluido.
• Optimizar Teams y SharePoint.
• Formar a champions internos.
• Revisar licencias tras uso real.

27. Preguntas frecuentes sobre migración a Microsoft 365

28. Recursos oficiales y enlaces externos

Documentación oficial de Microsoft

• Formas de migrar correo a Microsoft 365
• Buenas prácticas y rendimiento en migraciones de Exchange Online
• Migración IMAP a Microsoft 365
• Migration Manager para migrar file shares a Microsoft 365
• SharePoint Migration Tool
• Conectar un dominio a Microsoft 365 con registros DNS
• Registros DNS externos para Microsoft 365
• Autenticación de correo: SPF, DKIM y DMARC
• Acceso Condicional en Microsoft Entra
• Safe Links en Defender for Office 365
• Safe Attachments en Defender for Office 365
• Qué es Microsoft Intune
• Microsoft Purview Information Protection

Servicios relacionados de MSAdvance

• Migración a Microsoft 365
• Modern Workplace Microsoft 365
• Seguridad y cumplimiento Microsoft 365
• Suministro y venta de licencias
• Arquitectura Azure
• Todos los servicios

29. Conclusión y siguientes pasos

Una migración a Microsoft 365 bien ejecutada puede mejorar mucho la forma de trabajar de una empresa: correo más sólido, archivos ordenados, Teams como centro de colaboración, identidades protegidas, dispositivos gestionados y datos con más gobierno.

Pero para conseguirlo hace falta método. No basta con comprar licencias y cambiar el MX. Hay que entender el entorno, decidir qué se migra, diseñar el destino, probar con usuarios reales, ejecutar por fases, validar resultados y acompañar al usuario.

La diferencia entre una migración tranquila y una migración problemática suele estar en lo que se hace antes del corte: assessment, comunicación, seguridad, piloto y checklists. Si esas piezas están bien, el cambio se vive como una mejora. Si no, se vive como una interrupción.