Servicios de migración a Microsoft 365 para empresas

Cómo comparar servicios de migración a Microsoft 365

Dos propuestas con el mismo número de usuarios pueden incluir trabajos muy distintos. Para comparar servicios de migración a Microsoft 365 hay que revisar análisis previo, preparación, transferencia, validación y soporte. La oferta debe describir también las cargas incluidas y las que necesitan un proyecto independiente. Sin ese detalle, el precio puede parecer comparable mientras el cliente espera un resultado que una de las propuestas no contempla.

Por ejemplo, migrar los buzones puede incluir únicamente el contenido o contemplar además los accesos de Outlook, los móviles y las aplicaciones que envían correo. La diferencia afecta a la experiencia del primer día y al esfuerzo del equipo interno. Cada tarea debe tener un responsable y una condición de entrega, especialmente cuando intervienen proveedor, departamento de TI y responsables de negocio.

Las exclusiones deben explicarse con sus consecuencias prácticas. Si una aplicación no admite el método previsto o un histórico solo existe en equipos locales, no basta con indicar que queda fuera. La propuesta debe identificar quién lo resolverá y si condiciona el calendario. Esto permite aprobar un alcance con conocimiento de las dependencias que siguen abiertas.

Qué documentación y acompañamiento debe dejar el servicio

La entrega debería permitir que el equipo que operará Microsoft 365 entienda qué se ha hecho y qué queda pendiente. Son útiles el inventario final, las decisiones de destino, los informes de transferencia y los resultados de las pruebas. Las diferencias aceptadas deben quedar separadas de las incidencias que todavía requieren una corrección, con responsable y siguiente actuación.

El acompañamiento se concreta por canal, cobertura y criterios de escalado. También debe existir un procedimiento para una necesidad que se descubra durante el proyecto: se evalúan impacto, solución y cambio de alcance antes de incorporarla al calendario. Esa disciplina evita que una expectativa no documentada aparezca como conflicto cuando los usuarios ya están trabajando en el nuevo entorno.

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.

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.

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.

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:

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.

Referencia oficial: Microsoft – Migrate Google Workspace to Microsoft 365 with Migration Manager.

Migració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.

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.

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.

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?

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.

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.

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.

Migració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.

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.

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.

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.

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.

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.

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.

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.

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:

Si alguno de estos datos no está disponible podemos ayudar a obtenerlo durante la fase inicial.

Errores frecuentes en una migración a Microsoft 365

Checklist antes de migrar a Microsoft 365

Preguntas frecuentes sobre nuestros servicios de migración a Microsoft 365

¿Qué debería incluir una propuesta de migración a Microsoft 365?

Debe describir fuentes, destinos, cargas, preparación, método, validación y soporte, además de las responsabilidades de cada parte. Las exclusiones y dependencias deben ser comprensibles para el cliente. Una cifra de usuarios no basta para saber si se incluyen equipos, aplicaciones, permisos o información que requiere un tratamiento especial.

¿Cómo se compara el precio de dos proveedores?

Se compara primero un alcance equivalente y el resultado que entregará cada uno. Deben revisarse tareas de preparación, pruebas, licencias de herramientas y acompañamiento incluidos. También interesa saber qué trabajo conservará el equipo interno y cómo se tratarán incidencias o necesidades adicionales. Un precio menor puede corresponder a menos servicio, no a mayor eficiencia.

¿Qué debe aportar la empresa al proyecto?

Necesita facilitar información del entorno, responsables de los datos y personas que puedan validar procesos. También debe coordinar accesos autorizados y comunicar restricciones operativas. El proveedor puede guiar el análisis, pero las decisiones de negocio y la aceptación de determinados cambios requieren participación de quienes utilizarán y administrarán el destino.

¿Qué conviene exigir para aceptar la entrega?

Conviene acordar pruebas antes de empezar y recibir sus resultados al terminar. Los informes deben permitir comprobar las cargas incluidas, entender diferencias y localizar incidencias pendientes. La entrega operativa incluye documentación y responsables de soporte; un mensaje de copia completada no sustituye la aceptación del funcionamiento previsto.

Recomendaciones finales: 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.

Documentació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 – IMAP Mailbox Migration

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

HCL Domino / Notes.

• HCL – Notes and Domino Product Rebranding