5. Completa las tareas previas a la transferencia

Los entornos de origen y destino tienen sus propias tareas que debes completar antes de que se pueda autorizar una transferencia de dominio de Google Workspace.

Después de cada prueba, el equipo de Transferencia de dominio proporciona los resultados en los que se detallan las tareas previas a la transferencia pendientes y cómo se pueden resolver.

Completa estas tareas antes de la transferencia

Paso 1: Busca tareas

  1. Actualiza las licencias (si corresponde): Las licencias no se mueven como parte del proceso de transferencia. Si el entorno de origen usa una edición de Google Workspace diferente a la del entorno de destino, debes actualizar el origen para que coincida con el destino. Para obtener más información, revisa las transferencias de licencias en Tareas de destino.

    Notas:

    • Puedes usar licencias de prueba o de período de gracia en el entorno de origen para adquirir licencias de forma temporal y evitar costos. Sin embargo, ten en cuenta los siguientes puntos:
      • Estas licencias bloquean el proceso de intercambio de cualquier otro dominio por el dominio principal. Cambia el dominio principal antes de aprovisionar licencias temporales.
      • Si las licencias disponibles en el entorno de destino son licencias completas, a los usuarios se les asignarán licencias completas como resultado de la transferencia.
    • Los usuarios del entorno de origen a los que no se les asignaron licencias también se transfieren.
  2. Cancela suscripciones de licencias no admitidas: Es posible que cancelar suscripciones de licencias tenga implicaciones. Los entornos de origen con Google Voice deben prestar especial atención a este paso. Para obtener más información, consulta Licencias de fuentes.
  3. Agregar un dominio de marcador de posición a Google Workspace (si corresponde): Agrega y verifica un nuevo nombre de dominio secundario en el entorno de origen que, finalmente, reemplazará el dominio principal existente. Si existe un dominio secundario y no es necesario transferirlo, puedes usarlo. Para obtener más información, consulta Cómo agregar un dominio de alias de usuario o un dominio secundario.
  4. Crea un administrador de marcador de posición y conviértelo en el administrador principal de la cuenta: Crea una cuenta de usuario asociada al dominio de marcador de posición. Si reutilizas una cuenta anterior, asegúrate de que no haya otros dominios de transferencia existentes como alias adjuntos a la cuenta. Otorgarle a este usuario el rol de administrador avanzado y convertirlo en el administrador principal de la cuenta Para obtener más información, consulta Cómo enviar notificaciones de facturación y de la cuenta a otro administrador. Asegúrate de que la verificación en 2 pasos de Google esté configurada y accede al menos una vez para verificar el acceso con la cuenta de administrador de marcador de posición.
  5. Intercambia el dominio principal por el dominio marcador de posición: Realiza un intercambio de dominio y promueve el dominio marcador de posición como el nuevo dominio principal.

    Antes de intercambiar tu dominio, ten en cuenta lo siguiente:

    Cuando esté todo listo para el cambio, consulta Cómo cambiar tu dominio principal de Google Workspace.

    • Cancela todas las suscripciones a dispositivos, incluidas las de hardware de Google Meet y Chrome Enterprise.
    • Es posible que debas quitar algunas licencias no admitidas antes de la transferencia. Para obtener más información, consulta Licencias de fuentes.
    • Si el entorno de origen tiene licencias de prueba, se bloqueará el intercambio. Asegúrate de que el cambio se realice antes de que se aprovisionen las licencias temporales.
    • Cambiar el dominio principal y usar dominios secundarios tiene problemas conocidos. Revisa las alternativas para cambiar tu dominio principal.
    • No cambies el nombre de los usuarios de transferencia ni de los grupos después de cambiar el nombre del dominio principal. Los usuarios y los grupos deben permanecer en sus dominios de transferencia.
    • Si configuraste el SSO con un proveedor de identidad externo y usas una entidad emisora específica del dominio, la aserción SAML cambiará para reflejar el nuevo dominio principal. Verifica la configuración de tu proveedor de identidad para asegurarte de que los usuarios puedan autenticarse después del intercambio del dominio principal. Para obtener más información, consulta Requisitos de la aserción de SSO.
  6. Establece reglas de retención de Google Vault: Configura reglas de retenció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 2 reglas para las siguientes aplicaciones:

    • Chat: Selecciona Unidad organizativa y luegola unidad organizativa raíz. Para la segunda regla, selecciona Todos los espacios de Chat.
    • Drive: Selecciona Unidad organizativa y luegola unidad organizativa raíz. Para la segunda regla, selecciona Todas las unidades compartidas.
    • Meet: Selecciona Unidad organizativa y luego la unidad organizativa raíz y activa Incluir elementos de unidades compartidas. Para la segunda regla, selecciona Todas las unidades compartidas.
    • Sitios: Selecciona Unidad organizativa y luegola unidad organizativa raíz y activa Incluir elementos de unidades compartidas. Para la segunda regla, selecciona Todas las unidades compartidas.

    Además, antes de la transferencia, se configuran reglas de retención personalizadas indefinidas en el entorno de destino. Para obtener más información, consulta Retención indefinida de Google Vault en el entorno de destino. Para obtener más información sobre la transferencia desde Vault, consulta Transfiere tus datos de Vault con la transferencia de dominio.

  7. Actualiza tu registro de Sender Policy Framework (SPF) (si corresponde): Si el entorno de destino usa una puerta de enlace saliente diferente del entorno de origen, este último debe actualizar su registro de SPF para incluir la puerta de enlace saliente.

    Nota: Si usas DomainKeys Identified Mail (DKIM), la transferencia no debería afectar tu política de Autenticación de mensajes, informes y cumplimiento basados en el dominio (DMARC). El registro SPF seguirá alineándose después de la transferencia, incluso si el DKIM no lo hace temporalmente. Además, asegúrate de completar la tarea posterior a la transferencia de DKIM en el entorno de destino.

  8. Resuelve los conflictos de recursos de calendario: Si hay conflictos de recursos de calendario, resuélvelos antes de continuar:
    • IDs de edificios: Un ID de edificio en el entorno de origen no puede ser el mismo que un ID de edificio en el entorno de destino. Para omitir el bloqueo de transferencia, tienes 2 opciones. Puedes borrar el edificio en el entorno de origen. También puedes hacer que los detalles de los 2 edificios sean idénticos para combinar los edificios de origen y destino. Para que los 2 edificios sean idénticos, haz que el ID, el nombre, todos los campos de dirección, la descripción y el piso sean exactamente iguales para ambos edificios.
    • Nombres de edificios: Si un recurso de edificio en el entorno de origen tiene el mismo nombre que un recurso de edificio en el entorno de destino, debes cambiar el nombre de uno de los recursos para resolver el conflicto. Una vez que se complete el proceso de transferencia, podrás combinar los 2 recursos de compilación.
    • IDs de recursos: Un recurso en el entorno de origen que tiene el mismo ID de recurso que un recurso en el destino crea un conflicto que no se puede resolver con el proceso de transferencia, y el recurso no se transferirá. Borra uno de los recursos en conflicto y vuelve a crearlo con un ID que no genere conflictos. Un recurso borrado tarda 30 días en desaparecer por completo del sistema. Puedes esperar a que se borre el recurso por completo o el equipo de Transferencia de dominio puede enviar una solicitud para borrarlo de forma manual.
  9. Evalúa el impacto en la organización de Google Cloud asociada (si corresponde): Si se usa Google Cloud, notifica a los administradores de ese entorno sobre los posibles impactos que la transferencia de dominio de Google Workspace podría tener en Google Cloud. Si es necesario, involucra a tu socio de Google Cloud o a tus contactos en Google Cloud para que te ayuden a evaluar los impactos y los pasos de corrección. El equipo de Transferencia de dominios de Google Workspace no ofrece asistencia con Google Cloud durante una participación de transferencia de dominios.
  10. Notifica a tu revendedor de Google Workspace (si corresponde): Infórmale la hora planificada de la transferencia del dominio y pídele que no cambie la cuenta (por ejemplo, que no actualice las suscripciones) durante el período de transferencia.
  11. Inscríbete en los programas alfa o beta en los que participe el entorno de origen o destino (si corresponde): Las inscripciones en los programas alfa y beta no se transfieren en el entorno de origen. Del mismo modo, el entorno de origen puede depender de las inscripciones en el entorno de destino. El entorno no inscrito debe solicitar la participación en esos programas y ser aceptado para seguir usándolos.
    Te recomendamos que te inscribas en los programas alfa o beta antes de realizar la transferencia para que los usuarios que realicen la transferencia tengan las mismas funciones disponibles durante todo el proceso. Sin embargo, el proceso de inscripción puede tardar un tiempo y no se garantiza el éxito. Por lo tanto, se recomienda, pero no es obligatorio.

  12. Para transferir dispositivos inscritos con la inscripción automática de Chrome, haz lo siguiente:
    1. En el entorno de origen,revoca el token de aprovisionamiento previo existente y anula el aprovisionamiento de todos los dispositivos. Restablece los dispositivos a la configuración predeterminada de fábrica.
    2. En el entorno de destino, crea un token de aprovisionamiento previo nuevo.
    3. Proporciona el token nuevo a tu socio autorizado para el aprovisionamiento previo. Tu socio usa el token para aprovisionar previamente los dispositivos en el entorno de destino.

    Los dispositivos se inscriben automáticamente una vez que se conectan a Internet. El estado del dispositivo cambia a Provisioned.

    Para obtener más información sobre los dispositivos con inscripción automática, consulta Inscripción automática.

