Servicios de migración a Microsoft 365: Google Workspace, Exchange, IMAP, Domino y Tenant-to-Tenant
No todas las migraciones a Microsoft 365 son iguales. Pasar 30 buzones IMAP a Exchange Online tiene poco que ver con sustituir una infraestructura Exchange Server, abandonar Google Workspace, modernizar un entorno HCL Domino o consolidar dos tenants completos de Microsoft 365 después de una adquisición.
El destino puede parecer el mismo, pero cambian los datos disponibles, las herramientas, la forma de mantener calendarios y contactos, las posibilidades de premigración, el tratamiento de los usuarios, la gestión de dominios y la experiencia que tendrá cada persona después del cambio.
Por eso en Kloudeal no planteamos una migración empezando por la herramienta. Primero analizamos el origen, identificamos qué información existe realmente y definimos qué debe terminar en Exchange Online, OneDrive, SharePoint, Microsoft Teams o Microsoft Entra ID.
A partir de ahí podemos preparar el tenant, seleccionar la tecnología de migración, ejecutar un piloto, realizar las cargas previas que permita el método elegido, coordinar el cutover y validar que los servicios incluidos funcionan correctamente en el nuevo entorno.
El objetivo es que la migración tenga un alcance claro, expectativas realistas y un procedimiento verificable, especialmente cuando intervienen correo crítico, dominios corporativos, buzones compartidos, archivos, calendarios, aplicaciones o varios cientos de usuarios.
¿Desde qué plataforma necesitas migrar?
| Origen | Qué suele trasladarse | Principal punto de atención |
|---|---|---|
| Google Workspace | Gmail, calendario, contactos, Google Drive y Shared Drives. | Separar correctamente correo y contenido documental y mapear identidades. |
| Exchange Server | Buzones, calendarios, contactos, shared mailboxes, salas y permisos. | Versión, coexistencia, identidad, aplicaciones y estrategia híbrida. |
| HCL Domino / Notes | Correo, calendarios, contactos y datos que puedan trasladarse. | Distinguir correo de aplicaciones y bases de datos Domino. |
| IMAP | Correo y estructura de carpetas. | Contactos, calendarios y tareas no forman parte de IMAP. |
| POP3 | Depende de dónde se encuentre realmente el correo histórico. | Gran parte de la información puede estar descargada en equipos o PST. |
| Microsoft 365 | Exchange, OneDrive, SharePoint, Teams y otros componentes según alcance. | Identidad, dominios, mappings y dependencias entre workloads. |
| File server / NAS | Documentos y carpetas. | Decidir qué debe ir a SharePoint y qué pertenece a OneDrive. |
¿Quieres saber qué implicaría vuestra migración?
Con el origen actual, número aproximado de usuarios, volumen, dominios y fecha objetivo podemos hacer una primera revisión y determinar qué información necesitamos para preparar el alcance.
Solicitar valoración de migración Microsoft 365Índice
- En qué consiste un servicio de migración a Microsoft 365
- Cuándo tiene sentido migrar
- Qué puede incluir el proyecto
- Migración desde Google Workspace
- Google Drive y Shared Drives
- Migración desde Exchange Server
- Cutover, híbrido y otros métodos Exchange
- Migración desde HCL Domino / Notes
- Migración desde IMAP
- Migración desde POP3
- Zimbra, cPanel, Dovecot y otros servidores
- Migración Tenant-to-Tenant de Microsoft 365
- File servers, NAS y repositorios documentales
- OneDrive o SharePoint
- Usuarios, dominios e identidad
- MX, SPF, DKIM, DMARC y DNS
- Aplicaciones e integraciones
- Seguridad durante la migración
- Herramientas que utilizamos
- Cómo desarrollamos el proyecto
- Piloto y premigración
- Ventana de cambio
- Validación y soporte posterior
- Qué ocurre con Outlook y los dispositivos de usuario
- Qué necesitamos para preparar una propuesta
- Errores frecuentes
- Checklist previa
- Preguntas frecuentes
- Documentación oficial
En qué consiste un servicio de migración a Microsoft 365
Una migración profesional debería resolver algo más que la transferencia de datos. Para que el cambio funcione hay que coordinar origen, destino, identidad, licencias, herramientas, dominios, seguridad y validación.
El trabajo empieza entendiendo qué tiene actualmente la empresa.
Por ejemplo, dos organizaciones pueden indicar que tienen “100 cuentas de correo” y necesitar proyectos completamente distintos. Una puede utilizar un hosting IMAP con buzones pequeños y sin calendarios compartidos. La otra puede tener Exchange Server con buzones de 80 GB, Archives, salas, delegaciones, aplicaciones SMTP y sincronización con Active Directory.
Una valoración fiable tiene que distinguir esos escenarios.
| Fase | Resultado esperado |
|---|---|
| Discovery | Conocer usuarios, datos, dominios, aplicaciones y excepciones. |
| Diseño | Determinar dónde irá cada servicio y cómo se realizará la transición. |
| Preparación | Configurar tenant, usuarios, licencias, seguridad y herramientas. |
| Piloto | Comprobar con casos reales que el método funciona como esperamos. |
| Premigración | Mover previamente información cuando la tecnología lo permite. |
| Cutover | Ejecutar los cambios finales de correo, identidad o dominio. |
| Validación | Comprobar técnicamente los servicios incluidos. |
| Hypercare | Resolver incidencias relacionadas con la transición. |
Cuándo tiene sentido migrar a Microsoft 365
El cambio suele responder a una necesidad empresarial concreta.
Puede tratarse de dejar de administrar un Exchange Server, sustituir un hosting de correo antiguo, integrar una empresa recién adquirida, abandonar Google Workspace, modernizar HCL Domino o trasladar documentación desde servidores locales hacia SharePoint y OneDrive.
También puede haber un objetivo más amplio: centralizar identidad y colaboración dentro del ecosistema Microsoft.
La migración tiene más sentido cuando existe una definición clara del estado futuro. Si simplemente se traslada todo aquello que existe sin cuestionar su utilidad, es fácil terminar pagando por mover información obsoleta, cuentas antiguas y estructuras que nadie necesita.
Qué puede incluir una migración a Microsoft 365
El alcance se construye según el origen. No todos los componentes están disponibles en todas las plataformas y no todos pueden conservarse con la misma fidelidad.
| Componente | Qué puede incluir el proyecto |
|---|---|
| Exchange Online | Correo, calendario, contactos, Archives, shared mailboxes, salas y recursos según origen. |
| Dominios | Validación, configuración y coordinación de DNS. |
| Microsoft Entra ID | Preparación de usuarios, grupos e identidad según arquitectura. |
| OneDrive | Datos personales de trabajo y contenido del usuario. |
| SharePoint Online | Documentación compartida, sitios y bibliotecas. |
| Microsoft Teams | Preparación o migración de componentes según origen y tecnología. |
| Seguridad | MFA y controles iniciales acordes al licenciamiento y alcance. |
| Aplicaciones | Inventario y reconfiguración de las integraciones incluidas expresamente. |
| DNS y mail flow | MX, Autodiscover, SPF, DKIM, DMARC y conectores relacionados. |
El proyecto debe indicar expresamente qué elementos se incluyen y cuáles no. Es especialmente importante en servicios como Teams, Domino o Power Platform, donde la palabra “migrar” puede tener significados muy diferentes.
Migración desde Google Workspace a Microsoft 365
Google Workspace es uno de los orígenes para los que Microsoft dispone actualmente de rutas específicas de migración.
La estrategia debe separar al menos dos grupos de información:
correo, calendario y contactos, por un lado, y Google Drive / Shared Drives, por otro.
No son el mismo workload y no necesariamente utilizan la misma herramienta o proceso.
Gmail, calendario y contactos
Microsoft documenta una ruta específica de migración desde Google Workspace hacia Exchange Online.
El procedimiento permite trabajar por lotes y trasladar información de Google hacia los buzones preparados en Microsoft 365.
| Google Workspace | Destino habitual |
|---|---|
| Gmail | Exchange Online |
| Google Calendar | Calendario de Exchange Online |
| Google Contacts | Contactos del buzón |
| My Drive | OneDrive, normalmente |
| Shared Drives | SharePoint, normalmente |
| Identidades | Microsoft Entra ID |
Antes de ejecutar la migración revisamos usuarios, dominios, permisos administrativos, APIs, mapping de cuentas y el calendario de cambio de MX.
Referencia oficial: Microsoft – Perform a Google Workspace migration to Microsoft 365.
Una migración desde Google también es un cambio de forma de trabajar
El usuario que deja Gmail para utilizar Outlook y Exchange Online no solo cambia de servidor.
También puede cambiar:
| Antes | Después |
|---|---|
| Gmail | Outlook / Exchange Online |
| Google Calendar | Outlook Calendar |
| Google Meet | Microsoft Teams si forma parte de la estrategia |
| Google Drive | OneDrive / SharePoint |
| Google Docs | Microsoft 365 Apps y formatos compatibles según contenido |
Por eso es importante que la comunicación a usuarios se diseñe alrededor de los cambios que realmente van a experimentar.
Migración de Google Drive y Shared Drives
Microsoft utiliza actualmente Migration Manager para migrar archivos desde Google Workspace hacia Microsoft 365.
El flujo de trabajo incluye conexión con Google, escaneo, revisión del destino, mapping de identidades y ejecución de la migración.
Microsoft distingue además entre unidades personales y compartidas, algo importante a la hora de elegir correctamente OneDrive o SharePoint como destino.
My Drive no equivale siempre a OneDrive
Aunque conceptualmente ambos servicios son almacenamiento ligado al usuario, dentro de My Drive puede existir contenido que en realidad sea propiedad de un departamento o proceso.
Durante el assessment conviene detectar estos casos para evitar que documentación corporativa termine dependiendo de la cuenta personal de una única persona.
Shared Drives
En general tienen una correspondencia más lógica con sitios o bibliotecas SharePoint porque su información pertenece a un equipo u organización y no a un usuario concreto.
| Antes de migrar Google Drive | Qué revisamos |
|---|---|
| Identidades | Usuarios y grupos Google frente a usuarios y grupos Microsoft. |
| Permisos | Accesos internos y externos. |
| Destino | OneDrive o SharePoint. |
| Contenido compartido | Evitar dependencias de cuentas individuales. |
| Formatos Google | Comprobar cómo se tratarán los tipos de archivo específicos. |
Referencia oficial: Microsoft – Migrate Google Workspace to Microsoft 365 with Migration Manager.
¿Quieres abandonar Google Workspace?
Podemos valorar por separado Gmail, calendarios, contactos, My Drive, Shared Drives, dominios y usuarios para preparar un alcance realista y una secuencia de cambio.
Valorar migración Google Workspace a Microsoft 365Migración desde Exchange Server a Exchange Online
Cuando el origen es Exchange Server, Microsoft 365 puede recibir correo, calendarios, contactos y otros elementos del buzón mediante métodos nativos de Exchange.
La arquitectura correcta depende sobre todo de la versión de Exchange, número de usuarios, duración de la transición y necesidad de coexistencia.
| Elemento | Qué revisamos |
|---|---|
| Versión de Exchange | Determina métodos compatibles y estrategia. |
| Buzones | Número, tamaño y crecimiento. |
| Archives | Volumen y licenciamiento destino. |
| Shared mailboxes | Contenido y delegaciones. |
| Salas y recursos | Configuración de reservas y calendario. |
| Permisos | Full Access, Send As y otras delegaciones. |
| Aplicaciones | SMTP, relays, autenticación y conectores. |
| Identidad | Active Directory, UPN y sincronización. |
| Coexistencia | Tiempo que convivirán Exchange local y Exchange Online. |
Cutover, híbrido y otros métodos de Exchange
Microsoft documenta distintas rutas para mover buzones desde Exchange Server a Exchange Online.
Cutover
Puede encajar en determinados entornos donde interesa trasladar la organización en una ventana relativamente concentrada.
No debería elegirse únicamente porque “hay pocos usuarios”; la versión de Exchange y el resto de dependencias siguen siendo importantes.
Hybrid migration
La configuración híbrida permite mantener buzones locales y cloud durante una transición y moverlos progresivamente.
Es especialmente interesante cuando necesitamos coexistencia o una migración por oleadas.
Minimal Hybrid / Express Migration
Microsoft también documenta Minimal Hybrid para determinadas organizaciones que quieren aprovechar Hybrid Configuration Wizard para una transición relativamente rápida sin mantener una coexistencia híbrida a largo plazo.
Staged OutlookAnywhere
Hay que tener cuidado con documentación antigua.
Microsoft retiró Staged OutlookAnywhere onboarding el 8 de mayo de 2025. Para nuevos proyectos donde sea necesaria una incorporación progresiva desde entornos antiguos deben evaluarse otros métodos soportados, como los procedimientos híbridos correspondientes.
Referencia oficial: Microsoft – Staged migration notice.
PST
Los archivos PST pueden formar parte de determinados proyectos, pero no deberían convertirse automáticamente en la estrategia por defecto para sustituir un Exchange Server completo.
Microsoft dispone de un servicio de importación para escenarios donde los PST son realmente el origen de la información que debe trasladarse.
Referencia oficial: Microsoft – Ways to migrate multiple email accounts to Microsoft 365.
Migración desde HCL Domino / HCL Notes hacia Microsoft 365
Muchas organizaciones siguen utilizando los nombres Lotus Notes, Lotus Domino o IBM Notes. Actualmente la familia se comercializa como HCL Notes y HCL Domino.
La diferencia con una migración IMAP es importante.
Domino puede contener mucho más que correo.
| Componente Domino | Posible destino |
|---|---|
| Correo | Exchange Online |
| Calendario | Exchange Online |
| Contactos | Exchange Online |
| Grupos | Objetos Microsoft 365 según función. |
| Documentación | SharePoint u otro repositorio según estructura. |
| Aplicaciones Domino | No tienen una correspondencia automática; necesitan análisis individual. |
| Bases de datos NSF | Depende completamente de su contenido y uso. |
Correo y aplicaciones deben separarse en el assessment
Una aplicación desarrollada sobre Domino no se convierte en una aplicación Microsoft 365 simplemente por migrar el buzón del usuario.
Puede necesitar:
mantenerse temporalmente, rediseñarse, sustituirse por otra solución, trasladarse a Power Platform o migrarse mediante una tecnología específica, dependiendo de su función.
Por eso en estos proyectos conviene crear un inventario separado de aplicaciones y bases de datos Domino.
Calendarios y colaboración
También es importante analizar calendarios compartidos, recursos, workflows y cualquier función que los usuarios utilicen actualmente desde Notes.
El objetivo no debería ser únicamente conservar mensajes, sino conocer qué procesos empresariales dependen de la plataforma.
Referencia oficial: HCL – Notes and Domino product rebranding.
Migración IMAP a Microsoft 365
La migración IMAP a Exchange Online es adecuada cuando el sistema origen proporciona acceso mediante este protocolo.
Es habitual en hostings tradicionales, proveedores de correo y plataformas como Dovecot, Courier o determinados entornos cPanel.
Su principal ventaja es que existe un mecanismo estándar para leer el correo.
Su principal limitación es exactamente la misma: IMAP es un protocolo de correo y carpetas, no una representación completa de un buzón moderno.
| Elemento | Migración IMAP |
|---|---|
| Mensajes | Sí |
| Carpetas de correo | Sí, según estructura y compatibilidad. |
| Contactos | No |
| Calendarios | No |
| Tareas | No |
| Reglas | No como parte de IMAP |
| Configuración del cliente | No |
Microsoft también requiere que los buzones destino existan antes de iniciar el movimiento IMAP.
Qué revisamos antes
Especialmente:
servidor, puerto, cifrado, autenticación, credenciales, tamaño de buzones, número de elementos, carpetas especiales, límites del proveedor y posibles bloqueos por concurrencia.
Nuevos mensajes después de una pasada
También debe existir una estrategia para el correo que continúa llegando al origen durante la transición.
Dependiendo de la herramienta, podemos disponer de sincronizaciones posteriores o necesitar otra estrategia de corte.
Referencia oficial: Microsoft – IMAP migration to Microsoft 365.
Migración desde POP3
POP3 merece un tratamiento distinto porque no podemos asumir que el servidor conserva el buzón completo.
Tradicionalmente muchos clientes POP se configuraban para descargar los mensajes al ordenador y eliminarlos posteriormente del servidor.
En esos entornos puede ocurrir que el servidor solo contenga los últimos meses de correo mientras el histórico completo esté repartido entre uno o varios equipos.
La primera pregunta no es “¿cuántas cuentas POP hay?”
La pregunta es:
¿dónde están realmente todos los mensajes que debemos conservar?
| Situación | Posible estrategia |
|---|---|
| Proveedor ofrece también IMAP y conserva todo el correo | Evaluar migración mediante IMAP. |
| Histórico está en Outlook | Localizar PST u otros almacenes locales. |
| Parte está en servidor y parte en local | Combinar procedimientos evitando duplicados. |
| No sabemos dónde están los datos | Realizar discovery antes de presupuestar como IMAP estándar. |
Por eso una migración POP puede requerir más trabajo operativo que una migración IMAP aunque tenga exactamente el mismo número de usuarios.
Zimbra, Dovecot, cPanel y otros sistemas de correo
“Zimbra a Microsoft 365” o “cPanel a Microsoft 365” no define por sí solo un procedimiento.
Necesitamos conocer qué interfaces ofrece el origen y qué información se quiere conservar.
Si únicamente existe acceso IMAP, la migración tendrá las limitaciones propias de IMAP.
Si el producto dispone de APIs, exportaciones específicas o una herramienta de terceros con soporte nativo, puede ser posible preservar otros componentes.
| Información | Qué necesitamos conocer |
|---|---|
| Correo | IMAP, API o exportación disponible. |
| Calendario | Formato y método de acceso. |
| Contactos | Formato de exportación. |
| Distribución | Listas y grupos existentes. |
| Dominios | DNS y direcciones utilizadas. |
Migración Microsoft 365 Tenant-to-Tenant
Una migración Tenant-to-Tenant de Microsoft 365 aparece habitualmente en fusiones, adquisiciones, separaciones empresariales y consolidaciones.
Es uno de los escenarios más complejos porque el origen y destino utilizan los mismos productos, pero pertenecen a directorios y organizaciones diferentes.
No existe un botón para trasladar todo el tenant
Hay que tratar los workloads de forma coordinada.
| Workload | Consideración |
|---|---|
| Exchange Online | Buzones, routing, dominio, permisos y Archives. |
| OneDrive | Identidad, contenido, permisos y sharing. |
| SharePoint | Sitios, propietarios, metadata, permisos y Teams asociados. |
| Microsoft Teams | Equipos, canales, chats, reuniones, archivos y apps según herramienta. |
| Microsoft Entra ID | Usuarios, grupos, identidad híbrida y aplicaciones. |
| Dominios | Transferencia y dependencias. |
| Aplicaciones | App Registrations, SSO, SCIM, OAuth y Graph. |
Capacidades nativas de Microsoft
Microsoft dispone actualmente de herramientas cross-tenant específicas para Exchange Online, OneDrive y SharePoint.
Además, Microsoft 365 Migration Orchestrator coordina actualmente determinados datos de usuario, entre ellos Exchange Online, OneDrive, chats y reuniones de Teams dentro de su alcance documentado.
Microsoft aclara que esta solución mueve contenido, no identidades, y que datos compartidos como sitios SharePoint o las estructuras de Teams y Channels requieren su estrategia correspondiente.
Referencia oficial: Microsoft – Migration Orchestrator Overview.
Herramientas especializadas
Dependiendo del proyecto podemos evaluar plataformas como Quest On Demand Migration, ShareGate, BitTitan, Cloudiway o AvePoint.
La elección se realiza según workloads, necesidad de deltas, coexistencia, identidad, volumen y fidelidad requerida.
¿Necesitas consolidar o separar tenants de Microsoft 365?
Podemos revisar Exchange, OneDrive, SharePoint, Teams, dominios, usuarios, grupos y aplicaciones antes de seleccionar la herramienta y cerrar el alcance.
Analizar migración Tenant-to-TenantMigración desde file servers, NAS y otros repositorios
Una migración a Microsoft 365 puede incluir también documentación almacenada en servidores Windows, NAS u otros repositorios.
La parte importante no es únicamente copiar los archivos.
Primero hay que decidir cómo debería organizarse la información en Microsoft 365.
| Origen | Decisión de destino |
|---|---|
| Carpeta personal del usuario | Puede encajar en OneDrive. |
| Carpeta de departamento | Normalmente debería evaluarse SharePoint. |
| Proyecto compartido | SharePoint o Team asociado según colaboración. |
| Archivo histórico | Evaluar si debe migrarse, archivarse o permanecer fuera del entorno operativo. |
Antes de migrar analizamos volumen, número de elementos, rutas, nombres, permisos, propietarios y contenido que puede excluirse.
OneDrive o SharePoint: no son destinos intercambiables
Una forma práctica de diferenciarlos es preguntarse quién es propietario del contenido.
| OneDrive | SharePoint |
|---|---|
| Información principalmente asociada al usuario. | Información asociada a la organización o a un equipo. |
| Documentos personales de trabajo. | Documentación departamental. |
| Contenido en elaboración individual. | Proyectos y procesos compartidos. |
| Sharing puntual. | Permisos y colaboración estructurada. |
Una carpeta corporativa utilizada por diez empleados no debería terminar automáticamente en el OneDrive del director del departamento solo porque él tenga permisos sobre ella en el servidor antiguo.
Usuarios, grupos, dominios e identidad
Los datos necesitan identidades destino.
Por eso usuarios y grupos deben prepararse antes de los movimientos donde permisos, propietarios o metadata dependen de ellos.
Durante el diseño revisamos:
UPN, dirección SMTP, dominios, usuarios duplicados, cuentas antiguas, grupos, identidad híbrida y aplicaciones que dependan de esas identidades.
Microsoft Entra ID
Microsoft Entra ID es el servicio de identidad de Microsoft anteriormente denominado Azure Active Directory.
Puede trabajar únicamente en la nube o sincronizarse con Active Directory local cuando la organización mantiene una arquitectura híbrida.
El dominio corporativo
En una migración hacia un tenant nuevo, el dominio puede verificarse y prepararse antes del cambio cuando el escenario lo permite.
En una migración tenant-to-tenant, la transferencia del mismo dominio personalizado necesita una planificación más estricta porque antes de retirarlo del tenant origen deben eliminarse sus dependencias.
MX, Autodiscover, SPF, DKIM y DMARC
El DNS concentra una parte importante del cutover de correo.
| Registro / tecnología | Función |
|---|---|
| MX | Determina dónde se entrega el correo entrante. |
| Autodiscover | Ayuda a los clientes Exchange a localizar el servicio. |
| SPF | Identifica servidores autorizados para enviar por el dominio. |
| DKIM | Firma mensajes enviados desde el dominio. |
| DMARC | Define política y reporting de autenticación del correo. |
No cambies SPF pensando únicamente en Microsoft 365
Antes del cutover necesitamos localizar otras fuentes de envío:
CRM, ERP, aplicaciones web, impresoras, sistemas de ticketing, newsletters y cualquier servicio que envíe utilizando el dominio corporativo.
Si no se documentan, pueden dejar de entregar correctamente después del cambio.
Aplicaciones e integraciones
Esta es una de las áreas que más fácilmente queda fuera de una migración de correo y que más incidencias puede generar después.
| Integración | Qué puede cambiar |
|---|---|
| SMTP | Servidor, autenticación, relay y remitentes. |
| SSO | Microsoft Entra ID, tenant, claims y certificados. |
| OAuth | Consentimientos, Client ID, secretos o certificados. |
| SCIM | Provisioning y mappings. |
| Microsoft Graph | App Registrations, permisos y tenant ID. |
| Backup | Registro y permisos sobre el nuevo tenant. |
Durante el assessment identificamos estas dependencias. Su reconfiguración puede formar parte del proyecto o quedar asignada al proveedor de la aplicación, pero debe existir un responsable.
Seguridad durante la migración
El tenant destino debería tener una base de seguridad antes de recibir usuarios de producción.
La migración no debería convertirse en una excusa para mantener indefinidamente cuentas administrativas sin MFA o permisos excesivos concedidos a las herramientas.
MFA
Microsoft está aplicando progresivamente MFA obligatorio a sus portales y herramientas administrativas.
En nuevos proyectos debemos asumir por tanto que las cuentas administrativas utilizarán autenticación multifactor y diseñar también el acceso de los usuarios.
Security Defaults y Conditional Access
Para organizaciones sin Microsoft Entra ID P1/P2, Security Defaults puede proporcionar una protección básica.
Cuando existe licenciamiento adecuado y se necesita más granularidad, Conditional Access permite aplicar políticas diferentes según usuarios, roles, dispositivos, aplicaciones y riesgo.
Permisos de las herramientas de migración
Plataformas como Quest, BitTitan, ShareGate o cualquier solución que utilice APIs de Microsoft puede necesitar permisos elevados para leer y escribir datos.
Estos consentimientos deben documentarse y revisarse al terminar el proyecto.
Referencia oficial: Microsoft – Mandatory multifactor authentication.
Herramientas de migración que podemos utilizar
La tecnología depende del origen y del workload.
No utilizamos una misma herramienta para todos los proyectos.
| Herramienta / tecnología | Escenarios habituales |
|---|---|
| Exchange Online Migration | Exchange Server, Google Workspace e IMAP según método soportado. |
| Exchange Hybrid | Coexistencia y migración progresiva desde Exchange Server. |
| Migration Manager | Google Drive, Dropbox, file shares y otros orígenes soportados hacia Microsoft 365. |
| SharePoint Migration Tool | SharePoint Server y file shares. |
| Microsoft cross-tenant | Exchange, OneDrive, SharePoint y Orchestrator según workload. |
| Quest On Demand Migration | Microsoft 365 Tenant-to-Tenant multiworkload. |
| BitTitan MigrationWiz | Correo y diferentes escenarios SaaS según proyecto. |
| ShareGate | SharePoint, OneDrive, Teams y capacidades T2T actuales. |
| Cloudiway | Escenarios cross-platform y Tenant-to-Tenant. |
| AvePoint | Migraciones enterprise y diferentes workloads. |
| CodeTwo | Proyectos donde Exchange es la carga principal. |
| PowerShell / Microsoft Graph | Discovery, preparación, automatización y validación. |
La herramienta se selecciona después de comprender el alcance. Esto evita pagar por funcionalidades que no necesitamos o descubrir demasiado tarde que una plataforma no trata correctamente un componente crítico.
Cómo desarrollamos un proyecto de migración
1. Discovery
Recopilamos la información necesaria del origen: usuarios, buzones, dominios, repositorios, tamaño, permisos y aplicaciones.
2. Definición del alcance
Separamos aquello que debe migrarse de lo que requiere recreación, limpieza, archivo o un proyecto independiente.
3. Diseño
Definimos tenant destino, licencias, identidad, seguridad, destino de archivos, herramientas, oleadas y cutover.
4. Preparación del entorno
Configuramos los elementos acordados en Microsoft 365 y los prerrequisitos de las herramientas.
5. Discovery de la herramienta
Cuando la plataforma dispone de análisis propio, contrastamos su inventario con el obtenido anteriormente.
6. Piloto
Seleccionamos usuarios y datos representativos.
7. Premigración
Cuando la tecnología soporta varias pasadas, trasladamos con antelación la mayor cantidad posible de información.
8. Cutover
Ejecutamos las operaciones finales siguiendo un runbook previamente preparado.
9. Validación
Comprobamos los servicios incluidos utilizando tanto informes técnicos como pruebas funcionales.
10. Estabilización
Atendemos incidencias relacionadas con la migración durante la fase post-cambio definida para el proyecto.
Por qué hacemos piloto
Un piloto permite convertir estimaciones en datos reales.
| Caso | Qué queremos comprobar |
|---|---|
| Buzón estándar | Flujo normal. |
| Buzón grande | Rendimiento. |
| Shared mailbox | Permisos y comportamiento. |
| Calendario relevante | Fidelidad cuando el origen no es Exchange. |
| Usuario con muchos datos | Tiempo y errores. |
| Contenido compartido | Permisos y mapping. |
| Aplicación integrada | Autenticación y dependencias. |
El piloto puede confirmar el diseño o hacer que modifiquemos herramienta, mapping, fases o procedimiento antes de afectar al resto de usuarios.
La ventana de cambio
El cutover es el momento en el que se ejecutan aquellos cambios que no pueden mantenerse indefinidamente en paralelo.
| Actuación | Puede formar parte del cutover |
|---|---|
| Sincronización final | Sí, cuando la herramienta dispone de delta. |
| MX | Sí. |
| Autodiscover | Según estrategia. |
| Dominio | Especialmente crítico en Tenant-to-Tenant. |
| Identidad | Cambios previstos de UPN o acceso. |
| Aplicaciones | Cambios que deben activarse en el nuevo entorno. |
Estas operaciones deben aparecer en un runbook con orden, responsables, validaciones y condiciones de parada.
Validación y soporte después de la migración
El proyecto no debería cerrarse simplemente porque la herramienta muestre los jobs como completados.
| Área | Qué validamos |
|---|---|
| Identidad | Inicio de sesión y MFA. |
| Correo entrante | Recepción desde Internet. |
| Correo saliente | Entrega y autenticación. |
| Calendario | Creación y recepción de reuniones cuando entra en alcance. |
| Shared mailboxes | Acceso y permisos. |
| OneDrive | Contenido y acceso. |
| SharePoint | Sitios, información y permisos. |
| Teams | Componentes incluidos en el proyecto. |
| Aplicaciones | Integraciones incluidas expresamente. |
| DNS | MX, SPF, DKIM, DMARC y resto de configuración acordada. |
Qué ocurre con Outlook, móviles y equipos de los usuarios
Una migración puede producir cambios visibles en los clientes que utiliza el usuario.
Dependiendo del origen y de la transición, puede ser necesario volver a autenticarse, añadir una cuenta, actualizar el perfil de Outlook o volver a vincular aplicaciones.
Estas actuaciones deben diferenciarse del trabajo realizado en el tenant.
En Kloudeal podemos proporcionar al equipo de TI del cliente la información y los requisitos necesarios para el cambio, pero la configuración individual de cada puesto de trabajo o dispositivo no debe darse por incluida salvo que se haya definido expresamente en el alcance.
Esto resulta especialmente importante al presupuestar migraciones con muchos usuarios, porque una cosa es mover 500 buzones en Microsoft 365 y otra distinta intervenir físicamente o remotamente sobre 500 ordenadores.
Qué necesitamos para preparar una propuesta
No es necesario que dispongas de un assessment completo para pedir una primera valoración.
Estos datos suelen ser suficientes para comenzar:
| Información | Ejemplo |
|---|---|
| Origen | Google Workspace, Exchange Server, IMAP, Domino, Microsoft 365… |
| Número de usuarios | 125 |
| Buzones compartidos | 14 |
| Tamaño aproximado | 2,6 TB de correo |
| Calendarios y contactos | Necesitan migrarse / no aplica. |
| Archivos | Google Drive, Dropbox, NAS… |
| SharePoint / Teams | Si existen o deben migrarse. |
| Dominios | empresa.com, filial.com. |
| Identidad | Cloud-only o Active Directory. |
| Fecha objetivo | Mes o fecha de cutover deseada. |
Si alguno de estos datos no está disponible podemos ayudar a obtenerlo durante la fase inicial.
¿Quieres que preparemos una propuesta?
Indícanos desde qué plataforma queréis migrar, cuántos usuarios tenéis y qué servicios queréis trasladar. Revisaremos el escenario y os diremos qué información adicional necesitamos.
Solicitar presupuesto de migración Microsoft 365Errores frecuentes en una migración a Microsoft 365
| Error | Problema | Mejor enfoque |
|---|---|---|
| Tratar todos los orígenes igual | Se prometen elementos que el protocolo no contiene. | Diseñar por plataforma. |
| Considerar IMAP una migración completa | Faltan calendarios y contactos. | Explicar el alcance antes. |
| Presupuestar POP como IMAP | El histórico puede estar en equipos locales. | Localizar primero los datos. |
| Migrar Domino como si fuera solo correo | Se olvidan aplicaciones y bases de datos. | Inventariarlas aparte. |
| Utilizar documentación Exchange antigua | Se intenta utilizar un método retirado. | Validar las rutas actuales. |
| No separar Google Drive y Gmail | Se mezclan workloads y destinos diferentes. | Diseñar correo y archivos por separado. |
| No revisar shared mailboxes | Se pierde funcionalidad de delegación. | Inventariar permisos. |
| No revisar DNS | Problemas de entrega de correo. | Preparar un plan de cutover. |
| Olvidar aplicaciones SMTP | ERP o webs dejan de enviar correo. | Inventariar remitentes. |
| No hacer piloto | Las limitaciones aparecen con los usuarios reales. | Probar previamente. |
| Prometer interrupción cero | Expectativas poco realistas. | Explicar el impacto previsto. |
| Dar por incluida la configuración de cada PC | El alcance crece de forma descontrolada. | Separar tenant y endpoint. |
| Cerrar cuando termina el job | No se detectan problemas funcionales. | Validar después. |
Checklist antes de migrar a Microsoft 365
| Área | Comprobación |
|---|---|
| Origen | Está identificado exactamente. |
| Usuarios | Tenemos número y listado cuando es posible. |
| Buzones | Conocemos tamaños y casos especiales. |
| Shared mailboxes | Inventariados junto con sus permisos. |
| Calendarios | Sabemos si el método seleccionado los migra. |
| Contactos | Sabemos si están incluidos. |
| Archivos | Repositorios identificados. |
| OneDrive / SharePoint | Destino documental definido. |
| Dominios | Plan de configuración o transferencia preparado. |
| MX | Cambio planificado. |
| SPF / DKIM / DMARC | Revisados. |
| Aplicaciones SMTP | Inventariadas. |
| Identidad | Cloud-only o híbrida definida. |
| Licencias | Preparadas según perfiles. |
| Herramienta | Seleccionada después del assessment. |
| Seguridad | MFA y configuración base previstas. |
| Piloto | Usuarios representativos seleccionados. |
| Cutover | Runbook y responsables preparados. |
| Usuarios | Comunicación preparada. |
| Endpoints | Responsable de configuración local definido. |
| Validación | Criterios de aceptación acordados. |
| Hypercare | Soporte posterior planificado. |
Preguntas frecuentes sobre nuestros servicios de migración a Microsoft 365
Podemos estudiar migraciones desde Google Workspace, Exchange Server, HCL Domino, IMAP, POP3, Zimbra, cPanel, otros proveedores de correo, file servers y otros tenants Microsoft 365, entre otros escenarios.
El alcance y la herramienta cambian según el origen.
Sí.
El proyecto puede limitarse a Exchange Online o incluir también calendarios, contactos, OneDrive, SharePoint, Teams, dominios y otros componentes.
Sí.
Microsoft dispone de procedimientos para migrar Gmail, calendarios y contactos hacia Exchange Online y de Migration Manager para trasladar Google Drive hacia OneDrive y SharePoint.
Puede incluirse.
Antes conviene decidir qué My Drives se corresponden con OneDrive y qué información compartida debería terminar en SharePoint.
Sí pueden formar parte del proyecto.
Normalmente SharePoint es un destino más lógico para contenido compartido que pertenece a equipos o departamentos.
Sí.
Microsoft ofrece diferentes rutas dependiendo de la versión, tamaño y coexistencia, incluyendo procedimientos cutover, Minimal Hybrid e Hybrid Migration en los escenarios compatibles.
No en todos los proyectos.
Hybrid resulta especialmente útil cuando necesitamos coexistencia o una migración progresiva, pero existen otros métodos para determinados entornos.
Microsoft retiró Staged OutlookAnywhere onboarding el 8 de mayo de 2025.
Los proyectos nuevos deben utilizar un método actualmente soportado apropiado para la versión y arquitectura del entorno.
Sí puede diseñarse una migración desde HCL Domino / Notes hacia Microsoft 365.
Sin embargo, debe distinguirse entre correo, calendarios y contactos y las aplicaciones o bases de datos Domino, que necesitan un assessment separado.
Son denominaciones utilizadas en diferentes etapas de la evolución del producto.
La denominación actual es HCL Notes / HCL Domino, aunque muchas organizaciones continúan utilizando los nombres Lotus Notes o IBM Notes.
No.
Una aplicación Domino puede necesitar mantenerse, rediseñarse, sustituirse o transformarse en otra tecnología.
No debe darse por incluida dentro de una simple migración de correo.
Sí.
IMAP permite trasladar principalmente correo y carpetas desde sistemas compatibles hacia Exchange Online.
No.
El protocolo IMAP no incluye contactos, calendario ni tareas. Si esos datos deben conservarse necesitamos otra fuente o procedimiento.
No como parte del protocolo IMAP.
Las reglas y otras configuraciones dependen del sistema origen y pueden necesitar recreación o tratamiento específico.
Sí puede trasladarse la información existente, pero primero hay que determinar dónde se encuentra.
En entornos POP3 es frecuente que parte del correo histórico esté descargado en ordenadores o PST y ya no exista en el servidor.
Puede ocurrir.
Si tenemos que localizar archivos locales, trabajar con múltiples PST o combinar correo de servidor y dispositivos, el esfuerzo puede ser superior al de una migración IMAP centralizada.
Sí.
El método depende de la versión, interfaces disponibles y de si solo necesitamos correo o también calendarios, contactos y otros componentes.
Sí, normalmente cuando las cuentas proporcionan acceso IMAP.
En ese caso se aplican las limitaciones propias de una migración IMAP.
Sí.
Es una migración Tenant-to-Tenant y puede incluir Exchange Online, OneDrive, SharePoint, Microsoft Teams, dominios, usuarios y otros componentes según el alcance.
Sí.
Microsoft dispone de capacidades específicas para Exchange Online, OneDrive y SharePoint y de Migration Orchestrator para determinados datos de usuario y workloads.
No.
Actualmente Microsoft documenta un alcance concreto de workloads y especifica que la solución mueve contenido, no identidades.
SharePoint Sites y estructuras compartidas de Teams necesitan su estrategia correspondiente.
Sí.
Quest On Demand Migration es una de las plataformas que podemos evaluar para proyectos Tenant-to-Tenant de Microsoft 365, especialmente cuando existen varios workloads.
No.
La herramienta depende del proyecto. En otros escenarios pueden resultar más apropiadas las capacidades nativas de Microsoft, BitTitan, ShareGate, Cloudiway, AvePoint, CodeTwo u otras tecnologías.
Sí puede incluirse una migración documental desde file servers o NAS hacia Microsoft 365.
Antes de ejecutarla debemos decidir qué información pertenece a OneDrive y qué debería organizarse en SharePoint.
Normalmente no es la mejor arquitectura si son datos que pertenecen al departamento.
SharePoint suele ser más adecuado para contenido compartido que no debe depender de una persona concreta.
Sí puede incluirse en determinados proyectos.
Pero hay que especificar si hablamos de equipos, canales, chats, reuniones, archivos, Planner, apps, invitados u otros componentes porque cada uno puede tener capacidades diferentes.
Existen actualmente capacidades de Microsoft y herramientas de terceros para determinados chats y reuniones.
El resultado y las limitaciones deben confirmarse según la tecnología elegida.
Normalmente se cambia cuando el entorno destino está preparado para recibir correo y ha llegado la ventana de cutover.
La secuencia exacta depende del escenario.
Podemos incluir la configuración relacionada con Microsoft 365 dentro del alcance.
Antes necesitamos identificar otras plataformas que también envíen correo utilizando el dominio corporativo.
Deben identificarse antes del cambio.
ERP, CRM, páginas web, impresoras o sistemas de ticketing pueden necesitar modificar autenticación, relay o configuración DNS.
MFA debe considerarse una medida básica de seguridad y Microsoft está aplicando progresivamente MFA obligatorio sobre sus portales y herramientas administrativas.
El diseño para usuarios depende del licenciamiento y las políticas de la organización.
Depende de la tecnología.
Muchas herramientas permiten realizar una carga inicial y posteriormente sincronizar cambios. Otros procedimientos funcionan mediante un movimiento definitivo y necesitan una estrategia diferente.
Es muy recomendable.
Permite comprobar tiempos, errores y fidelidad con datos reales antes de afectar al resto de la organización.
Trabajamos para reducir el impacto, pero no es recomendable prometer interrupción cero.
DNS, correo, dominios, identidad y aplicaciones pueden necesitar una ventana de transición.
En muchos métodos sí durante gran parte del proyecto.
Cuando existen premigraciones, los usuarios pueden continuar trabajando en origen hasta la ventana de corte.
La migración del tenant y la configuración individual de puestos son alcances diferentes.
Podemos proporcionar instrucciones y coordinarnos con el equipo de TI del cliente, pero la intervención individual sobre equipos debe aparecer expresamente en la propuesta si se requiere.
La configuración individual de dispositivos no debe darse por incluida automáticamente.
Podemos proporcionar instrucciones o requisitos y definir expresamente cualquier actuación adicional necesaria.
Depende del origen.
Exchange y Google Workspace disponen de métodos capaces de tratarlos. IMAP no los incluye y en Domino requieren una revisión específica.
No existe una duración estándar.
Depende de usuarios, tamaño de buzones, número de elementos, archivos, herramienta, origen, coexistencia, aplicaciones y ventana de cambio.
Depende del número de objetos y de los servicios incluidos.
Una migración de 50 buzones IMAP tiene un alcance muy diferente de una migración de 50 usuarios desde Google Workspace con Drive o de un Tenant-to-Tenant con SharePoint y Teams.
Como punto de partida necesitamos origen, número de usuarios, buzones compartidos, tamaño aproximado, dominios, necesidad de calendarios y contactos, datos documentales, identidad y fecha objetivo.
Sí.
Podemos asumir la parte especializada de la migración y coordinarnos con vuestro equipo o con otros proveedores para las tareas que dependan de endpoints, aplicaciones, red o comunicaciones internas.
Conclusión: el origen determina cómo debe hacerse la migración
Hablar genéricamente de “migrar a Microsoft 365” oculta gran parte de la complejidad real del proyecto.
Una migración desde Google Workspace debe separar Gmail de Google Drive y definir cómo se mapearán identidades y destinos documentales.
Una migración desde Exchange Server debe decidir qué modelo de coexistencia necesita la empresa y utilizar un método compatible con la versión y arquitectura actuales.
En HCL Domino hay que diferenciar el correo de las aplicaciones y bases de datos que forman parte de procesos empresariales.
En IMAP debemos asumir desde el principio que calendarios y contactos no viajan mediante el protocolo. Y en POP3 lo primero es localizar dónde se encuentra realmente el histórico de correo.
En un proyecto Tenant-to-Tenant, por otro lado, aparecen dependencias adicionales entre Exchange Online, OneDrive, SharePoint, Teams, identidad, dominios y aplicaciones.
Por eso el procedimiento que seguimos en Kloudeal comienza identificando el origen y el alcance real, continúa seleccionando la herramienta adecuada y utiliza piloto, premigración, cutover y validación para controlar el cambio.
El objetivo no es simplemente conseguir que la herramienta muestre un porcentaje de migración completado. Es que el nuevo entorno de Microsoft 365 quede preparado para que la organización pueda continuar trabajando con los datos y servicios que realmente necesita.
¿Necesitas migrar a Microsoft 365?
Cuéntanos brevemente desde qué plataforma queréis migrar y cuántos usuarios tenéis.
Podemos ayudarte con migraciones desde Google Workspace, Exchange Server, HCL Domino, IMAP, POP3, Zimbra, otros proveedores de correo, servidores de archivos y Microsoft 365 Tenant-to-Tenant.
Según el proyecto podemos incluir Exchange Online, calendarios, contactos, buzones compartidos, dominios, DNS, OneDrive, SharePoint, Microsoft Teams, Microsoft Entra ID, herramientas de migración, piloto, cutover, validación y soporte posterior.
Solicitar valoración de migración a Microsoft 365Documentación oficial recomendada
Microsoft – migración de correo
- Microsoft – Ways to migrate multiple email accounts to Microsoft 365
- Microsoft – Exchange Server Hybrid Deployments
- Microsoft – Minimal Hybrid / Express Migration
- Microsoft – Staged Migration and OutlookAnywhere Retirement Notice
Google Workspace
- Microsoft – Google Workspace Mail Migration
- Microsoft – Switch from Google Workspace to Microsoft 365
- Microsoft – Google Workspace to Microsoft 365 with Migration Manager
- Microsoft – Map Google identities with Migration Manager
IMAP
Microsoft 365 Tenant-to-Tenant
- Microsoft – Microsoft 365 Migration Overview
- Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration
- Microsoft – Migration Orchestrator Overview
- Microsoft – Cross-Tenant Mailbox Migration
- Microsoft – Cross-Tenant OneDrive Migration
- Microsoft – Cross-Tenant SharePoint Migration
Microsoft Entra ID y MFA
- Microsoft – Microsoft Entra ID Name Change
- Microsoft – Mandatory Multifactor Authentication
- Microsoft – Security Defaults