Transferir un dominio

5. Completar tareas previas a la transferencia

Tanto en el entorno de origen como en el de destino hay tareas que debes completar antes de que se pueda autorizar una transferencia de Google Workspace Domain Transfer.

Después de cada simulacro, el equipo de transferencia de dominio da unos resultados en los que se detallan qué tareas previas a la transferencia están pendientes y cómo se pueden resolver.

Después de hacer una prueba de funcionamiento, el equipo de transferencia de dominio informa de cualquier tarea de transferencia que sea necesaria.

Completar estas tareas antes de la transferencia

Mostrar todo  |  Ocultar todo

Paso 1: Tareas en el entorno de origen
  1. Actualiza las licencias (si procede): durante el proceso de transferencia no se trasladan licencias. Si el entorno de origen usa una edición de Google Workspace distinta a la del entorno de destino, debes actualizar el origen para que coincida con el destino. Para obtener más información, consulta cómo transferir las licencias en el apartado Tareas en el entorno de destino.

    Notas:

    • Puedes usar licencias de prueba o en periodo de gracia en el entorno de origen para la adquisición de licencias temporales y así poder evitar costes. Sin embargo, se debe tener en cuenta lo siguiente:
      • Estas licencias bloquean el proceso de cambio del dominio de servicio por el dominio principal. Cambia el dominio de servicio por el dominio principal antes de aprovisionar las licencias temporales.
      • Si las licencias disponibles en el entorno de destino son licencias completas, se asigna a los usuarios licencias completas como resultado de la transferencia.
    • Los usuarios del entorno de origen que no tienen ninguna licencia asignada se transfieren igualmente.
  2. Cancela las suscripciones de licencia no compatibles: cancelar suscripciones de licencia puede acarrear consecuencias. Los entornos de origen con Google Voice deben prestar especial atención a este paso. Consulta más información en el artículo Licencias de origen.
  3. Añade un dominio de servicio a Google Workspace (si procede): añade y verifica un nombre de dominio secundario nuevo en el entorno de origen que sustituya en algún momento al dominio principal. Si hay un dominio secundario y no es necesario transferirlo, puedes usarlo en vez de añadir otro. Consulta más información en el artículo Añadir un dominio de alias de usuario o un dominio secundario.
  4. Crea un administrador de servicio y conviértelo en el administrador principal de la cuenta: crea una cuenta de usuario asociada al dominio de servicio. Si reutilizas una cuenta antigua, comprueba que no hay otros dominios de transferencia vinculados a la cuenta como alias. Dale a este usuario el rol de superadministrador y conviértelo en el principal administrador de la cuenta. Tienes más información en el artículo Enviar notificaciones sobre la facturación y la cuenta a otro administrador.

    Nota: Asegúrate de que la verificación en dos pasos de Google no está activada en esta cuenta y que al menos has iniciado sesión una vez para verificar el acceso.

  5. Cambia el dominio principal por el de marcador de posición: cambia los dominios de forma que el dominio de marcador de posición pase a ser el nuevo dominio principal.

    Antes de cambiar tu dominio:

    Cuando lo tengas todo listo para cambiar, consulta el artículo Cambiar el dominio principal de Google Workspace.

    • Cancela todas las suscripciones de dispositivos, incluidas las de hardware de Google Meet, Chrome Enterprise y Jamboard.
    • Puede que algunas licencias no compatibles deban quitarse antes de hacer la transferencia. Consulta más información en el artículo Licencias de origen.
    • Si el entorno de origen tiene licencias de prueba, el cambio se bloqueará. Asegúrate de que el dominio se haya cambiado antes de que se aprovisionen licencias temporales.
    • Tenemos constancia de que, si se cambia el dominio principal y se usan dominios secundarios, pueden darse problemas. Lee nuestras alternativas a cambiar el dominio principal.
    • No cambies de nombre los grupos o usuarios de transferencia después de cambiar el nombre del dominio principal. Los usuarios y los grupos deben mantener sus dominios de transferencia.
    • Si configuras el SSO con un proveedor de identidades externo y utilizas una entidad emisora específica del dominio, la aserción de SAML cambiará para reflejar el dominio principal nuevo. Comprueba la configuración de tu proveedor de identidades para asegurarte de que los usuarios puedan autenticarse después de cambiar el dominio principal. Consulta más información en el artículo Requisitos de las aserciones de SSO.
  6. Crea reglas de conservación de Google Vault: crea reglas de conservación personalizadas indefinidas.

    Crea una regla para las siguientes aplicaciones:

    • Gmail: en Unidad organizativa, selecciona la unidad organizativa raíz.
    • Grupos de Google: en Grupos, selecciona Todos los grupos.

    Crea dos reglas para las siguientes aplicaciones:

    • Chat: selecciona Unidad organizativa y luego la unidad organizativa raíz. Como segunda regla, selecciona Todos los espacios de Chat.
    • Drive: selecciona Unidad organizativa y luego la unidad organizativa raíz. Como segunda regla, selecciona Todas las unidades compartidas.
    • Meet: selecciona Unidad organizativa y luego la unidad organizativa raíz y habilita la opción Incluir elementos de unidades compartidas. Como segunda regla, selecciona Todas las unidades compartidas.
    • Sites: selecciona Unidad organizativa y luego la unidad organizativa raíz y habilita la opción Incluir elementos de unidades compartidas. Como segunda regla, selecciona Todas las unidades compartidas.

    Además, las reglas de conservación personalizadas indefinidas se configuran en el entorno de destino antes de la transferencia. Consulta más información en el artículo Conservación indefinida de datos de Google Vault en el entorno de destino. Para obtener más información sobre la transferencia de Vault, consulta el artículo Transferir los datos de Vault con Domain Transfer.

  7. Actualizar el registro del marco de políticas del remitente (SPF) (si procede): si el entorno de destino usa una pasarela de salida que es distinta al entorno de origen, el entorno de origen debe actualizar su registro SPF para que incluya la pasarela de salida.

    Nota: Si utilizas DomainKeys Identified Mail (DKIM), la transferencia no debería afectar a tu política de autenticación basada en dominios para mensajes, informes y conformidad (DMARC). Aunque DKIM no alinee los dominios temporalmente, el registro SPF los seguirá alineando después de la transferencia. Asegúrate también de completar en el entorno de destino la tarea relativa a DKIM después de la transferencia.

  8. Resuelve conflictos entre recursos de calendario: si hay algún conflicto entre recursos de calendario, soluciónalos antes de continuar:
    • IDs de edificio: el ID de edificio del entorno de origen no puede ser el mismo que el del entorno de destino. Para evitar el bloqueo de transferencia, tienes dos opciones. Puedes eliminar el edificio del entorno de origen. También puedes hacer que los detalles de los dos edificios sean idénticos para combinar los edificios de origen y de destino. Para que los dos edificios sean idénticos, el ID, el nombre, todos los campos de la dirección, la descripción y la planta deben ser exactamente los mismos en ambos edificios.
    • Nombres de edificios: si el recurso de un edificio del entorno de origen tiene el mismo nombre que otro del entorno de destino, debes cambiar el de uno de los recursos para resolver el problema. Una vez que la transferencia se complete, puedes combinar los recursos de los dos edificios.
    • IDs de recursos: si un recurso del entorno de origen tiene el mismo ID que el recurso del destino, se genera un conflicto que no se puede resolver mediante el proceso de transferencia, y el recurso no se transfiere. Elimina uno de los recursos que entran en conflicto y vuelve a crearlo con un ID que no genere conflictos. Los recursos eliminados tardan 30 días en desaparecer por completo del sistema. Puedes esperar a que el recurso se elimine completamente o pedir al equipo de Domain Transfer que envíe una solicitud para eliminarlo manualmente.
  9. Evalúa el impacto que tendrá la transferencia en la organización asociada con Google Cloud (si procede): si se está usando Google Cloud, notifica a los administradores de ese entorno el posible impacto que Google Workspace Domain Transfer podría tener en Google Cloud. Si es necesario, incluye en este proceso a tu partner o a tus contactos de Google Cloud para que te ayuden a evaluar las consecuencias y te indiquen qué hay que hacer para remediarlas. El equipo de Google Workspace Domain Transfer no ofrece asistencia en los procesos de transferencia de dominio con Google Cloud.
  10. Habla con tu distribuidor de Google Workspace (si procede): infórmale de a qué hora está planeada la transferencia de dominio y pídele que no haga cambios en la cuenta (por ejemplo, actualizando sus suscripciones) mientras la transferencia esté en curso.
  11. Registra cualquier programa alfa o beta que el entorno de origen o destino estén utilizando (si procede): Google Workspace Domain Transfer no transfiere registros de programas alfa o beta que haya en el entorno de origen. Asimismo, el entorno de destino puede que tenga registros de los que dependa el entorno de origen. Para que los programas usen un entorno no registrado, se debe enviar una solicitud a esos programas, que deben aceptarla.

    Te recomendamos que te registres en los programas alfa o beta antes de transferir el dominio para que los usuarios de transferencia tengan las mismas funciones disponibles durante el proceso. No obstante, el proceso de registro puede llevar cierto tiempo y no se garantiza que se vaya a completar. Por lo tanto, aunque se recomienda, no es obligatorio.

  12. Para transferir dispositivos Chrome de activación automática, sigue estos pasos:
    1. En el entorno de origen, revoca el token de preaprovisionamiento y da de baja todos los dispositivos. Restablece el estado de fábrica del dispositivo.
    2. En el entorno de destino, crea un token de preaprovisionamiento.
    3. Facilita el nuevo token a tu partner de aprovisionamiento autorizado. Tu partner usa el token para preaprovisionar los dispositivos en el entorno de destino.

      Los dispositivos se registran cuando están conectados a Internet. El estado del dispositivo cambia a Aprovisionado.

    Consulta más información sobre la activación automática en el artículo Activación automática.