Paso 2: Tareas de destino

  1. Las licencias no se mueven como parte del proceso de transferencia, por lo que debes aprovisionar suficientes licencias de Google Workspace de repuesto para admitir a todos los usuarios de la transferencia: Cuando transfieres usuarios, se les asigna el mismo conjunto de licencias en el entorno de destino que tenían en el entorno de origen. Por lo tanto, debe haber suficientes licencias de repuesto del mismo tipo en el entorno de destino en el momento de la transferencia.

    Si el entorno de destino usa una edición de Google Workspace diferente a la del entorno de origen, asegúrate de que las licencias coincidan actualizándolas en el entorno de origen o de destino.

    Notas:

    • Google recomienda actualizar las licencias para evitar que se active el proceso de eliminación del servicio (SWP).
    • Aprovisiona las licencias faltantes para que existan varias suscripciones en el entorno de destino. De manera opcional, puedes actualizar o cambiar a una versión anterior las licencias de usuarios individuales después de la transferencia. Ten en cuenta que no todos los tipos de licencias admiten las licencias de dominio parciales (PDL).
    • Asegúrate de que haya suficientes licencias de repuesto disponibles en el entorno de destino. Considera si se agregan más usuarios (por ejemplo, nuevas contrataciones) a cada entorno de origen entre el inicio y el final del proceso de transferencia. Si hay varias transferencias, también debes tener en cuenta la cantidad total de usuarios de origen en todas las transferencias.
    • Los usuarios del entorno de origen a los que no se les asignaron licencias también se transfieren. Supervisa cómo se autoasignan las licencias en el entorno de destino para asegurarte de que estos usuarios no obtengan licencias.
    • La transferencia de dominio no ofrece planes de facturación especiales de Google Workspace para admitir la compra de licencias adicionales durante la transferencia. Si las licencias del entorno de origen están sujetas a un plan de facturación anual, permanecerán activas y se facturarán hasta el final del contrato del plan anual. Si tienes más preguntas sobre los planes de facturación de Google Workspace, consulta a tu representante de ventas o administrador de cuentas.
  2. Asegúrate de que las licencias se apliquen correctamente a los usuarios transferidos cuando existan varias licencias: Algunos parámetros de configuración del entorno de destino pueden afectar la forma en que se asignan las licencias a los usuarios transferidos.Esta situación puede hacer que los usuarios transferidos terminen con una licencia diferente a la esperada. Estas configuraciones incluyen las licencias automáticas y la anulación de licencias automáticas para organizaciones específicas.

    Para asegurarte de que no haya cambios inesperados en las licencias durante la transferencia, debes realizar las siguientes acciones:

    • Si la configuración de licencias automáticas del entorno de destino es "Desactivado para todos" o si el entorno de destino solo tiene un tipo de licencia, no se requieren cambios.
    • Si la configuración de licencias automáticas del entorno de destino es "Activada para todos" (por ejemplo, licencias de Google Workspace), asegúrate de que la anulación esté activada para unidades organizativas específicas. En el caso de la unidad organizativa raíz de la transferencia, asegúrate de que la configuración de licencias automáticas esté desactivada y de que no haya anulaciones adicionales para las unidades organizativas secundarias.
  3. Crea la unidad organizativa raíz de transferencia y, de manera opcional, vuelve a crear la estructura de la unidad organizativa del entorno de origen: Crea una unidad organizativa que sirva como unidad organizativa principal para todos los usuarios transferidos. Una vez que se cree, tendrás 2 opciones:

    • No hacer nada: El proceso de transferencia de dominio recrea la estructura de la unidad organizativa del entorno de origen en la nueva unidad organizativa raíz de transferencia. Para realizar este paso, establece la opción de transferencia "Recreate the organizational unit structure in advance" en No. Todos los usuarios transferidos entrantes heredan las políticas que aplicas a nivel de la unidad organizativa.
    • Vuelve a crear manualmente la estructura de la unidad organizativa del entorno de origen en la unidad organizativa raíz de transferencia: La transferencia de dominio garantiza que toda la estructura de la unidad organizativa del entorno de origen se replique correctamente antes de continuar con la transferencia. Para realizar este paso, establece la opción de transferencia "Recreate the organizational unit structure in advance" en Sí. Esta opción es útil si deseas establecer políticas distintas en diferentes unidades organizativas secundarias.

      Nota: La transferencia de dominio solo valida la estructura de la unidad organizativa. Es tu responsabilidad asegurarte de que se establezcan las políticas adecuadas en las unidades organizativas.

  4. Establece la configuración y las políticas adecuadas para reflejar los requisitos del entorno de origen y destino: La configuración y las políticas del entorno de origen no se transfieren al entorno de destino. Además, una vez que se complete el proceso de transferencia, solo se aplicarán las políticas y la configuración del entorno de destino a los usuarios transferidos y sus datos.

    Debes revisar tus políticas y parámetros de configuración en el entorno de destino y compararlos con los del entorno de origen. Esta acción incluye la configuración general y específica de la unidad organizativa raíz de transferencia para garantizar que abarque todas las entidades y los usuarios de transferencia entrantes.

    A continuación, se incluye una lista no exhaustiva de políticas y parámetros de configuración que debes verificar como parte del proceso de configuración. Además, realiza una auditoría completa de ambos entornos para asegurarte de que se analicen todas las secciones pertinentes:

    • Habilitación del servicio (activado/desactivado): Verifica 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 la transferencia se comporte según lo esperado. Esto es especialmente importante cuando se usa Google Vault, ya que es posible que las reglas de Vault no se apliquen si el servicio está desactivado.
    • Gmail, configuración avanzada y registros MX: Revisa la configuración, como el enrutamiento de correo electrónico, las reglas de cumplimiento, la habilitación y la delegación de IMAP. Para obtener más información, consulta Cómo activar Gmail con Google Workspace.
    • Administración de contraseñas: Revisa tus políticas de contraseñas para asegurarte de que se alineen con los procedimientos de tu organización. Una vez que los usuarios de transferencia se mueven al entorno de destino, heredan las políticas de administración de contraseñas de ese entorno.
    • Verificación en 2 pasos: Controla si los usuarios pueden agregar una configuración de verificación en 2 pasos a su cuenta, si se permite o si se aplica de manera forzosa. Si los usuarios de transferencia con la verificación en 2 pasos activada se transfieren a un entorno o unidad organizativa de destino en el que la verificación en 2 pasos está desactivada, los administradores de destino no podrán administrarlos. En cambio, los administradores pueden mover a estos usuarios a otra unidad organizativa en la que esté activada la Verificación en 2 pasos para realizar cambios, o bien pueden quitar la Verificación en 2 pasos de las cuentas antes de la transferencia.
    • Configuración de uso compartido: Controla si los usuarios pueden compartir su contenido fuera de la organización. Si el entorno de origen bloquea el uso compartido y el entorno de destino no lo hace, es posible que se pueda acceder al contenido de la transferencia fuera de tu organización. Si el entorno de origen tiene el uso compartido abierto de forma predeterminada y el entorno de destino no, es posible que los usuarios de tu organización no puedan acceder al contenido transferido. Obtén más información sobre las opciones de uso compartido de Google Drive y el Calendario de Google.
    • Reglas de prevención de pérdida de datos (DLP): Supervisan y evitan que los usuarios compartan información sensible fuera de tu organización. Cuando la DLP impide que los usuarios compartan información en el entorno de origen y el contenido se transfiere a un entorno de destino sin configuración de DLP, los usuarios del entorno de destino pueden compartir información fuera de tu organización. Obtén más información sobre las reglas de DLP de Gmail y las reglas de DLP de Drive.
    • Historial de chat: Controla si el historial de chat está activado o desactivado, y si los usuarios pueden establecer la aplicación de la política en todos los chats o establecerla como predeterminada. Si el entorno de origen permite activar el historial de chat, pero el entorno de destino lo obliga a estar desactivado, se perderá el historial de chat. Si bien Google Chat aparece como no compatible con la transferencia, los mensajes directos (MD) se transferirán.
    • Países o regiones de datos: Controla en qué ubicación geográfica específica se almacenarán tus datos migrados. Los usuarios que deban permanecer en una ubicación geográfica específica deben tener esta política configurada de forma adecuada en el entorno de destino para asegurarse de que sus datos no salgan de forma inesperada del país o la región de datos requeridos. Para obtener más información, consulta Regiones de datos: Elige una ubicación geográfica para tus datos.
    • Apps menos seguras (también conocidas como contraseñas de aplicación): Si las apps menos seguras están activadas en el entorno de origen y desactivadas en el entorno de destino, se agotará el tiempo de espera de la conexión con la aplicación que usa apps menos seguras y se cerrará. Los períodos de espera varían según la aplicación, pero suelen vencer en un plazo de 60 minutos. Se bloquean las solicitudes de acceso futuras que realice la aplicación no segura. Para obtener más información, consulta Cómo controlar el acceso a las apps menos seguras.
    • Permisos de OAuth, inicio de sesión único (SSO) para SAML, apps de confianza y extensiones de Chrome: Los controles de OAuth determinan el nivel de acceso a la API que se permite a los usuarios y las aplicaciones de terceros. El SSO para SAML, ya sea que lo proporcione Google Workspace o que se implemente como una aplicación personalizada, permite a los usuarios aprovechar sus credenciales de Google Workspace para acceder a otras aplicaciones o servicios. Las apps de confianza determinan qué aplicaciones pueden instalar los usuarios desde Google Workspace Marketplace o Chrome Web Store, y qué apps pueden omitir las restricciones de OAuth. Obtén más información para controlar las apps internas y de terceros, el SSO de SAML, las apps de Google Workspace Marketplace y las apps y extensiones de Chrome.
    • Delegación de todo el dominio: Permite que las apps accedan a los datos de Google Workspace de los usuarios. Para asegurarte de que los clientes y los permisos funcionen correctamente, configura la delegación en todo el dominio en el entorno de destino antes de la transferencia.

    Importante: Si no puedes establecer políticas y parámetros de configuración de forma adecuada, es posible que ocurra lo siguiente:

    • Exposición accidental de tus datos fuera de tu organización (por ejemplo, el entorno de destino tiene una configuración más abierta que el entorno de origen)
    • Acceso restringido a datos a los que se podía acceder anteriormente (por ejemplo, el entorno de destino tiene una configuración más restrictiva que el entorno de origen)
  5. Acepta los acuerdos que rigen los datos transferidos: Revisa la Enmienda de Tratamiento de Datos (DPA), la cláusula contractual modelo y la Enmienda de Socio Comercial de la HIPAA (BAA) en el entorno de destino. Para obtener más información, consulta Registros y cumplimiento de la privacidad para Google Workspace y Cloud Identity.
  6. Activa Vault si se usa en el entorno de origen: Si el entorno de destino no usa Vault, pero el entorno de origen sí, el entorno de destino debe activar Vault.
  7. Notifica a tu revendedor de Google Workspace (si corresponde): Infórmale la hora planificada de la transferencia del dominio y pídele que no cambie la cuenta (por ejemplo, que no actualice las suscripciones) durante el período de transferencia.
  8. Inscríbete en los programas alfa o beta en los que participe el entorno de origen o destino (si corresponde): Las inscripciones en los programas alfa y beta no se transfieren en el entorno de origen. Del mismo modo, el entorno de origen puede depender de las inscripciones en el entorno de destino. El entorno no inscrito debe solicitar la participación en esos programas y ser aceptado para seguir usándolos.
    Te recomendamos que te inscribas en los programas alfa o beta antes de realizar la transferencia para que los usuarios que realicen la transferencia tengan las mismas funciones disponibles durante todo el proceso. Sin embargo, el proceso de inscripción puede tardar un tiempo y no se garantiza el éxito. Por lo tanto, se recomienda, pero no es obligatorio.

