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 desinversión por transferencia de dominio de Google Workspace.

Después de cada prueba, el equipo de desinversión de la transferencia de dominio de Google Workspace proporciona resultados que detallan qué tareas previas a la transferencia están 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 las suscripciones a licencias no admitidas: En algunos casos, debes quitar las licencias no admitidas de los usuarios de la transferencia, mientras que los usuarios que no se transfieren pueden conservar sus licencias. De lo contrario, debes cancelar o quitar por completo todas las licencias no admitidas. La simulación valida qué licencias debes cancelar.

    Debes cancelar Google Voice para todos los usuarios. La cancelación de suscripciones a licencias puede tener consecuencias. Los entornos de origen con Google Voice deben prestar atención a este paso. Para obtener más información, consulta Licencias de fuentes.

  3. Asigna un nuevo dominio principal si deseas transferir el dominio principal actual: Este paso solo es obligatorio si deseas transferir tu dominio principal actual. Realiza un intercambio de dominios y promueve cualquier otro dominio como el nuevo dominio principal .Para este propósito, se puede promover cualquier dominio que no sea de transferencia como dominio principal.

    Antes de intercambiar tu dominio, haz 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 o grupos de transferencia 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.
  4. 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.

  5. Crea una copia de seguridad de los artefactos de Vault y quita las referencias a las entidades de transferencia: Descarga y crea una copia de seguridad de los informes y la configuración de Vault para las entidades de transferencia, ya que es posible que no se pueda acceder a ellos en el entorno de origen después de la transferencia. Esta información incluye asuntos, conservaciones, búsquedas y exportaciones.

    Después de la copia de seguridad, quita las referencias a las entidades de transferencia de los artefactos de Google Vault. Vault devuelve errores y es posible que no se pueda acceder a él si algún artefacto de Vault contiene referencias a las entidades de transferencia.

    • Las retenciones y conservaciones no aplican las conservaciones con errores en las entidades de transferencia.
    • Quita todas las referencias a los usuarios, los grupos y las unidades compartidas de transferencia de los asuntos, las listas compartidas, las retenciones y las reglas de retención. Vault no permite que se aplique una retención de Vault en un arrendatario que haga referencia a una entidad en el otro arrendatario.
    • Para conservar las retenciones de los datos de los usuarios que se transfieren en el arrendatario de origen, los administradores deben crear un nuevo usuario que no se transfiera y copiar todos los datos de Gmail y Drive de los usuarios que se transfieren y que están en espera al nuevo usuario. Luego, archiva los usuarios nuevos que no son de transferencia y asegúrate de que pertenezcan a un dominio que no es de transferencia. En su lugar, crea bloqueos equivalentes de Vault en el nuevo usuario no transferible y quita los bloqueos del usuario transferible original.
    • Para conservar las retenciones de los datos del usuario transferidos en el arrendatario de destino, usa las copias de seguridad para agregar retenciones equivalentes en el arrendatario de destino después de la transferencia.
    • No es necesario que quites las referencias indirectas. Las referencias indirectas se relacionan con una unidad organizativa que contiene un usuario de transferencia.
    • No es necesario que quites las referencias en las búsquedas y exportaciones completadas. Se descargan estas referencias.
  6. Actualiza tu registro de Sender Policy Framework (SPF) (si corresponde): Si el entorno de destino usa una puerta de enlace saliente diferente de la 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.

  7. 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 desinversión de 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 desinversión de la transferencia de dominios de Google Workspace no ofrece asistencia con Google Cloud durante una participación en la transferencia de dominios.
  8. 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.
  9. 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.

  10. 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.

  11. Actualizar la membresía del grupo: Quita todos los usuarios y grupos de transferencia de los grupos que no son de transferencia, y quita todos los usuarios y grupos que no son de transferencia de los grupos de transferencia. Por ejemplo, quita user@to-stay-insource.com y group@to-stay-insource.com de group@to-be-transfer.com.

    Nota: Este paso es opcional, ya que puedes hacer referencia a usuarios y grupos externos dentro de otros grupos. Considera las implicaciones de administrar grupos mientras otro arrendatario administra grupos de miembros y usuarios

  12. Quita los usuarios y grupos de transferencia de los públicos objetivo: Los públicos objetivo no se transfieren, por lo que el administrador de destino no tiene control sobre los públicos objetivo del entorno de origen después de la transferencia.

    Nota: Este paso es opcional, ya que los públicos objetivos permiten referencias a usuarios y grupos externos. Los usuarios conservan el acceso a los documentos que se compartieron con públicos objetivo.

  13. Actualiza las políticas basadas en grupos: Debes quitar todas las políticas basadas en grupos que hagan referencia a grupos de transferencia del arrendatario de origen.

    Importante: Si el arrendatario de origen contiene políticas basadas en grupos que hacen referencia a grupos de transferencia, la política basada en grupos desaparecerá de la Consola del administrador y no se podrá editar. Aún está vigente para los usuarios que no se transfirieron en el grupo de transferencia, pero no puedes verlo ni editarlo. Este es otro motivo para quitar los grupos entre múltiples arrendatarios en el paso 12.

  14. Establece la administración de dispositivos móviles como Básica: Anula el aprovisionamiento de la administración de dispositivos móviles para los usuarios de transferencia o configúrala como Básica.

  15. Directorios personalizados: Hay un problema conocido con los directorios personalizados. Los directorios personalizados no se transfieren, y debes quitar todos los grupos de transferencia antes de la transferencia.

    Importante: Si no quitas los grupos de transferencia, el directorio no se podrá editar ni borrar, y su comportamiento podría ser incoherente.

  16. Actualiza la membresía de la unidad organizativa: Asegúrate de que ninguna unidad organizativa del entorno de origen tenga tanto Transfer User como Non Transfer User. Los usuarios de transferencia y los usuarios que no son de transferencia deben estar en unidades separadas y no se pueden mezclar en una unidad en el entorno de origen.

  17. Actualiza las licencias automáticas: En el caso de las unidades organizativas que contienen usuarios de transferencia, asegúrate de que la configuración de licencias automáticas esté desactivada.

Paso 2: Tareas de destino

  1. Crea un entorno de destino: La desinversión de Google Workspace Domain Transfer no creará automáticamente un entorno de destino de Google Workspace. Debes crear uno con anticipación. Asegúrate de configurar la facturación y verificar un nombre de dominio principal en el entorno de destino.
  2. 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 adaptarse a 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.
  3. 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.
  4. 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 lo crees, 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.

  5. Establece la configuración y las políticas adecuadas para reflejar los requisitos del entorno de origen y destino: Las políticas y la configuración 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 entrantes de la transferencia.

    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 Activa 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 la DLP de Gmail y las reglas de la 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 almacenan los 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 inesperadamente 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 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)
  6. 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 Cumplimiento y registros de privacidad para Google Workspace y Cloud Identity.
  7. 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.
  8. 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.
  9. 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. Antes de realizar cualquier cambio, revisa con atención las diferencias entre las ediciones de Google Workspace y el impacto de actualizar o cambiar a una versión anterior. Obtén más información sobre las ediciones de Google Workspace.
  • La degradación de licencias puede activar 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.

    Todas las acciones de administrador en el entorno de origen y destino se bloquean durante la transferencia, incluido el acceso a la API y a la Consola del administrador de Google. Se recomienda que los representantes del entorno 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

La desinversión de la transferencia de dominio de Google Workspace configura 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 transferidos, 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 las 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 (alcance: 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 (alcance: 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.