Paso 2: Tareas en el entorno de destino
  1. Durante el proceso de transferencia no se trasladan licencias, por lo que debes aprovisionar suficientes licencias libres de Google Workspace para admitir a todos los usuarios de transferencia. Al transferir usuarios, se les asigna en el entorno de destino el mismo conjunto de licencias que tenían en el entorno de origen. Por lo tanto, cuando se hace la transferencia debe haber suficientes licencias libres del mismo tipo en el entorno de destino.

    Si el entorno de destino usa una edición de Google Workspace distinta a la del entorno de origen, actualiza las licencias en el entorno de origen o de destino para asegurarte de que coinciden.

    Notas:

    • Google recomienda actualizar las licencias para evitar que se active el proceso de borrado de servicios (SWP).
    • Aprovisiona las licencias que falten para que haya varias suscripciones en el entorno de destino. Puedes cambiar las licencias de usuarios concretos a una edición superior o inferior después de la transferencia. Recuerda que la concesión de la Licencia de dominio parcial (LDP) no está disponible para todos los tipos de licencias.
    • Asegúrate de que hay suficientes licencias de reserva en el entorno de destino. Ten en cuenta la posibilidad de que se añadan usuarios a cada entorno de origen (por ejemplo, porque se contraten nuevos empleados) durante el proceso de transferencia. Si hay varias transferencias, también debes tener en cuenta el número total de usuarios de origen de todas ellas.
    • Los usuarios del entorno de origen que no tienen ninguna licencia asignada se transfieren igualmente. Monitoriza cómo se asignan licencias automáticamente en el entorno de destino para asegurarte de que estos usuarios no reciben ninguna licencia.
    • Google Workspace Domain Transfer no ofrece planes de facturación especiales de Google Workspace para cubrir la compra de licencias extra durante la transferencia. Si las licencias del entorno de origen están sujetas a un plan de facturación anual, se mantendrán activas y se cobrarán hasta que se termine el contrato. Se pueden usar licencias de prueba y de gracia, aunque solo en el entorno de origen, lo que puede ser útil durante este proceso. Consulta a tu representante de ventas o a tu gestor de cuentas si tienes alguna duda más sobre los planes de facturación de Google Workspace. 
  2. Cuando hay varias licencias, asegúrate de que estas se aplican correctamente a los usuarios de transferencia: algunas configuraciones en el entorno de destino pueden repercutir en la forma en que se asignan licencias a usuarios de transferencia. Esto puede hacer que los usuarios de la transferencia terminen con una licencia diferente a la esperada. Estas configuraciones incluyen la concesión automática de licencias y la anulación de licencias automáticas en organizaciones concretas.

    Para que no se den cambios de licencias inesperados durante la transferencia, sigue estos pasos:

    • Si en el ajuste "Concesión automática de licencias" del entorno de destino se ha seleccionado la opción "Desactivado para todos", o si el entorno de destino solo tiene un tipo de licencia, no necesitas hacer ningún cambio.
    • Si la configuración de la asignación automática de licencias del entorno de destino está activada para todos (por ejemplo, si se tienen licencias de Google Workspace), comprueba que la configuración de determinadas unidades organizativas prevalece sobre este ajuste. Selecciona en la unidad organizativa raíz de transferencia la opción "Desactivado" y no permitas que lo definido en sus unidades organizativas secundarias prevalezca sobre ella.
  3. Crea la unidad organizativa raíz de transferencia y, si quieres, recrea la estructura de la unidad organizativa del entorno de origen: crea una unidad organizativa que sirva de unidad organizativa superior de todos los usuarios de la transferencia. Una vez creada, tienes dos opciones:
    • No hacer nada: el proceso de Google Workspace Domain Transfer recrea la estructura de la unidad organizativa del entorno de origen en la nueva unidad organizativa raíz de transferencia. Para seguir este paso, selecciona la opción "No" en el ajuste sobre recrear la estructura de la unidad organizativa de antemano. Todos los nuevos usuarios de la transferencia pueden heredar políticas que apliques al nivel de la unidad organizativa raíz de la transferencia.
    • Recrea manualmente la estructura de la unidad organizativa del entorno de origen en la unidad organizativa raíz de transferencia: Google Workspace Domain Transfer comprueba que toda la estructura de la unidad organizativa del entorno de origen se ha replicado correctamente antes de continuar con la transferencia. Para seguir este paso, selecciona la opción "Sí" en el ajuste sobre recrear la estructura de la unidad organizativa de antemano. Esto resulta útil si quieres configurar distintas políticas en unidades organizativas secundarias diferentes.

      Nota: Google Workspace Domain Transfer solo comprueba la estructura de la unidad organizativa. Es tu responsabilidad asegurarte de que en las unidades organizativas están configuradas las políticas adecuadas.

  4. Selecciona las políticas y los ajustes adecuados que reflejen los requisitos del entorno de origen y de destino: las políticas y los ajustes del entorno de origen no se transfieren al entorno de destino. Además, después de que el proceso de transferencia se complete, solo se aplican las políticas y la configuración del entorno de destino a los usuarios de la transferencia y sus datos.

    Debes revisar las políticas y ajustes del entorno de destino, y compararlas con las del de origen. Esta acción incluye ajustes generales y específicos de la unidad organizativa raíz de transferencia para comprobar que cubren todos los usuarios y entidades de transferencia entrantes.

    A continuación, te ofrecemos una lista no exhaustiva de las políticas y ajustes que debes verificar al hacer la configuración. También debes hacer una auditoría completa de ambos entornos para asegurarte de que se han analizado todas las secciones importantes.

    • Habilitación de servicios (Activado/Desactivado): comprueba que los servicios que usas en el entorno de origen están activados en el entorno de destino y que la unidad organizativa raíz de transferencia se comporta como debería. Es especialmente importante cuando se usa Google Vault, ya que las reglas de Vault podrían no aplicarse si el servicio está desactivado.
    • Ajustes avanzados de Gmail y registros MX: revisa ajustes como el enrutamiento de correo, las reglas de cumplimento, la habilitación de IMAP, la delegación y Google Sync. Consulta más información en el artículo Activar Gmail con Google Workspace.
    • Gestión de contraseñas: revisa las políticas de contraseñas para asegurarte de que siguen los procedimientos de tu organización. Una vez que los usuarios de transferencia se muevan al entorno de destino, heredarán las políticas de gestión de contraseñas en el entorno de destino.
    • Verificación en dos pasos: controla si los usuarios pueden añadir la verificación en dos pasos a su cuenta, ya sea de forma opcional u obligatoria. Si hay usuarios que tienen activada la verificación en dos pasos y se les transfiere a un entorno o a una unidad organizativa de destino en los que la verificación en dos pasos está desactivada, sus nuevos administradores no podrán gestionarlos. En vez de eso, los administradores podrán transferir estos usuarios a una unidad organizativa distinta en la que la verificación en dos pasos esté activada para poder hacer cambios, o bien quitar la verificación en dos pasos de esas cuentas antes de hacer la transferencia.
    • Opciones para compartir: controla si los usuarios pueden compartir su contenido fuera de la organización. Si en el entorno de origen no se permite compartir contenido con usuarios externos, pero en el de destino sí, es posible que estos usuarios externos puedan acceder al contenido de la transferencia. Si en el entorno de origen se permite compartir contenido con usuarios externos de manera predeterminada, pero en el de destino no, es posible que los usuarios de tu organización no puedan acceder al contenido de la transferencia. Consulta más información sobre las opciones para compartir contenido en Google Drive, en la versión clásica de Google Sites y en Google Calendar.
    • Reglas de prevención de la pérdida de datos (DLP): monitoriza e impide que los usuarios compartan información confidencial con usuarios ajenos a tu organización. Cuando DLP impide que los usuarios compartan información en el entorno de origen, y el contenido se transfiere al entorno de destino sin haberse configurado ajustes de DLP, los usuarios del entorno de destino podrán compartir la información con usuarios ajenos a tu organización. Consulta más información sobre las reglas DLP de Gmail y de Drive.
    • Historial de chat: controla si el historial de chat está activado o desactivado, y si los usuarios pueden seleccionar que sea obligatorio en todos los chats o que sea el ajuste predeterminado. Si el entorno de origen permite que el historial de chat se active, pero el de destino obliga a que esté desactivado, el historial de chat se perderá. Si bien aparece que Google Chat no es compatible con las transferencias, los mensajes directos sí que se transferirán.
    • Países o regiones de datos: controla en qué ubicación geográfica específica se deben almacenar los datos migrados. Los usuarios de la transferencia que tengan que estar en una ubicación geográfica concreta deben tener esta política configurada adecuadamente en el entorno de destino para asegurarse de que sus datos no salgan inesperadamente del país o de la región definida para almacenarlos. Consulta más información en el artículo Regiones de datos: elegir la ubicación geográfica de los datos.
    • Aplicaciones poco seguras (también denominadas contraseñas de aplicación): si las aplicaciones poco seguras están activadas en el entorno de origen, pero desactivadas en el entorno de destino, la conexión con la aplicación que utiliza este tipo de aplicaciones caducará y se cerrará. El tiempo de espera varía según la aplicación, pero normalmente caduca a los 60 minutos. Las futuras solicitudes de acceso que haga la aplicación poco segura se bloquearán. Consulta más información en el artículo Controlar el acceso a aplicaciones menos seguras.
    • Permisos OAuth, el inicio de sesión único (SSO) mediante SAML, aplicaciones de confianza y extensiones de Chrome: los controles OAuth determinan el nivel de acceso a la API permitido a usuarios y a aplicaciones de terceros. El SSO mediante SAML, proporcionado por Google Workspace o implementado como una aplicación personalizada, permite que los usuarios aprovechen sus credenciales de Google Workspace para acceder a otras aplicaciones o servicios. Las aplicaciones de confianza determinan qué aplicaciones pueden instalar los usuarios desde el Marketplace de Google Workspace o desde Chrome Web Store, y qué aplicaciones pueden evitar las restricciones de OAuth. Consulta más información sobre cómo controlar aplicaciones internas y de terceros, SSO mediante SAML, aplicaciones de Marketplace de Google Workspace, y extensiones y aplicaciones de Chrome.
    • Delegación de todo el dominio: permite que las aplicaciones accedan a los datos de Google Workspace de los usuarios. Para asegurarte de que los clientes y los permisos funcionan correctamente, configura la delegación de todo el dominio en el entorno de destino antes de la transferencia.

    Importante: Si no se llegan a definir políticas y ajustes correctamente, puede que se produzca lo indicado a continuación.

    • Que tus datos se muestren de forma inesperada a usuarios ajenos a tu organización. Por ejemplo, puede pasar si el entorno de destino tiene unos ajustes más laxos que el entorno de origen.
    • Que se restrinja el acceso a datos que antes eran accesibles. Por ejemplo, puede pasar si el entorno de destino tiene unos ajustes más restrictivos que el entorno de origen.
  5. Aceptar acuerdos que rigen los datos que se transfieren: revisa la Adenda sobre Tratamiento de Datos (DPA), la cláusula contractual tipo y la adenda al contrato de colaboración empresarial (BAA) de conformidad con la ley HIPAA aplicables en el entorno de destino. Consulta más información en el artículo Cumplimiento de la privacidad y registros en Google Workspace y Cloud Identity.
  6. Activar Vault si se usaba en el entorno de origen: si el entorno de destino no usa Vault, pero el de origen sí, el primero debe activarlo.
  7. Habla con tu distribuidor de Google Workspace (si procede): infórmale de a qué hora está planeada la transferencia de dominio y pídele que no haga cambios en la cuenta (por ejemplo, actualizando sus suscripciones) mientras la transferencia esté en curso.
  8. Registra cualquier programa alfa o beta que el entorno de origen o destino estén utilizando (si procede): Google Workspace Domain Transfer no transfiere registros de programas alfa o beta que haya en el entorno de origen. Asimismo, el entorno de destino puede que tenga registros de los que dependa el entorno de origen. Para que los programas usen un entorno no registrado, se debe enviar una solicitud a esos programas, que deben aceptarla.

    Te recomendamos que te registres en los programas alfa o beta antes de transferir el dominio para que los usuarios de transferencia tengan las mismas funciones disponibles durante el proceso. No obstante, el proceso de registro puede llevar cierto tiempo y no se garantiza que se vaya a completar. Por lo tanto, aunque se recomienda, no es obligatorio.