Importante:

  • Si se disminuye la versión de las licencias, es posible que se pierdan servicios y funciones de Google Workspace. Revisa con atención las diferencias entre las ediciones de Google Workspace y el impacto de las actualizaciones y las versiones anteriores antes de realizar cualquier cambio. Obtén más información sobre las ediciones de Google Workspace.
  • Es posible que la degradación de licencias active el SWP, lo que puede retrasar una transferencia hasta por 90 días.

Paso 3: Otras tareas y consideraciones

  • Administración de cambios: Ni el equipo de Google Workspace Domain Transfer ni el proceso de transferencia proporcionan automáticamente a los usuarios información sobre la ejecución de la transferencia durante el proceso. Se recomienda que los representantes del entorno de origen y destino informen a los usuarios sobre el proceso de transferencia y sus posibles impactos con anticipación.

    Durante la transferencia, se bloquean todas las acciones de administrador en el entorno de origen y destino, incluido el acceso a la API y a la Consola del administrador de Google. Se recomienda que los representantes de los entornos de origen y destino notifiquen a todos los administradores avanzados y administradores delegados del dominio antes de la transferencia y una vez que se complete.

  • Dependencias externas: Si usas Google Cloud Directory Sync (GCDS), GAM (una herramienta de línea de comandos de terceros para que los administradores de Google Workspace administren la configuración del dominio y del usuario) o un proveedor externo de inicio de sesión único (SSO), asegúrate de analizar el efecto de la transferencia. También analiza cómo la coexistencia de los entornos de origen y destino en un solo entorno afecta tu sistema y los tiempos de ejecución de la transferencia.

