Servicio de migración Tenant to Tenant Microsoft 365 para empresas
Una migración Tenant to Tenant de Microsoft 365 va mucho más allá de copiar buzones de correo de una organización a otra. En una migración real pueden intervenir Exchange Online, OneDrive, SharePoint, Microsoft Teams, usuarios, grupos, dominios, permisos, aplicaciones, licencias, identidad y diferentes configuraciones que mantienen conectados todos esos servicios.
En Kloudeal ayudamos a empresas que necesitan consolidar, separar o reorganizar sus entornos de Microsoft 365 a diseñar y ejecutar todo el proceso de migración de forma estructurada.
El trabajo comienza antes de mover el primer dato. Analizamos los tenants implicados, identificamos dependencias, definimos qué se puede migrar y qué necesita reconstrucción, seleccionamos la tecnología adecuada y preparamos un plan de ejecución que incluya piloto, premigraciones, cutover, transferencia de dominios y validación final.
El objetivo no es prometer que el cambio será invisible ni que dos tenants diferentes pueden convertirse en uno sin ninguna adaptación. El objetivo es reducir riesgos, anticipar incidencias y controlar el cambio para que usuarios y responsables de TI sepan qué ocurrirá en cada fase.
¿Qué incluye un proyecto Tenant to Tenant?
| Fase | Qué hacemos |
|---|---|
| Assessment | Analizamos usuarios, dominios, buzones, OneDrive, SharePoint, Teams, grupos, permisos y dependencias. |
| Diseño | Definimos tenant destino, identity mapping, coexistencia, herramientas, oleadas y estrategia de dominio. |
| Preparación | Configuramos los prerrequisitos necesarios en origen y destino antes de mover datos. |
| Piloto | Probamos la estrategia con usuarios y contenidos representativos. |
| Premigración | Cuando la tecnología lo permite, trasladamos por adelantado gran parte de los datos. |
| Cutover | Coordinamos las tareas finales, dominios, DNS, correo e identidad que deban realizarse durante el cambio. |
| Validación | Comprobamos que correo, documentos, permisos, Teams y servicios incluidos funcionan según el alcance. |
| Hypercare | Acompañamos al equipo de TI durante la estabilización posterior a la migración. |
¿Estás preparando una migración entre tenants?
Podemos revisar primero el alcance y decirte qué información necesitamos, qué puntos pueden complicar el proyecto y qué estrategia tendría más sentido antes de comprometer una herramienta o una fecha.
Hablar con un especialista en migraciones Microsoft 365Índice
- Qué es una migración Tenant to Tenant de Microsoft 365
- Cuándo necesita una empresa una migración entre tenants
- Qué podemos migrar
- Migración de Exchange Online
- Migración de OneDrive
- Migración de SharePoint Online
- Migración de Microsoft Teams
- Usuarios, grupos e identidad
- Dominios, UPN, DNS y correo
- Aplicaciones e integraciones
- Assessment previo
- Elección de la herramienta de migración
- Piloto y validación de la estrategia
- Premigración y sincronizaciones
- Ventana de cutover
- Coexistencia entre tenants
- Seguridad y cumplimiento
- Comunicación y experiencia de usuario
- Validación y soporte posterior
- Qué necesitamos para valorar una migración
- Cómo trabajamos en Kloudeal
- Preguntas frecuentes
- Documentación oficial
Qué es una migración Tenant to Tenant de Microsoft 365
Un tenant es el entorno lógico en el que una organización utiliza y administra Microsoft 365. Dentro de ese tenant se encuentran las identidades de Microsoft Entra ID, licencias, dominios y buena parte de los servicios que utiliza la empresa.
Cuando dos empresas operan en tenants distintos no basta con cambiar una configuración para fusionarlos. Los datos y servicios que deban permanecer en la organización resultante tienen que trasladarse o reconstruirse en el tenant destino.
Microsoft contempla expresamente este tipo de proyectos para escenarios como fusiones, adquisiciones, desinversiones, consolidaciones y reorganizaciones empresariales.
Referencia oficial: Microsoft – Plan a Microsoft 365 tenant-to-tenant migration.
Una migración no es una única operación
En la práctica, hablamos de varias migraciones relacionadas entre sí.
| Área | Ejemplo |
|---|---|
| Identidad | Relacionar usuario@empresa-a.com con su nueva identidad en el tenant destino. |
| Exchange | Trasladar buzones, calendarios y contenido de correo. |
| OneDrive | Mover los datos personales de cada usuario. |
| SharePoint | Migrar sitios, bibliotecas, documentos y permisos. |
| Teams | Reconstruir equipos, canales y los componentes incluidos en alcance. |
| Dominio | Liberar empresa.com del tenant origen y configurarlo en destino. |
| Aplicaciones | Actualizar SSO, OAuth, SCIM, Graph y sistemas que dependan del tenant anterior. |
El reto consiste en coordinar todas esas operaciones para que las dependencias se respeten.
Cuándo necesita una empresa migrar entre tenants
La mayoría de los proyectos aparecen como consecuencia de un cambio empresarial, no de una decisión puramente técnica.
Fusiones y adquisiciones
Cuando una empresa adquiere otra, mantener dos tenants indefinidamente suele aumentar la complejidad de administración, colaboración, seguridad y licenciamiento.
La migración permite integrar progresivamente a los usuarios de la empresa adquirida en el entorno corporativo de destino.
Carve-out o separación empresarial
El caso contrario ocurre cuando una división o compañía deja de formar parte de un grupo.
En este escenario hay que identificar qué usuarios, buzones, documentos, dominios y aplicaciones pertenecen realmente a la organización que se separa.
La dificultad suele estar menos en mover datos que en separar correctamente aquello que actualmente está compartido.
Consolidación de tenants
Empresas que han crecido mediante adquisiciones pueden terminar con varios tenants administrados de forma independiente.
Consolidarlos puede simplificar identidad, colaboración, gobierno y administración, aunque el proyecto debe analizar primero qué diferencias existen entre ellos.
Reorganizaciones internas
También puede ser necesario mover usuarios entre tenants por una reestructuración, una nueva estrategia corporativa o una centralización de servicios de TI.
Qué podemos migrar en una migración Microsoft 365
No existe un alcance universal. Antes de presupuestar o contratar licencias de migración necesitamos conocer qué utiliza realmente la organización.
| Workload | Qué puede formar parte del proyecto | Qué analizamos |
|---|---|---|
| Microsoft Entra ID | Usuarios, grupos, invitados y determinadas configuraciones asociadas. | Mapping, UPN, duplicados, sincronización, roles y aplicaciones. |
| Exchange Online | Buzones, Archive, calendario, contactos, shared mailboxes y recursos. | Tamaño, permisos, delegaciones, aliases, holds, conectores y mail flow. |
| OneDrive | Archivos personales y contenido compartido. | Volumen, propietarios, permisos, sharing, usuarios inactivos y retención. |
| SharePoint Online | Sitios, bibliotecas, archivos, metadata y permisos según tecnología. | Estructura, versiones, permisos únicos, invitados, apps y contenido obsoleto. |
| Microsoft Teams | Equipos, canales, archivos, miembros, conversaciones y otros componentes según herramienta. | Canales privados, shared channels, chats, Planner, apps e invitados. |
| Dominios | UPN, SMTP, dominio personalizado y DNS relacionado. | Dependencias, MX, SPF, DKIM, DMARC, aliases y aplicaciones. |
| Aplicaciones | Reconfiguración de integraciones incluidas en alcance. | SSO, SCIM, Graph, certificados, secretos y service principals. |
| Power Platform | Entornos y componentes cuando formen parte expresamente del proyecto. | Dataverse, conexiones, Power Apps, Power Automate y dependencias. |
Una de las primeras tareas del assessment consiste precisamente en transformar el concepto genérico de “migrar Microsoft 365” en un alcance concreto y verificable.
Migración de Exchange Online entre tenants
Exchange suele ser el workload más visible porque cualquier incidencia en correo afecta rápidamente al usuario.
Sin embargo, migrar Exchange no significa únicamente copiar mensajes.
Antes del cambio revisamos buzones principales, Online Archives, shared mailboxes, recursos, calendarios, contactos, aliases, reglas, delegaciones y aquellos sistemas que utilizan Exchange como plataforma de envío.
Buzones compartidos y delegaciones
Un buzón compartido puede migrarse correctamente y resultar inutilizable para el negocio si después nadie conserva el acceso previsto.
Por eso documentamos relaciones como:
| Permiso | Uso |
|---|---|
| Full Access | Permite abrir y trabajar con el buzón. |
| Send As | Permite enviar apareciendo como el buzón. |
| Send on Behalf | Permite enviar en nombre del buzón. |
| Calendar permissions | Controlan el acceso a calendarios compartidos. |
Migración nativa o herramienta especializada
Microsoft dispone actualmente de Cross-Tenant Mailbox Migration, basada en Exchange Online y MRS.
También podemos utilizar herramientas especializadas cuando el proyecto necesita otro modelo operativo, coexistencia, reporting unificado o combinación con otros workloads.
Referencia oficial: Microsoft – Cross-Tenant Mailbox Migration.
Migración de OneDrive entre tenants
OneDrive parece sencillo porque su contenido se presenta al usuario como carpetas y documentos. Sin embargo, también contiene permisos, enlaces compartidos y relaciones con otros servicios.
Un archivo de OneDrive puede estar enlazado desde un chat de Teams, compartido con un proveedor o utilizado como fuente de otro proceso.
Durante el assessment revisamos especialmente:
| Aspecto | Por qué importa |
|---|---|
| Volumen | Influye en tiempos y estrategia. |
| Sharing | Los documentos pueden depender de usuarios internos o externos. |
| Usuarios inactivos | Hay que decidir qué ocurre con sus datos. |
| Holds / Retention | Pueden modificar o bloquear determinados métodos de migración. |
| OneDrive no aprovisionados | Deben diferenciarse de usuarios con contenido real. |
Microsoft dispone actualmente de una migración cross-tenant nativa de OneDrive. Su comportamiento debe entenderse bien: Microsoft la define como una operación one-and-done, no como una herramienta de varias pasadas incrementales.
Después de un movimiento nativo correcto puede mantenerse una redirección desde la antigua ubicación mientras el tenant origen continúe disponible.
Referencia oficial: Microsoft – Cross-Tenant OneDrive Migration.
Migración de SharePoint Online entre tenants
SharePoint suele ser uno de los workloads donde más valor aporta un assessment previo.
Con los años, una organización puede acumular cientos de sitios, espacios sin propietario, contenido duplicado, permisos específicos y documentos que ya no deberían seguir formando parte del entorno operativo.
Trasladar todo sin revisarlo puede significar invertir tiempo y dinero para reconstruir en el tenant nuevo exactamente los mismos problemas del anterior.
No analizamos únicamente cuánto ocupa SharePoint
El volumen es importante, pero también lo es la estructura.
| Elemento | Qué necesitamos conocer |
|---|---|
| Sitios | Cuáles están activos y quién es responsable. |
| Bibliotecas | Estructura y volumen. |
| Versiones | Si deben conservarse y qué herramienta las soporta. |
| Metadata | Columnas, content types y taxonomías relevantes. |
| Permisos únicos | Si deben mantenerse o simplificarse. |
| Invitados | Qué accesos externos siguen siendo válidos. |
| Teams asociados | Qué sitios forman parte de Microsoft Teams. |
Microsoft dispone de una capacidad específica para Cross-Tenant SharePoint Migration, aunque dependiendo del entorno también puede resultar más adecuado utilizar una plataforma especializada.
Referencia oficial: Microsoft – Cross-Tenant SharePoint Migration.
¿No sabes cuántos sitios SharePoint o Teams tenéis realmente?
Podemos comenzar por un discovery para identificar volumen, propietarios, permisos, usuarios y complejidad antes de plantear la migración.
Solicitar análisis del entorno Microsoft 365Migración de Microsoft Teams entre tenants
Teams es uno de los componentes que más expectativas genera y uno de los que más conviene explicar antes de comenzar.
Un Team no es un único contenedor. Está relacionado con varios servicios Microsoft 365.
| Elemento de Teams | Servicio relacionado |
|---|---|
| Equipo y membresía | Microsoft 365 Groups y Microsoft Entra ID. |
| Archivos de canales | SharePoint Online. |
| Archivos compartidos por chat | OneDrive. |
| Reuniones | Teams y Exchange Online. |
| Apps y pestañas | Teams y servicios Microsoft o externos. |
| Planner | Servicio independiente conectado al grupo. |
Por eso, cuando un cliente nos pide “migrar Teams”, primero definimos qué significa exactamente.
El alcance puede distinguir entre equipos, canales estándar, canales privados, shared channels, archivos, publicaciones, chats 1:1, chats grupales, reuniones, Planner, pestañas, aplicaciones y usuarios invitados.
No todas las herramientas migran Teams de la misma manera
Las capacidades dependen de la tecnología utilizada y están cambiando con rapidez.
Microsoft está ampliando sus herramientas y APIs; Quest, ShareGate, BitTitan y Cloudiway también disponen de diferentes capacidades.
Por eso, antes de incluir un componente de Teams como parte contractual del proyecto, verificamos qué comportamiento puede ofrecer la herramienta seleccionada y lo probamos cuando sea necesario.
Usuarios, grupos e identidad: la base de toda la migración
Antes de trasladar datos necesitamos saber a qué identidad del tenant destino pertenece cada objeto.
Ese proceso se denomina habitualmente identity mapping.
Por ejemplo:
laura.gomez@empresa-antigua.com
puede convertirse en:
lgomez@empresa.com
El correo puede ser sencillo de relacionar manualmente, pero cuando multiplicamos el mismo problema por cientos de usuarios, permisos SharePoint, chats, grupos y documentos compartidos, un mapping incorrecto puede producir errores difíciles de corregir posteriormente.
Cloud-only e identidad híbrida
También necesitamos distinguir usuarios administrados únicamente desde Microsoft Entra ID de objetos sincronizados desde un Active Directory local.
En un entorno híbrido, determinados atributos siguen teniendo su origen de autoridad en Active Directory y deben modificarse respetando esa arquitectura.
Migración del dominio: UPN, correo y DNS
El dominio corporativo suele concentrar uno de los momentos más delicados del cutover.
Un dominio como empresa.com puede estar siendo utilizado simultáneamente como:
| Uso | Ejemplo |
|---|---|
| UPN | usuario@empresa.com |
| SMTP principal | usuario@empresa.com |
| Aliases | ventas@empresa.com |
| Aplicaciones | SSO o integraciones. |
| Correo de aplicaciones | ERP, CRM, web o ticketing. |
El mismo dominio personalizado exacto debe liberarse del tenant origen antes de poder verificarse en el nuevo tenant.
Eso obliga a retirar previamente las referencias que impidan su eliminación y a preparar usuarios y objetos con namespaces alternativos durante la transición.
DNS que revisamos durante el cambio
| Registro | Función |
|---|---|
| TXT | Verificación del dominio. |
| MX | Entrega del correo. |
| Autodiscover | Descubrimiento de servicios Exchange. |
| SPF | Fuentes autorizadas para enviar correo. |
| DKIM | Firma de mensajes desde Microsoft 365. |
| DMARC | Política y alineación de autenticación de correo. |
También identificamos aplicaciones que envían correo en nombre del dominio antes de cambiar SPF, DKIM o mail flow.
Aplicaciones, SSO e integraciones
Una migración puede haber trasladado correctamente todos los datos y, aun así, provocar una incidencia grave si una aplicación empresarial deja de autenticar.
Por eso el assessment no debería limitarse a Microsoft 365.
| Integración | Qué puede necesitar cambiar |
|---|---|
| SSO | Tenant, claims, usuarios o certificados. |
| SCIM | Endpoint, token y mappings. |
| Microsoft Graph | App Registration, tenant ID y permisos. |
| OAuth | Consentimientos, Client ID, secrets o certificados. |
| SMTP | Autenticación, relay y direcciones remitentes. |
| Backup | Nuevo tenant y permisos. |
| Seguridad | Integraciones, logs o service principals. |
No todas estas tareas tienen necesariamente que formar parte del alcance de migración, pero deben identificarse para saber quién será responsable de ellas antes del cutover.
Assessment: la fase que determina cómo será realmente la migración
Antes de seleccionar herramienta o fijar una fecha de cambio necesitamos entender el entorno.
El assessment transforma una petición como:
“Tenemos aproximadamente 300 usuarios y queremos pasar de un tenant a otro”
en un conjunto de datos que permite diseñar el proyecto.
| Área | Resultado que buscamos |
|---|---|
| Usuarios | Número real, estado, UPN y casos especiales. |
| Exchange | Buzones, tamaños, Archives, shared mailboxes y permisos. |
| OneDrive | Número de cuentas, volumen y sharing. |
| SharePoint | Sitios, almacenamiento, owners y complejidad. |
| Teams | Equipos, canales, chats y componentes adicionales. |
| Dominios | Dependencias y plan de transferencia. |
| Identidad | Cloud-only, híbrida y mapping destino. |
| Aplicaciones | Dependencias que podrían verse afectadas. |
Qué obtenemos después del assessment
Con esta información podemos definir de forma mucho más fiable:
alcance, herramienta, licencias, esfuerzo, orden de migración, estrategia de cutover y necesidades de coexistencia.
¿Tienes que preparar un presupuesto de migración?
Podemos revisar primero los datos básicos del entorno y ayudarte a determinar el alcance real antes de cerrar la arquitectura o adquirir licencias de migración.
Solicitar valoración de migración Tenant to TenantQué herramienta utilizamos para una migración Tenant to Tenant
No elegimos la herramienta antes de conocer el proyecto.
Las capacidades nativas de Microsoft han aumentado considerablemente y hoy existen diferentes caminos posibles para una migración entre tenants.
Herramientas nativas de Microsoft
Microsoft dispone de herramientas cross-tenant para Exchange Online, OneDrive y SharePoint, además de Microsoft 365 Migration Orchestrator para migraciones coordinadas de workloads soportados.
Estas opciones pueden resultar adecuadas cuando el alcance encaja con sus prerrequisitos y modelo operativo.
Referencia oficial: Microsoft – Microsoft 365 Migration Overview.
Quest On Demand Migration
Para proyectos multiworkload, Quest On Demand Migration es una de las plataformas que utilizamos habitualmente.
Quest permite trabajar desde una misma plataforma con discovery, account matching y diferentes workloads como Exchange, OneDrive, SharePoint, Teams y otros componentes según el alcance y el licenciamiento contratado.
Referencia oficial: Quest – On Demand Migration.
Otras plataformas
Dependiendo del escenario también podemos evaluar soluciones como ShareGate, BitTitan MigrationWiz o Cloudiway.
No existe una herramienta universalmente mejor. Una solución puede ser excelente para Exchange y no ser la más adecuada para Teams; otra puede ser especialmente potente en SharePoint pero no aportar ventajas en una migración sencilla de buzones.
PowerShell y Microsoft Graph
También utilizamos PowerShell y Microsoft Graph para tareas de discovery, preparación, automatización, mapping, configuración y validación cuando aportan valor al proyecto.
Estas tecnologías complementan las herramientas de migración; no tienen por qué sustituirlas.
Piloto: comprobar el diseño antes de migrar la organización
Un buen piloto no debe seleccionar únicamente los usuarios más fáciles.
Su objetivo es encontrar los problemas antes de que afecten a cientos de personas.
| Caso | Qué comprobamos |
|---|---|
| Buzón estándar | Proceso normal de Exchange. |
| Buzón grande | Rendimiento y tiempos. |
| Usuario con Archive | Tratamiento de archivo online. |
| Shared mailbox | Permisos y delegaciones. |
| OneDrive con sharing | Archivos y accesos compartidos. |
| SharePoint complejo | Permisos, metadata y contenido. |
| Team con canales privados | Estructura, miembros y SharePoint asociado. |
| Aplicación crítica | Impacto de identidad o tenant. |
El resultado del piloto puede confirmar la arquitectura original o hacer que modifiquemos mappings, oleadas, herramienta o procedimiento antes de continuar.
Premigración: mover antes todo lo que sea posible
Cuando la tecnología utilizada admite varias pasadas, intentamos reducir la cantidad de información pendiente para la ventana final.
Por ejemplo, puede copiarse gran parte de un buzón o repositorio varios días antes mientras los usuarios siguen trabajando en origen.
Después se realizan sincronizaciones posteriores para trasladar los cambios producidos desde la primera copia.
Este enfoque puede reducir la presión sobre el cutover, aunque no todos los métodos funcionan mediante deltas. Algunas capacidades nativas de Microsoft utilizan modelos de movimiento distintos.
La ventana de cutover
El cutover es el momento en el que se realizan las tareas que no podían completarse mientras los usuarios continuaban trabajando normalmente en el tenant origen.
No debería ser una sucesión de decisiones improvisadas.
Preparamos un runbook con secuencia, responsables y validaciones.
| Momento | Ejemplo de actuación |
|---|---|
| Antes de empezar | Validar jobs, usuarios, licencias y accesos administrativos. |
| Sincronización final | Procesar cambios pendientes cuando el método lo permita. |
| Identidad | Aplicar los cambios previstos de UPN o mapping. |
| Dominio | Liberar el dominio del tenant origen y verificarlo en destino. |
| Correo | Actualizar mail flow y DNS según la estrategia. |
| Aplicaciones | Activar o revisar configuraciones dependientes del nuevo tenant. |
| Validación | Ejecutar pruebas técnicas antes de dar el cambio por finalizado. |
Coexistencia cuando no todos los usuarios migran a la vez
En organizaciones medianas o grandes puede no ser viable migrar a todos los usuarios en una única ventana.
Durante varias semanas pueden existir personas trabajando en los dos tenants.
Microsoft recomienda planificar expresamente esta convivencia y contempla aspectos como mail routing, disponibilidad de calendario y comunicación entre usuarios de Teams.
La necesidad de coexistencia puede influir mucho en la herramienta y arquitectura elegidas.
Una migración de un fin de semana y una de seis meses no son el mismo proyecto
| Modelo | Necesidad de coexistencia |
|---|---|
| Cutover único | Baja o muy limitada. |
| Dos o tres oleadas | Media. |
| Migración de varios meses | Alta. |
| Carve-out gradual | Muy alta. |
Cuanto más larga sea la coexistencia, mayor importancia tienen la identidad, mail flow, calendarios y colaboración entre organizaciones.
Seguridad y cumplimiento durante una migración
La migración no debería convertirse en una excepción permanente a las políticas de seguridad.
Es posible que durante el proyecto necesitemos permisos administrativos o aplicaciones con acceso a varios workloads. Estos accesos deben estar documentados y revisarse cuando termine la migración.
Antes de migrar
Analizamos, dentro del alcance acordado, elementos como:
| Área | Qué revisamos |
|---|---|
| Roles | Cuentas administrativas necesarias. |
| MFA | Accesos administrativos y usuarios. |
| Conditional Access | Políticas que puedan interferir con migración o usuarios. |
| Apps de migración | Permisos y consentimientos requeridos. |
| Retention | Datos con políticas de conservación o holds. |
| Purview | Etiquetas, DLP y otros requisitos cuando formen parte del proyecto. |
| Acceso externo | Invitados y sharing relevante. |
Si existen requisitos jurídicos o regulatorios, deben revisarse antes de modificar retenciones o mover información.
La experiencia del usuario también forma parte de la migración
Para el usuario, la migración no consiste en mover objetos entre dos tenants.
Consiste en llegar al trabajo y descubrir si:
puede entrar, tiene correo, encuentra sus documentos y puede seguir colaborando.
Por eso preparamos junto con el equipo interno de TI la información que deben recibir los usuarios antes y después del cambio.
| Antes | Después |
|---|---|
| Fecha prevista. | Cómo iniciar sesión. |
| Servicios afectados. | Qué identidad utilizar. |
| Acciones que deben evitar. | Cómo acceder a Teams y OneDrive. |
| Posibles cambios. | Qué hacer ante una incidencia. |
| Canal de comunicación. | Contacto del equipo de soporte correspondiente. |
En migraciones donde existen cambios que afectan a aplicaciones locales, podemos proporcionar al equipo de TI las instrucciones y requisitos necesarios para que coordine las actuaciones con los usuarios.
Validación y soporte después de la migración
Una migración no termina cuando la consola muestra todos los jobs en verde.
El cierre requiere comprobar que el entorno funciona.
Validación técnica
| Área | Prueba |
|---|---|
| Microsoft Entra ID | Inicio de sesión, UPN, grupos y autenticación. |
| Exchange | Correo interno y externo, calendarios y shared mailboxes. |
| DNS | MX, SPF, DKIM, DMARC y configuración relacionada. |
| OneDrive | Contenido y acceso. |
| SharePoint | Sitios, datos y permisos. |
| Teams | Equipos, canales y componentes incluidos. |
| Aplicaciones | Integraciones incluidas en la validación. |
Validación funcional
También recomendamos que usuarios clave de cada área comprueben sus procesos habituales.
Un administrador puede verificar que los archivos están en SharePoint, pero el responsable del departamento sabe si son los archivos correctos y si su equipo puede acceder a ellos.
Hypercare
Después del cambio pueden aparecer incidencias que no justifican revertir una migración pero sí necesitan atención: permisos, accesos, enlaces, delegaciones o aplicaciones.
Por eso contemplamos una fase de estabilización posterior acorde al proyecto.
Qué información necesitamos para valorar una migración
No es necesario disponer de un inventario técnico perfecto para contactar con nosotros.
Con algunos datos básicos podemos comenzar a estimar el alcance y pedir posteriormente la información que falte.
| Dato | Ejemplo |
|---|---|
| Número de usuarios | 250 usuarios. |
| Buzones compartidos | 18 shared mailboxes. |
| OneDrive | 250 usuarios / aproximadamente 3 TB. |
| SharePoint | 25 sitios. |
| SharePoint asociado a Teams | 15 Teams. |
| Microsoft Teams | Número de equipos y necesidad de conversaciones/chats. |
| Dominios | empresa.com, filial.com. |
| Identidad | Cloud-only o sincronizada con Active Directory. |
| Aplicaciones críticas | ERP, RRHH, CRM, backup, SSO. |
| Fecha objetivo | Cutover previsto o plazo aproximado. |
A partir de esta información podemos determinar qué puntos necesitan un assessment más detallado y preparar una propuesta adaptada al proyecto.
¿Quieres que valoremos vuestra migración?
Envíanos el número aproximado de usuarios, buzones, OneDrive, SharePoint, Teams, dominios y la fecha objetivo. Revisaremos el escenario y podremos indicarte qué información adicional necesitamos para preparar el alcance.
Solicitar valoración Tenant to TenantCómo abordamos una migración Microsoft 365 en Kloudeal
No planteamos el proyecto empezando por el botón que hay que pulsar en la herramienta. Primero necesitamos entender cómo funciona el entorno y cómo debe quedar después.
La herramienta se adapta al proyecto
No todos los clientes necesitan la misma tecnología. Podemos utilizar capacidades nativas de Microsoft o plataformas especializadas en función de los workloads y de las necesidades reales.
Definimos el alcance antes de ejecutar
Explicamos qué se migrará, qué componentes requieren tratamiento específico y qué elementos quedan fuera del proyecto.
Esto evita descubrir durante el cutover que “migrar Teams” significaba una cosa diferente para cada parte.
Trabajamos con pilotos y validaciones
Preferimos descubrir una limitación durante un piloto controlado y no cuando ya se han migrado cientos de usuarios.
Coordinamos los workloads
Exchange, OneDrive, SharePoint, Teams, identidad y dominio no deberían convertirse en proyectos independientes que coinciden casualmente el mismo día.
Los tratamos como componentes de una única migración.
El objetivo es dejar un entorno administrable
La migración también es una oportunidad para corregir objetos obsoletos, permisos innecesarios y estructuras que ya no tienen sentido.
Cuando el alcance lo permite, intentamos que el tenant destino no sea simplemente una copia de todos los problemas históricos del origen.
Preguntas frecuentes sobre nuestro servicio de migración Tenant to Tenant Microsoft 365
Es el proceso de trasladar usuarios, datos o servicios desde un tenant de Microsoft 365 a otro.
Puede incluir Exchange Online, OneDrive, SharePoint, Microsoft Teams, dominios, usuarios, grupos, permisos y determinadas aplicaciones o configuraciones.
Es habitual en fusiones y adquisiciones, carve-outs, separaciones empresariales, consolidación de tenants y reorganizaciones internas.
Sí.
No es necesario trasladar toda la organización. El proyecto puede limitarse a un conjunto de usuarios, una unidad de negocio, determinados dominios o workloads concretos.
Sí.
El alcance puede incluir buzones de usuario, Online Archives, shared mailboxes, calendarios, contactos y otros componentes según la herramienta y el diseño seleccionado.
Pueden incluirse.
Además del contenido, revisamos permisos y delegaciones relevantes como Full Access, Send As y Send on Behalf.
Sí.
Podemos utilizar herramientas especializadas o capacidades nativas de Microsoft según el escenario.
Antes revisamos volumen, usuarios, sharing, retención y estrategia de migración.
Sí.
La migración puede incluir sitios, bibliotecas, documentos, versiones, metadata y permisos según la tecnología utilizada y el alcance contratado.
Sí, pero Teams necesita una definición de alcance más detallada porque depende de SharePoint, OneDrive, Exchange, grupos e identidad.
Debemos especificar qué ocurrirá con equipos, canales, conversaciones, chats, archivos, Planner, invitados y aplicaciones.
Existen actualmente herramientas y APIs capaces de tratar diferentes tipos de chats, pero el resultado depende de la tecnología y del tipo de conversación.
Por eso lo validamos antes de comprometer el alcance.
No deberían darse por migrados automáticamente.
Son componentes o servicios relacionados que deben revisarse de forma específica y pueden necesitar migración, reinstalación o reconfiguración.
El dominio personalizado debe liberarse del tenant origen antes de quedar verificado en el destino.
Antes hay que retirar las dependencias que lo utilizan y preparar UPN, aliases, Exchange, aplicaciones y DNS para la ventana de cambio.
Podemos incluir dentro del proyecto la planificación y ejecución de los cambios DNS relacionados con Microsoft 365 cuando tengamos acceso y estén dentro del alcance acordado.
Normalmente se revisan registros como MX, TXT, Autodiscover, SPF, DKIM y DMARC.
Depende de la arquitectura de identidad y de cómo se preparen las cuentas de destino.
Este punto debe definirse durante el diseño de identidad y comunicarse antes del cutover.
La migración debe analizarse como un entorno híbrido.
UPN, proxyAddresses y otros atributos pueden seguir teniendo su origen de autoridad en Active Directory, por lo que no deben tratarse como usuarios puramente cloud.
Depende del proyecto.
Podemos utilizar tecnologías nativas de Microsoft y herramientas especializadas como Quest On Demand Migration, ShareGate, BitTitan o Cloudiway, además de PowerShell y Microsoft Graph para determinadas tareas.
Sí. Quest On Demand Migration es una de las herramientas que podemos utilizar para proyectos Microsoft 365 tenant-to-tenant, especialmente cuando existen varios workloads.
Sí.
Microsoft dispone actualmente de herramientas cross-tenant para Exchange Online, OneDrive y SharePoint y de Microsoft 365 Migration Orchestrator para migraciones coordinadas de workloads compatibles.
No debe interpretarse como un botón que traslada automáticamente todo Microsoft 365.
Microsoft soporta determinados workloads y existen otros elementos que necesitan herramientas o estrategias específicas.
En muchos escenarios sí.
Las herramientas que soportan migraciones incrementales permiten trasladar una parte importante del contenido antes del cambio final y procesar posteriormente los datos nuevos o modificados.
No todos los métodos funcionan mediante deltas.
Sí.
En proyectos medianos o grandes es habitual trabajar por oleadas agrupadas por departamento, país, unidad de negocio o dependencia funcional.
Sí puede diseñarse una fase de coexistencia.
Dependiendo de la duración pueden necesitarse mail routing, disponibilidad de calendarios, colaboración entre tenants y otras configuraciones temporales.
Trabajamos para minimizar el impacto, pero no es prudente garantizar interrupción cero en todos los escenarios.
Dominio, DNS, identidad, Exchange, aplicaciones y autenticación pueden requerir una ventana de transición.
No sería una promesa realista.
Microsoft 365 contiene objetos y relaciones que pueden comportarse de forma distinta en el tenant destino y cada herramienta tiene sus propias capacidades y limitaciones.
Lo que hacemos es definir de antemano qué se conserva, qué cambia y cómo se validará.
En proyectos que lo requieren recomendamos realizar un piloto con usuarios y datos representativos.
Nos permite validar mapping, tiempos, permisos, herramienta y experiencia de usuario antes de la ejecución masiva.
Deben inventariarse y revisarse.
Aplicaciones que utilizan Microsoft Entra ID, Microsoft Graph, SSO, SCIM, SMTP u OAuth pueden necesitar una nueva configuración en el tenant destino.
No todas las políticas se trasladan automáticamente con los datos.
El tenant destino debe prepararse con la configuración de seguridad prevista para la organización y deben revisarse aspectos como MFA, Conditional Access, roles y aplicaciones.
Deben revisarse antes de elegir el método de migración.
Determinadas políticas de hold o retención pueden afectar o incluso bloquear algunos procedimientos nativos.
No deberían modificarse sin evaluar primero el motivo legal o de cumplimiento por el que existen.
No existe una duración estándar.
Depende del número de usuarios, volumen, workloads, aplicaciones, herramientas, coexistencia y ventana de cutover.
El assessment y el piloto permiten realizar una estimación mucho más fiable que utilizar únicamente el número de usuarios.
El precio depende fundamentalmente del número de objetos y de los servicios incluidos.
Para preparar una valoración necesitamos conocer usuarios, buzones, OneDrive, SharePoint, Teams, dominios y cualquier requisito especial.
La propuesta debe indicar expresamente qué herramientas se utilizarán y cómo se incluyen sus licencias.
También revisamos las licencias Microsoft necesarias para el tenant destino y para determinadas capacidades nativas de migración cuando corresponda.
Sí.
Podemos asumir la parte especializada de la migración y coordinarnos con vuestro equipo interno para identidad, aplicaciones, comunicaciones, DNS u otras tareas que dependan de la organización.
Como punto de partida necesitamos conocer el número aproximado de usuarios, buzones compartidos, OneDrive, sitios SharePoint, Teams, dominios, identidad, aplicaciones relevantes y fecha objetivo.
Si hay información que todavía no conocéis, podemos ayudar a obtenerla durante el assessment.
Conclusión: una migración Tenant to Tenant empieza mucho antes del cutover
Una migración entre tenants de Microsoft 365 no debería reducirse a elegir una herramienta y comenzar a copiar datos.
El resultado depende de entender previamente usuarios, identidades, dominios, buzones, OneDrive, SharePoint, Teams, permisos, aplicaciones y requisitos de negocio.
Después hay que decidir qué tecnología utilizar, cómo se relacionarán las identidades, qué puede premigrarse, qué debe ejecutarse durante el cutover y cómo se validará que la organización puede seguir trabajando desde el nuevo tenant.
Microsoft dispone actualmente de más opciones nativas para tenant-to-tenant que hace unos años, incluyendo migraciones específicas para Exchange, OneDrive y SharePoint y un Migration Orchestrator para workloads compatibles. Las plataformas especializadas siguen teniendo un papel importante cuando el proyecto requiere otras capacidades, mayor flexibilidad o una gestión multiworkload diferente.
En Kloudeal planteamos el proyecto desde el alcance y la arquitectura, no desde la herramienta. Esto permite seleccionar la tecnología que mejor encaje en cada caso y preparar una migración con responsabilidades, pasos y criterios de validación claros.
¿Necesitas migrar de un tenant Microsoft 365 a otro?
Cuéntanos brevemente vuestro escenario: usuarios, buzones, OneDrive, SharePoint, Teams, dominios y fecha objetivo.
Podemos ayudarte con el assessment, diseño, herramientas de migración, Exchange Online, OneDrive, SharePoint, Microsoft Teams, dominios, permisos, identity mapping, cutover, validación y soporte posterior.
Solicitar valoración de mi migración Microsoft 365Documentación oficial recomendada
Planificación de migraciones Microsoft 365
- Microsoft – Microsoft 365 Migration Overview
- Microsoft – Plan a Microsoft 365 Tenant-to-Tenant Migration