Importante:

  • Al pasar licencias a una edición inferior, puede que se pierda el acceso a determinados servicios y funciones de Google Workspace. Lee detenidamente las diferencias entre las ediciones de Google Workspace y el impacto que puede tener pasar a usar una edición inferior o superior antes de hacer cualquier cambio. Más información sobre las ediciones de Google Workspace
  • Pasar a usar licencias de una edición inferior puede activar el proceso de borrado de servicios, lo que retrasará la transferencia hasta un máximo de 90 días.
Paso 3: Otras tareas y consideraciones
  • Gestión del cambio: ni el equipo de Google Workspace Domain Transfer ni el propio proceso de transferencia informan a los usuarios sobre la ejecución de la transferencia mientras está en curso. Los representantes de los entornos de origen y destino deberían notificar de antemano a los usuarios que se va a hacer un proceso de transferencia y en qué podría afectarles.

    Todas las acciones de los administradores del entorno de origen y de destino quedan bloqueadas durante la transferencia, incluido el acceso a la API y a la consola de administración de Google. Los representantes de los entornos de origen y de destino deberían enviar notificaciones a todos los superadministradores y a los administradores delegados de dominio antes de que se inicie la transferencia y una vez que se haya completado.

  • Dependencias externas: si utilizas Google Cloud Directory Sync (GCDS), GAM (una herramienta de línea de comando de terceros que utilizan los administradores de Google Workspace para gestionar ajustes de usuarios y dominios) o un proveedor de inicio de sesión único de terceros (SSO), debes analizar el efecto de la transferencia. Además, examina cómo afecta a tu sistema y al tiempo de la transferencia que el entorno de origen y el de destino se hayan combinado en un mismo entorno.