Retención indefinida de Google Vault en el entorno de destino

Google Workspace Domain Transfer& establece reglas de retención personalizadas indefinidas en el entorno de destino. Los administradores del entorno de destino no deben realizar ninguna acción.

Se mueve el archivo de Vault para los usuarios de transferencia, pero no las reglas de retención de Vault del entorno de origen. Para asegurarte de que no se pongan en riesgo los datos de Vault durante la transferencia y después de ella, el proceso de transferencia crea las siguientes reglas de retención de Vault en el entorno de destino antes de ejecutar cualquier acción de transferencia:

  • Gmail: Regla de retención personalizada indefinida (alcance: unidad organizativa raíz de transferencia).
  • Calendario de Google: Regla de retención personalizada indefinida (alcance: unidad organizativa raíz de transferencia).
  • Google Chat: Regla de retención personalizada indefinida (alcance: mensajes directos con usuarios de transferencia en la unidad organizativa raíz de la transferencia, pero no en Espacios).
  • Google Drive: Regla de retención personalizada indefinida, que no incluye unidades compartidas (alcance: unidad organizativa raíz de transferencia).
  • Grupos de Google: Regla de retención personalizada indefinida (alcance: unidad organizativa raíz). Conserva los datos de todos los grupos en el entorno de destino, incluidos los que no se incluyen en el proceso de transferencia.
  • Google Meet: Requiere 2 reglas de retención personalizadas indefinidas:
    1. No se incluyen las unidades compartidas (el alcance es la unidad organizativa raíz de transferencia).
    2. Incluye todas las unidades compartidas (alcance: unidad organizativa raíz).

      Conserva los datos de todas las unidades compartidas en el entorno de destino, incluidas las que no se incluyen en el proceso de transferencia.

  • Google Sites: Se requieren 2 reglas de retención personalizadas indefinidas.
    1. No se incluyen las unidades compartidas (el alcance es la unidad organizativa raíz de transferencia).
    2. Incluye todas las unidades compartidas (alcance: unidad organizativa raíz).

      Conserva los datos de todas las unidades compartidas en el entorno de destino, incluidas las que no se incluyen en el proceso de transferencia.

  • Unidades compartidas: Regla de retención personalizada indefinida en todas las unidades compartidas (alcance: unidad organizativa raíz). Conserva los datos de todas las unidades compartidas en el entorno de destino, incluidas las que no se incluyen en el proceso de transferencia.

Importante: Las reglas de retención de Vault en el entorno de destino no se quitan ni se modifican durante el proceso de transferencia, ya que esto podría provocar una pérdida de datos irreversible.