Para migrar de Google Workspace a Microsoft 365, se hace un inventario de usuarios, datos e integraciones, se preparan identidades, licencias y dominio, se prueba con un grupo piloto y se mueven correo, calendarios y archivos por lotes antes de cambiar el enrutamiento del correo. Después se validan permisos y reglas y se cierra Google. Los plazos varían.
Muchas migraciones se complican antes de mover un solo dato: un buzón compartido sin listar, una regla de reenvío olvidada o una aplicación que inicia sesión con una cuenta de Google y deja de funcionar sin avisar. Trasladar correo, calendarios y contactos es lo que los fabricantes documentan bien; esta guía cubre lo que lo rodea: si conviene cambiar, qué preparar, cómo es una migración por fases, qué se traslada bien y qué comprobar después. Está pensada para gerentes y responsables de IT de pymes sin un equipo de migración dedicado. En BlueNova IT trabajamos en cloud y Microsoft 365 y, cuando ayuda, en IT cogestionada con su equipo. Herramientas, límites y requisitos cambian, así que trate la documentación actual de cada fabricante como referencia final.
¿Dudas sobre esta guía? Hable con nosotros
¿Conviene migrar de Google Workspace a Microsoft 365?
Cambiar de plataforma es una decisión de negocio antes que un proyecto técnico: contraste sus motivos con los motivos para esperar y ponga el inventario por escrito antes de fijar fecha. BlueNova IT ofrece servicios de cloud y Microsoft 365 junto con consultoría IT, y podemos revisar con usted el inventario y la decisión; el alcance se acuerda con cada organización, sin promesas de resultados, plazos ni ahorros. Cuánto se traslada de cada área depende de la herramienta; compruebe la documentación actual.| Área | Qué suele migrarse | Qué requiere planificación | Qué comprobar |
|---|---|---|---|
| Correo y calendario | Mensajes, eventos y contactos | Etiquetas frente a carpetas, calendarios compartidos | Reglas, delegados, correo antiguo |
| Archivos | Unidades personales | Unidades compartidas, permisos, archivos nativos de Google | Quién abre qué, enlaces externos |
| Identidad | Nada: las cuentas se crean antes | Grupos, inicio de sesión, aplicaciones con acceso de Google | Acceso de terceros, multifactor |
| Dispositivos | Clientes de correo reconectados | Perfiles, móviles, gestión | Inicio de sesión en cada tipo |
Motivos que suelen sostenerse
Unificar el trabajo en Outlook, Teams y las aplicaciones de Office es el motivo que mejor resiste el análisis. Consolidar inquilinos tras una fusión es otro: dos sistemas de correo y dos consolas de administración consumen atención cada semana. Un motivo se sostiene si puede nombrar la tarea diaria que se simplifica y a la persona que lo confirmará que así fue. «Queremos modernizarnos» es un estado de ánimo, no un motivo. Anote dos o tres con su evidencia antes de mirar herramientas.Motivos para esperar
Esperar es a veces la decisión sensata. Si depende de automatizaciones de Apps Script, flujos con Formularios de Google o sitios de Google Sites, cada pieza necesitará un sustituto o una reescritura. Otra señal de alarma es que nadie sepa quién es propietario de una unidad compartida: sin dueño, nadie aprueba qué ocurre con ella. Un cierre de ejercicio es un mal momento para cambiar el correo de toda la empresa. Una migración aplazada a una fecha acordada suele salir mejor que una precipitada que deja a la gente sin ayuda.Qué inventariar antes de decidir
Un inventario de cuentas, buzones compartidos, grupos, reglas de reenvío y aplicaciones que inician sesión con Google convierte una opinión en un plan. Empiece por todas las cuentas, incluidas las de antiguos empleados, y marque cuentas de servicio y buzones compartidos. Añada grupos, filtros, reglas de reenvío y accesos delegados, y liste las unidades compartidas con su propietario y su uso compartido externo. Localice también las aplicaciones y los dispositivos que inician sesión con Google o envían correo solos. Asigne un responsable por línea: las líneas sin dueño dan problemas.Si el punto de partida es un servidor local
Partir de un servidor de correo o de archivos local cambia el planteamiento. No hay cuenta de Google que dar de baja, pero sí equipos, un directorio y una red construida alrededor de la instalación antigua. Los usuarios suelen proceder de un directorio local, así que hay que decidir cómo se relaciona con Microsoft 365. Los permisos de los recursos compartidos suelen basarse en carpetas y hay que reasignarlos a una estructura nueva. Los métodos difieren de los del camino desde Google; compruebe la documentación actual de Microsoft para su origen. Esta guía no los cubre.Qué planificar antes de mover nada
Los requisitos previos son sobre todo decisiones tomadas con antelación y condicionan el resultado más que cualquier herramienta. Úselos como lista de comprobación y confírmelos en la documentación actual de Microsoft y en la de Google, porque cambian.- Cree el inquilino de Microsoft 365 y decida quién lo administra.
- Dé de alta a los usuarios y asigne licencias antes de mover datos.
- Verifique su dominio y planifique el enrutamiento del correo.
- Decida qué datos entran en el alcance y limpie los que no.
- Planifique dispositivos, inicio de sesión y accesos, con autenticación multifactor.
- Acuerde quién informa a los usuarios y cuándo.
Usuarios, licencias e identidad
Los usuarios suelen tener que existir en Microsoft 365, con su licencia asignada, antes de poder mover sus datos. Cree las cuentas a mano si son pocas o en bloque desde un archivo si el equipo es mayor, y decida qué ocurre con alias y buzones compartidos. Si las licencias se cobran por usuario, el coste crece con la plantilla; resuelva pronto las cuentas de antiguos empleados. Las aplicaciones que permiten entrar con Google necesitan otra vía. Compruebe en la documentación actual de licencias qué incluye cada plan.Dominio, DNS y enrutamiento del correo
El dominio debe estar verificado, y el enrutamiento del correo entre ambas plataformas se suele planificar con antelación. Verificarlo consiste normalmente en añadir un registro en el DNS que demuestre que lo controla. Durante el traslado, ambas plataformas pueden recibir correo de la misma dirección, por lo que muchos planes usan subdominios de enrutamiento. Reduzca el tiempo de vida (TTL) de los registros de correo antes del cambio. Compruebe quién tiene las credenciales del registrador y del DNS: su ausencia es una causa frecuente de retrasos. Tras el cambio, actualice SPF, DKIM y DMARC para la plataforma nueva.Alcance de los datos y limpieza previa
Decidir qué no se migra acorta el traslado y ordena el nuevo entorno. El correo antiguo es el candidato habitual: muchas organizaciones fijan una fecha de corte, mueven lo reciente y archivan el resto. En Drive, busque archivos abandonados y copias duplicadas. Los archivos personales (OneDrive) y las unidades compartidas (SharePoint) suelen tener destinos distintos, así que decida el de cada uno. Registre cada decisión: un alcance escrito permite distinguir un hueco de una elección.Dispositivos y accesos
Cada portátil, teléfono y tableta que toque datos de la empresa forma parte de la migración. Los portátiles con Windows pueden requerir un nuevo registro, y en los teléfonos suele haber que quitar y volver a añadir el perfil de correo. Revise escáneres y herramientas de supervisión que envían correo solos: sus credenciales fijas suelen dejar de funcionar tras el cambio. Haga una lista de dispositivos con una persona y una fecha para cada uno, y fije los accesos de forma deliberada, no los herede de la configuración anterior.Cómo funciona una migración por fases
Una migración por fases sigue una secuencia conocida, aunque las herramientas y los pasos exactos varían y deben confirmarse en la documentación actual.- Piloto: un grupo pequeño se mueve primero para probar el proceso y el soporte.
- Copia previa: los datos antiguos se copian por adelantado mientras todos siguen en Google.
- Lotes: el resto de usuarios pasa por grupos, para poder atender las dudas.
- Cambio del correo: el enrutamiento pasa a Microsoft 365.
- Pasada final: se traslada lo que cambió desde la última copia.
Leer los pasos en texto
Inventario, preparación, piloto, lotes, cambio, comprobar y cerrar
Empezar con un grupo piloto
Un grupo piloto prueba el proceso y la rutina de soporte antes de que afecte a todos. Elija personas de funciones distintas: alguien con un buzón muy grande, alguien que dependa de calendarios compartidos, un usuario intensivo de Drive y quien lea el correo sobre todo en el móvil. Recorra el camino completo, del alta de la cuenta al inicio de sesión en cada dispositivo y una prueba de correo en ambos sentidos, y anote cada pregunta: serán su guía de usuario. Para planificar esa rutina, nuestra guía de servicios de soporte IT explica qué preguntar a un proveedor.Copia previa y después lotes
Mover los datos antiguos con antelación permite que la pasada final solo traslade los cambios recientes. Durante la copia previa los usuarios siguen en Google mientras una herramienta copia el correo y los archivos históricos; compruebe en la documentación actual cómo lo gestiona la elegida. Después, los lotes pasan a los usuarios por grupos. Agrupe por equipos y mantenga lotes lo bastante pequeños para atender las dudas. Entre lote y lote, revise los elementos fallidos y omitidos: un informe solo sirve si alguien lo lee, y cada fallo requiere una decisión.El cambio del correo
Cambiar el enrutamiento del correo es el momento que notan los usuarios, así que necesita una ventana comunicada y un plan de vuelta atrás pensado de antemano. En una migración de Gmail a Exchange Online, es cuando el correo llega al buzón nuevo. Elija un momento tranquilo y avise con un mensaje breve: qué cambia, qué deben hacer y a quién preguntar. Como el cambio tarda en propagarse, algunos mensajes pueden seguir llegando al sistema antiguo, así que revise ambos buzones. Decida antes qué revertiría, quién decide y hasta cuándo, y después pruebe envíos y recepciones, también desde fuera y hacia grupos.
Leer los pasos en texto
Aviso, cambio de enrutamiento, pasada final y verificación
La pasada final de diferencias
La pasada final recoge lo que cambió tras la copia previa y entre lotes: correo llegado al sistema antiguo, archivos editados y eventos nuevos. Ejecútela cuando el enrutamiento ya haya cambiado, para que nada nuevo llegue a Google. Compare lo esperado con lo recibido: revise por muestreo buzones de distinto tamaño y abra calendarios y carpetas compartidos. Mantenga Google Workspace activo en este periodo, sin suspender cuentas ni eliminar datos. Anote la fecha: desde ahí el trabajo nuevo se hace solo en Microsoft 365 y empiezan las comprobaciones posteriores.Qué se migra bien y qué requiere planificación
El correo, los calendarios y los contactos son la parte más madura de cualquier migración; los archivos y el uso compartido son donde están las decisiones. Trate la tabla inicial como una lista de partida, no como una promesa: algunos elementos no se trasladan, otros llegan de otra forma, y la lista exacta depende de la herramienta y de la documentación vigente del fabricante.Si un elemento importa para el negocio, pruébelo en el piloto y anote el resultado. No dé por hecho que se movió.BlueNova IT puede ayudarle a decidir qué se convierte, qué se rediseña y qué se archiva, sin asumir que todo llegue sin cambios; el alcance se concreta según el caso.
Correo, calendario y contactos
Correo, calendarios y contactos son lo mejor soportado, con carencias que dependen de la herramienta, como los calendarios compartidos o las reservas de salas; compruebe la documentación actual. Las etiquetas se tratan como carpetas o categorías, y un mensaje con varias etiquetas puede verse distinto después, así que mire ejemplos en el piloto. Las reglas y los filtros pueden llegar desactivados y alguien debe revisarlos y reactivarlos. Las respuestas automáticas, los delegados y los calendarios compartidos conviene configurarlos de nuevo y probarlos.Archivos de Drive y unidades compartidas
Las unidades personales suelen corresponderse con el OneDrive de cada persona, y las unidades compartidas, con sitios o bibliotecas de SharePoint. Es una decisión de diseño, no una copia: fije quién es propietario de cada sitio, cómo se estructura y quién puede compartir fuera de la empresa. El uso compartido de Google suele ser fruto de años de permisos individuales; trasladarlo tal cual puede reproducir el desorden; una auditoría previa permite ajustarlo. Compruebe en la documentación actual cómo trata cada herramienta permisos y enlaces. Los enlaces guardados seguirán apuntando a Google hasta que alguien los actualice.Archivos nativos de Google y permisos de uso compartido
Documentos, Hojas de cálculo y Presentaciones de Google pueden convertirse o mantenerse como enlaces, y la elección afecta a cómo trabajará la gente después. Convertirlos genera archivos de Word, Excel y PowerPoint, pero el formato, las fórmulas y los complementos no siempre se conservan: pruebe las hojas más usadas. Dejarlos como enlaces los mantiene en Google, lo que choca con cerrarlo. Decida por tipo: convierta lo que seguirá editando, archive lo que solo se lee y deje fuera lo que nadie abre desde hace años.Chat, grupos, sitios y archivos históricos
Más allá del correo y los archivos están los elementos que se olvidan. El historial de chat puede no encajar en Teams como espera: decida si importa o si basta empezar de cero con una nota breve. Los Grupos de Google usados como listas de correo o buzones compartidos necesitan un equivalente en Microsoft 365, como un grupo o un buzón compartido. Google Sites suele no tener equivalente directo y puede haber que reconstruirlo. Los datos de archivo y retención exigen decidir si se exportan y se guardan en otro lugar.Comprobaciones posteriores y cierre de Google Workspace
El primer correo que llega a Microsoft 365 abre las comprobaciones; no cierra el proyecto. Valide buzones, calendarios, contactos y acceso a archivos con lo aprendido en el piloto. Acompañe de cerca a los usuarios las primeras semanas: habrá preguntas sobre inicio de sesión, móviles y dónde están los archivos. Antes de cancelar Google, configure bien el nuevo inquilino, con autenticación multifactor, gestión de dispositivos y una copia de seguridad probada, y compruebe la documentación actual para ver las opciones vigentes. Conserve el registro de su dominio, porque su correo depende de él, y acuerde qué datos de Google se archivan y durante cuánto tiempo. BlueNova IT puede ofrecer IT gestionada o cogestionada después, según se acuerde.Validar buzones, reglas y permisos
Compare buzones, calendarios y acceso a archivos con lo observado en el piloto y revise las reglas migradas, que pueden llegar desactivadas, antes de volver a activarlas. Abra buzones compartidos, grupos y calendarios como un usuario normal, no como administrador, y compruebe que los delegados conservan el acceso necesario y que nadie tiene el que no debe. Mire los reenvíos: reglas antiguas que apuntan a Google o a antiguos empleados pueden enviar el correo en círculos o a la persona equivocada. Anote qué comprobó y el resultado.Acompañar a los usuarios en las primeras semanas
Tras el cambio llegará un goteo de preguntas pequeñas: dónde está un archivo, por qué el móvil pide contraseña, cómo se abre un calendario compartido. Facilite las respuestas con una guía de una página basada en las preguntas del piloto, un único lugar donde preguntar y una persona con nombre que conteste. Las preguntas repetidas señalan algo que corregir en la guía. Confirme que la autenticación multifactor funciona en cada móvil y que el alta de dispositivos está completa, porque una configuración a medias se manifiesta como errores raros.Fijar una base de seguridad y de copias
Un inquilino nuevo es tan seguro como su configuración, y los valores por defecto no siempre son su política. Revise quién tiene roles de administrador, exija autenticación multifactor y decida qué dispositivos acceden a los datos; compruebe en la documentación actual de Microsoft qué opciones de seguridad incluyen sus licencias. Decida también cómo se hará la copia de seguridad: guardar datos en un servicio en la nube y tener una copia de recuperación separada y probada no es lo mismo. Nuestra guía de copias de seguridad y recuperación para empresas explica los objetivos de punto y tiempo de recuperación (RPO y RTO).Migrar con apoyo de un proveedor de IT
Trabaje con un proveedor externo, con su propio equipo de IT o con ambos: un plan de migración a Microsoft 365 funciona mejor cuando las responsabilidades están por escrito.- Liste qué quiere mover y qué dejar atrás.
- Designe a una persona de su lado para decidir y dar el visto bueno.
- Reparta el trabajo entre identidad, enrutamiento del correo, traslado de datos y soporte a usuarios.
- Acuerde quién revisa los resultados del piloto.
- Decida cómo se informará a los usuarios y quién responde a sus preguntas.
- Acuerde quién cubre las primeras semanas tras el cambio.
Qué acordar antes de empezar
Deje por escrito quién se ocupa de la identidad, el enrutamiento del correo, el traslado de datos, el soporte a usuarios y la aprobación final: muchos desacuerdos nacen de suponer que otro hacía una tarea. Sea concreto: quién crea las cuentas y asigna licencias, quién cambia el DNS y custodia esas credenciales, quién ejecuta la herramienta y lee sus informes, y quién decide pasar al siguiente lote. Añada los límites: qué entra en el alcance, qué se excluye, y qué no tocará el proveedor.Dónde ayuda la IT cogestionada
La IT cogestionada permite que su contacto interno de informática y un equipo externo compartan el trabajo. Resulta útil cuando alguien de su lado conoce el negocio y las aplicaciones pero no tiene tiempo para ejecutar la migración, o cuando necesita apoyo puntual en identidad, DNS o dispositivos. Reparta las tareas según quién tiene el conocimiento y las credenciales, y deje claro quién decide en cada punto. También puede seguir después del cambio, si lo desea y según se acuerde, para que el conocimiento no quede en una sola persona.Preguntas para un proveedor
Las buenas preguntas se centran en el alcance, los supuestos, las exclusiones y qué ocurre si algo no se traslada como se esperaba. Pregunte qué se incluye y qué queda a su cargo, qué supuestos sobre volumen de datos y número de usuarios sostienen la propuesta y qué pasa si cambian. Pregunte cómo se comunicará el proveedor durante el cambio, quién tendrá acceso de administrador y cómo se retira. Desconfíe de cualquier propuesta que prometa que todo se migra sin cambios o que fije plazos sin conocer su inventario.Migrar de Google Workspace a Microsoft 365 sale bien cuando el inventario, las decisiones sobre los datos y la rutina de soporte están resueltos antes de cambiar el enrutamiento del correo. Para los detalles de herramientas, límites y requisitos, consulte la documentación actual de Microsoft y de Google, porque cambian. Si no sabe por dónde empezar, empiece por un inventario sincero de cuentas, buzones, unidades, aplicaciones y dispositivos. Nuestro soporte es en inglés y español, de lunes a viernes, de 09:00 a 18:00 CET.Preguntas frecuentes
¿Cómo se migra de Google Workspace a Microsoft 365 paso a paso?
En la mayoría de los casos se hace un inventario de usuarios y datos, se prepara Microsoft 365 y el dominio, se ejecuta un piloto, se mueven los datos por lotes, se cambia el enrutamiento del correo y después se valida antes de dar de baja Google. Los pasos exactos dependen de la herramienta y de su entorno, por lo que conviene consultar la documentación actual de Microsoft.
¿Qué requisitos previos hay para migrar de Google Workspace a Microsoft 365?
Normalmente hacen falta permisos de administrador en ambas plataformas, un dominio verificado, usuarios creados y con licencia en Microsoft 365 y un plan para el enrutamiento del correo. Los requisitos varían según el método de migración y cambian con el tiempo, por lo que conviene confirmarlos en la documentación actual.
¿Qué pasa con los Documentos, Hojas de cálculo y Presentaciones de Google al migrar?
Según la herramienta, los archivos nativos de Google pueden convertirse a formatos de Office o mantenerse como enlaces, y cada opción tiene ventajas e inconvenientes en el formato y en la colaboración. Pruebe una muestra de sus propios archivos en el piloto antes de decidir.
¿Qué herramienta se puede usar para migrar de Google Workspace a Microsoft 365?
Microsoft ofrece opciones de migración en sus herramientas de administración y también existen herramientas de terceros. La elección depende de lo que haya que mover, por ejemplo solo el correo o también archivos y unidades compartidas. Compare lo que admite cada una con la documentación actual.
¿Se pierde el acceso al correo durante la migración?
No necesariamente. Un enfoque por fases permite seguir trabajando en Google mientras se copian los datos, y el cambio principal llega cuando se modifica el enrutamiento del correo. Cuánto se nota depende de la planificación, la comunicación y el volumen de datos.