Conservación indefinida de datos de Google Vault en el entorno de destino

Google Workspace Domain Transfer configura reglas de conservación personalizadas indefinidas en el entorno de destino. No hace falta que los administradores del entorno de destino hagan nada.

El archivo de Vault de los usuarios de la transferencia se ha transferido, pero las reglas de conservación de Vault del entorno de origen no. Para que ningún dato de Vault esté en peligro durante y después de la transferencia, el proceso de transferencia crea las siguientes reglas de conservación de Vault en el entorno de destino antes de ejecutar cualquier acción de transferencia:

  • Gmail: regla de conservación personalizada indefinida (permiso: unidad organizativa raíz de transferencia).
  • Google Calendar: regla de conservación personalizada indefinida (permiso: unidad organizativa raíz de transferencia).
  • Google Chat: regla de conservación personalizada indefinida (permiso: mensajes directos a usuarios incluidos en la unidad organizativa raíz de transferencia, pero no a espacios).
  • Google Drive: regla de conservación personalizada indefinida, sin incluir unidades compartidas (permiso: unidad organizativa raíz de transferencia).
  • Grupos de Google: regla de conservación personalizada (permiso: unidad organizativa raíz). Conserva los datos de todos los grupos del entorno de destino, incluidos los que no forman parte de la transferencia.
  • Google Meet: requiere dos reglas de conservación personalizadas indefinidas:
    1. No se incluyen unidades compartidas (permiso: unidad organizativa raíz de transferencia).
    2. Se incluyen todas las unidades compartidas (permiso: unidad organizativa raíz)

      Conserva los datos de todas las unidades compartidas en el entorno de destino, incluidas aquellas que no forman parte de la transferencia.

  • Google Sites: requiere dos reglas de conservación personalizadas indefinidas.
    1. No se incluyen unidades compartidas (permiso: unidad organizativa raíz de transferencia).
    2. Se incluyen todas las unidades compartidas (permiso: unidad organizativa raíz)

      Conserva los datos de todas las unidades compartidas en el entorno de destino, incluidas aquellas que no forman parte de la transferencia.

  • Unidades compartidas: regla de conservación personalizada en todas las unidades compartidas (permiso: unidad organizativa raíz). Conserva los datos de todas las unidades compartidas en el entorno de destino, incluidas aquellas que no forman parte de la transferencia.

Importante: Las reglas de conservación de Vault del entorno de destino no se retiran ni se modifican durante la transferencia, ya que podría hacer que se perdieran datos de forma irreversible.

¿Te ha resultado útil esta información?

¿Cómo podemos mejorar esta página?
Búsqueda
Borrar búsqueda
Cerrar búsqueda
Menú principal
567174278817800928
true
Buscar en el Centro de ayuda
true
true
true
true
true
73010
false
false