5. Voltooi de taken die vóór de overdracht plaatsvinden.

Zowel de bron- als de doelomgeving hebben hun eigen taken die u moet voltooien voordat een domeinoverdracht naar Google Workspace kan worden geautoriseerd.

Na elke testrun levert het domeinoverdrachtsteam de resultaten aan, met een overzicht van de nog openstaande taken vóór de overdracht en hoe deze kunnen worden opgelost.

Voltooi deze taken vóór de overdracht.

Stap 1: Brontaken

  1. Upgrade licenses (if applicable) —Licenses are not moved as a part of the transfer process. If the source environment is using a different Google Workspace edition than the destination environment, you need to upgrade the source to match the destination. For more information, review license transfers under Destination tasks .

    Opmerkingen:

    • U kunt in de bronomgeving gebruikmaken van proeflicenties of zogenaamde 'grace licenses' om tijdelijk licenties aan te schaffen en zo kosten te besparen. Houd echter rekening met de volgende punten:
      • Deze licenties blokkeren het proces waarbij een ander domein wordt vervangen door het primaire domein. Wijzig het primaire domein voordat u tijdelijke licenties activeert.
      • Als de beschikbare licenties in de doelomgeving volledige licenties zijn, krijgen gebruikers na de overdracht volledige licenties toegewezen.
    • Gebruikers in de bronomgeving aan wie geen licenties zijn toegewezen, worden nog steeds overgezet.
  2. Cancel unsupported license subscriptions —There might be implications to canceling license subscriptions. Source environments with Google Voice must pay extra attention to this step. For details, go to Source licenses .
  3. Add a placeholder domain to Google Workspace (if applicable) —Add and verify a new secondary domain name in the source environment that will eventually replace the existing primary domain . If a secondary domain exists and doesn't need to be transferred, you can use it instead. For details, go to Add a user alias domain or secondary domain .
  4. Create a placeholder administrator and make it the primary administrator of the account —Create a user account associated with the placeholder domain . If you repurpose an old account, make sure no other transfer domains existing as aliases are attached to the account. Grant this user the super administrator role and make them the primary administrator on the account. For more information, go to Send billing and account notifications to another admin . Make sure that Google 2-Step Verification is set up and sign in at least once to verify access with the placeholder administrator account.
  5. Vervang het primaire domein door het placeholder-domein — Voer een domeinwissel uit en promoot het placeholder-domein als het nieuwe primaire domein.

    Voordat je je domein wijzigt :

    Als je klaar bent om over te stappen, ga dan naar Je primaire domein voor Google Workspace wijzigen .

    • Annuleer alle apparaatabonnementen, inclusief Google Meet-hardware en Chrome Enterprise.
    • Sommige niet-ondersteunde licenties moeten mogelijk worden verwijderd vóór de overdracht. Zie Bronlicenties voor meer informatie.
    • Als de bronomgeving proeflicenties bevat, wordt de omwisseling geblokkeerd. Zorg ervoor dat de omwisseling plaatsvindt voordat er tijdelijke licenties worden verstrekt.
    • Het wijzigen van het primaire domein en het gebruik van secundaire domeinen brengt bekende problemen met zich mee. Bekijk de alternatieven voor het wijzigen van uw primaire domein .
    • Wijzig de namen van overgedragen gebruikers of groepen niet nadat u de primaire domeinnaam hebt gewijzigd. Gebruikers en groepen moeten op hun overgedragen domeinen behouden blijven.
    • If you set up SSO using a third-party identity provider and you're using a domain-specific issuer, the SAML assertion changes to reflect the new primary domain. Check your identity provider's configuration to ensure that users can authenticate after the primary domain swap. For details, go to SSO assertion requirements .
  6. Stel bewaarregels in voor Google Vault — Stel aangepaste bewaarregels in voor onbepaalde tijd.

    Maak één regel voor de volgende toepassingen:

    • Gmail —Selecteer bij Organisatie-eenheid de hoofdorganisatie-eenheid.
    • Gemini-app — Selecteer bij Organisatie-eenheid de hoofdorganisatie-eenheid.
    • Google Groepen —Selecteer bij Groepen de optie Alle groepen.

    Maak 2 regels voor de volgende toepassingen:

    • Chat — Selecteer een organisatie-eenheid en dan de hoofdorganisatie-eenheid. Selecteer voor de tweede regel Alle chatruimtes .
    • Rijden — Selecteer organisatie-eenheid en dan de hoofdorganisatie-eenheid. Selecteer voor de tweede regel Alle gedeelde schijven .
    • Ontmoet — Selecteer een organisatie-eenheid en dan Selecteer de hoofdorganisatie-eenheid en schakel 'Items van gedeelde schijven opnemen' in. Selecteer voor de tweede regel ' Alle gedeelde schijven' .
    • Locaties — Selecteer organisatie-eenheid en dan Selecteer de hoofdorganisatie-eenheid en schakel 'Items van gedeelde schijven opnemen' in. Selecteer voor de tweede regel ' Alle gedeelde schijven' .

    In addition, indefinite custom retention rules are set up in the destination environment before the transfer. For details, go to Indefinite Google Vault retention in the destination environment . For more information about transferring from Vault, go to Transfer your Vault data with domain transfer .

  7. Update your Sender Policy Framework (SPF) record (if applicable) —If the destination environment is using an outbound gateway that's different from the source environment, the source should update their SPF record to include the outbound gateway.

    Note: If you're using DomainKeys Identified Mail (DKIM), the transfer shouldn't impact your Domain-based Message Authentication, Reporting, and Conformance (DMARC) policy. The SPF record will continue to align post transfer, even if DKIM temporarily does not. Also, make sure to complete the DKIM post-transfer task in the destination environment.

  8. Los conflicten met agendabronnen op — Los eventuele conflicten met agendabronnen op voordat u verdergaat:
    • Building IDs —A building ID in the source environment cannot be the same as a building ID in the destination environment. To bypass the transfer block, you have 2 options. You can delete the building in the source environment. Or, you can make the 2 buildings' details identical to merge the source and destination buildings. To make the 2 buildings identical, make the ID, name, all address fields, description, and floor exactly the same for both buildings.
    • Building names —If a building resource in the source environment has the same name as a building resource in the destination environment, you must change the name of one of the resources to resolve the conflict. After the transfer process completes, you can merge the 2 building resources.
    • Resource IDs —A resource in the source environment that has the same Resource ID as a resource in the destination creates a conflict that can't be resolved by the transfer process, and the resource won't transfer. Delete one of the conflicting resources and re-create it with a non-conflicting ID. It takes 30 days for a deleted resource to be completely cleared from the system. You can either wait for the resource to be completely deleted, or the Domain Transfer team can submit a request to manually delete it.
  9. Evaluate impact to the associated Google Cloud organization (if applicable) —If Google Cloud is being used, notify the administrators of that environment regarding the potential impacts Google Workspace Domain Transfer might have on Google Cloud. If necessary, involve your Google Cloud partner or contacts at Google Cloud for help with evaluating impacts and remediation steps. The Google Workspace Domain Transfer team doesn't offer assistance with Google Cloud during a domain transfer engagement.
  10. Notify your Google Workspace reseller (if applicable) —Let them know of the planned domain transfer time and request that they don't change the account (for example, update subscriptions) during the transfer period.

  11. Enroll in any alpha or beta programs the source or destination environment is participating in (if applicable) —Alpha and beta program enrollments are not transferred in the source environment. Likewise, the source environment might depend on enrollments in the destination environment. The unenrolled environment needs to apply to and be accepted into those programs to continue to use them.
    We recommend that you enroll for alpha or beta programs before you transfer so that your transfer users have the same features available throughout the transfer process. However, the enrollment process might take some time and success isn't guaranteed. Therefore, it's recommended but not required.

  12. Om apparaten over te zetten die geregistreerd zijn voor Chrome ZeroTouch:
    1. Trek in de bronomgeving het bestaande preprovisioning-token in en deprovisioning van alle apparaten uit. Zet de apparaten terug naar de fabrieksinstellingen.
    2. Maak in de doelomgeving een nieuw preprovisioning-token aan.
    3. Geef het nieuwe token aan uw geautoriseerde preprovisioneringspartner. Uw partner gebruikt het token om de apparaten in de doelomgeving te preprovisioneren.

    De apparaten registreren zichzelf zodra ze met internet verbonden zijn. De apparaatstatus verandert in 'Geprovisioneerd'.

    Voor meer informatie over zero-touch-apparaten kunt u terecht op Zero-touch-registratie .

  13. Gastaccounts verwijderen — Gastdomeinen en gastaccounts worden niet overgezet naar de doelomgeving. Schakel gastuitnodigingen uit en verwijder alle bestaande gastaccounts.

    Om uitnodigingen voor gasten uit te schakelen:

    1. Ga in de beheerdersconsole naar Menu. en dan Beveiliging en dan Toegangs- en gegevensbeheer en dan Extern delen .
    2. Schakel het selectievakje 'Gebruikers toestaan ​​gastuitnodigingen te versturen naar personen buiten uw organisatie' uit.

    Om gastaccounts te verwijderen:

    1. Ga in de beheerdersconsole naar Menu. en dan Directory en dan Gasten .
    2. Selecteer alle gastgebruikers en klik op Gebruiker verwijderen .
  14. Instellingen voor beheer van mobiele apparaten:

    1. Ga in de Google Admin-console naar Menu. en dan Apparaten en dan Mobiel & eindpunten en dan Instellingen en dan Universeel .

      Hiervoor is beheerdersrechten voor mobiel apparaatbeheer vereist.

    2. Klik op Algemeen en dan Mobiel beheer en selecteer een optie:
      • Basis (agentloos) — U kunt basisvereisten voor de vergrendelschermcode afdwingen, beheerde apps implementeren en op afstand alleen het werkaccount wissen (niet de persoonlijke gegevens) als een apparaat verloren of gestolen is.
      • Geavanceerd (vereist de app Apparaatbeleid) — Alle functies van Basis plus app-beheer, apparaten op afstand wissen en apparaatgoedkeuringen.
      • Aangepast — Stel beheermogelijkheden in per apparaatplatform.
      • Schakel mobiel beheer uit (Niet beheerd) — Gebruikers kunnen hun werkaccount toevoegen en toegang krijgen tot bedrijfsgegevens (zoals Gmail en Drive) zonder beveiligingsbeleid of beheerderscontrole.
    3. Klik op Opslaan .

Stap 2: Bestemmingstaken

  1. Licenses are not moved as a part of the transfer process so you must provision enough spare Google Workspace licenses to support all transfer users —When you transfer users, they're assigned the same set of licenses in the destination environment they had in the source environment. Therefore, there must be enough spare licenses of the same type in the destination environment at the time of the transfer.

    If the destination environment is using a different Google Workspace edition than the source environment, make sure the licenses match by upgrading the licenses either in the source or destination environment.

    Opmerkingen :

    • Google raadt aan om licenties te upgraden om te voorkomen dat het serviceverwijderingsproces (SWP) wordt geactiveerd.
    • Provision any missing licenses so multiple subscriptions exist in the destination environment. You can optionally upgrade or downgrade individual user licenses after the transfer. Note that not all license types support Partial Domain Licensing (PDL) .
    • Make sure enough spare licenses are available in the destination environment. Consider if more users are added (for example, new hires) to each source environment between the start and end of the transfer process. If there's multiple transfers, you must also account for the total number of source users across all transfers.
    • Users in the source environment who have no licenses assigned to them still transfer. Monitor how licenses are autoassigned in the destination environment to make sure these users don't get licenses.
    • Domain transfer does not offer special Google Workspace billing plans to accommodate the purchase of spare licenses during the transfer. If the source environment licenses are under an annual billing plan, they remain active and are billed until the end of your annual plan contract. Consult your sales representative or account manager if you have more questions regarding Google Workspace billing plans.

  2. Ensure licenses are correctly applied to transfer users when multiple licenses exist —Some configurations within the destination environment might impact the way transfer users are assigned licenses.This situation might result in transfer users ending up with a different license than expected. These configurations include automatic licensing and overriding automatic licensing for specific organizations .

    Om ervoor te zorgen dat er tijdens de overdracht geen onverwachte wijzigingen in de licenties optreden, moet u de volgende stappen ondernemen:

    • Als de automatische licentieconfiguratie van de doelomgeving is ingesteld op "Uitgeschakeld voor iedereen" of als de doelomgeving slechts één licentietype heeft, zijn er geen wijzigingen nodig.
    • If the destination environment's automatic licensing configuration is "On for everyone" (for example, Google Workspace licenses), then make sure overriding is on for specific organizational units. For the transfer root organizational unit, make sure the automatic licensing configuration is turned off, with no further overrides for child organizational units.

  3. Create the transfer root organizational unit and, optionally, re-create the source environment organizational unit structure —Create an organizational unit to serve as the parent organizational unit for all transfer users. Once created, you have 2 options:

    • Do nothing —The domain transfer process recreates the organizational unit structure from the source environment under the new transfer root organizational unit. To do this step, set the transfer option "recreate the organizational unit structure in advance" to No. All incoming transfer users inherit policies you apply at the organizational unit level.
    • Manually re-create the source environment organizational unit structure under the transfer root organizational unit —Domain transfer ensures that the source environment's entire organizational unit structure is properly replicated before proceeding with the transfer. To do this step, set the transfer option "recreate the organizational unit structure in advance" to Yes. This option is useful if you want to set distinct policies on different child organizational units.

      Let op : Domeinoverdracht valideert alleen de organisatiestructuur. Het is uw verantwoordelijkheid om ervoor te zorgen dat de juiste beleidsregels zijn ingesteld voor de organisatie-eenheden.

  4. Stel de juiste beleidsregels en instellingen vast die aansluiten op de vereisten van de bron- en doelomgeving. Beleidsregels en instellingen in de bronomgeving worden niet overgezet naar de doelomgeving. Bovendien zijn na de overdracht alleen de beleidsregels en instellingen in de doelomgeving van toepassing op de overgedragen gebruikers en hun gegevens.

    You must review your policies and settings in the destination environment and compare them with the source environment. This action includes both general and specific settings for the transfer root organizational unit to make sure that they cover all incoming transfer entities and users.

    The following is a non-exhaustive list of policies and settings you should verify as part of the setup process. Also, perform a full audit of both environments to make sure all relevant sections are analyzed:

    • Service Enablement (On/Off) —Verify that the services you use in the source environment are turned on in the destination environment, and the transfer root organizational unit behaves as expected. It's especially important when using Google Vault, because Vault rules might not apply if the service is off.
    • Gmail, geavanceerde instellingen en MX-records — Bekijk instellingen zoals e-mailroutering, nalevingsregels en IMAP-inschakeling en -delegatie. Ga naar Gmail activeren met Google Workspace voor meer informatie.
    • Password management —Review your password policies to make sure they're aligned with your organization's procedures. Once transfer users are moved to the destination environment, they inherit the password management policies in the destination environment.
    • 2-Step Verification —Controls whether users are allowed to add a 2-Step Verification configuration to their account, whether it's allowed or it's enforced. If transfer users with 2-Step Verification turned on are transferred into a destination environment or organizational unit where 2-Step Verification is turned off, destination administrators will be unable to manage them. Instead, admins can either move these users to a different organizational unit where 2-Step Verification is turned on to make changes, or they can remove 2-Step Verification from accounts before the transfer.
    • Sharing settings —Controls whether users can share their content outside the organization. If the source environment blocks sharing and the destination environment does not, then transfer content might be accessible outside your organization. If the source environment has open sharing by default and the destination environment does not, then transfer content might be inaccessible to users in your organization. Learn more about sharing options for Google Drive and Google Calendar .
    • Data loss prevention (DLP) rules —Monitors and prevents users from sharing sensitive information outside your organization. When DLP prevents users from sharing information in the source environment, and content is transferred into a destination environment without DLP setup, users in the destination environment can share information outside your organization. Learn more about Gmail DLP rules and Drive DLP rules .
    • Chat history —Controls whether chat history is on or off the record, and whether users can set enforcement on all chats or make it the default. If the source environment allows for chat history to be turned on, but the destination environment forces it to be off, then chat history is lost. While Google Chat is listed as unsupported for the transfer, direct messages (DMs) will transfer.
    • Data countries/regions —Controls which specific geographic location to store your migrated data. Transfer users that need to stay in a specific geographic location must have this policy set appropriately in the destination environment to make sure their data does not unexpectedly leave their required data country/region. For details, go to Data regions: Choose a geographic location for your data .
    • Less secure apps (also known as App Passwords) —If less secure apps are turned on in the source environment and are turned off in the destination environment, the connection with the application using less secure apps time out and close. Timeout periods vary by application, but usually expire within 60 minutes. Future access requests made by the insecure application are blocked. For details, go to Control access to less secure apps .
    • OAuth scopes, single sign-on (SSO) for SAML, trusted apps, and Chrome extensions —OAuth controls determine the level of API access allowed to users and third-party applications. SSO for SAML, whether supplied by Google Workspace or implemented as a custom application, allows users to leverage their Google Workspace credentials to access other applications or services. Trusted apps determine the applications users can install from the Google Workspace Marketplace or Chrome Web Store and which apps are allowed to bypass OAuth restrictions. Learn more about how to control third-party & internal apps , SAML SSO , Google Workspace Marketplace apps , and Chrome apps and extensions .
    • Domeinbrede delegatie — Hiermee krijgen apps toegang tot de Google Workspace-gegevens van gebruikers. Om ervoor te zorgen dat de clients en scopes correct werken, moet u domeinbrede delegatie instellen in de doelomgeving vóór de overdracht.

    Belangrijk : Het niet correct vaststellen van beleid en instellingen kan leiden tot:

    • Onbedoelde blootstelling van uw gegevens buiten uw organisatie (bijvoorbeeld doordat de doelomgeving meer open instellingen heeft dan de bronomgeving).
    • Beperkte toegang tot voorheen toegankelijke gegevens (bijvoorbeeld, de doelomgeving heeft strengere instellingen dan de bronomgeving).
  5. Accept agreements that govern transferred data —Review the Data Processing Amendment (DPA), model contract clause, and HIPAA Business Associate Amendment (BAA) in the destination environment. For details, go to Privacy compliance and records for Google Workspace and Cloud Identity .
  6. Schakel Vault in als het in de bronomgeving wordt gebruikt — Als de doelomgeving geen gebruik maakt van Vault, maar de bronomgeving wel, dan moet de doelomgeving Vault inschakelen.
  7. Breng uw Google Workspace-reseller op de hoogte (indien van toepassing) — Laat hen weten wanneer de domeinoverdracht gepland staat en verzoek hen om gedurende de overdrachtsperiode geen wijzigingen aan het account aan te brengen (bijvoorbeeld door abonnementen bij te werken).

  8. Enroll in any alpha or beta programs the source or destination environment is participating in (if applicable) —Alpha and beta program enrollments are not transferred in the source environment. Likewise, the source environment might depend on enrollments in the destination environment. The unenrolled environment needs to apply to and be accepted into those programs to continue to use them.
    We recommend that you enroll for alpha or beta programs before you transfer so that your transfer users have the same features available throughout the transfer process. However, the enrollment process might take some time and success isn't guaranteed. Therefore, it's recommended but not required.

Belangrijk :

  • Downgrading licenses might cause a loss in Google Workspace services and functionality. Carefully review the differences between Google Workspace editions and the impact of both upgrading and downgrading before making any changes. Learn more about Google Workspace editions .
  • Het downgraden van licenties kan het SWP-programma activeren, waardoor een overdracht tot 90 dagen vertraagd kan worden.

Stap 3: Overige taken en aandachtspunten

  • Change management —Both the Google Workspace Domain Transfer team or the transfer process don't automatically provide users with information on the transfer's execution during the transfer process. It's highly recommended that source and destination environment representatives inform users of the transfer process, and its potential impacts, in advance.

    All admin actions in both the source and destination environment are blocked during the transfer, including API and Google Admin console access. It's highly recommended that source and destination environment representatives notify all domain super admins and delegated admins before the transfer and once it completes.

  • External dependencies —If you use Google Cloud Directory Sync (GCDS), GAM (a third-party command-line tool for Google Workspace administrators to manage domain and user settings), or a third-party single sign-on (SSO) provider, make sure to analyze the effect of the transfer. Also examine how having the source and destination environments coexisting in a single environment affects your system and the timing of your transfer execution.

Onbeperkte bewaartermijn van Google Vault in de doelomgeving

Met Google Workspace Domain Transfer& worden onbeperkte, aangepaste bewaarregels ingesteld in de doelomgeving. Beheerders van de doelomgeving hoeven hiervoor geen actie te ondernemen.

Het Vault-archief voor overgedragen gebruikers wordt verplaatst, maar de Vault-bewaarregels uit de bronomgeving blijven behouden. Om ervoor te zorgen dat er tijdens en na de overdracht geen Vault-gegevens verloren gaan, maakt het overdrachtsproces de volgende Vault-bewaarregels aan in de doelomgeving voordat er overdrachtsacties worden uitgevoerd:

  • Google Agenda — Aangepaste bewaarregel voor onbepaalde tijd (bereik: overdracht van de hoofdorganisatie-eenheid).
  • Google Chat — Aangepaste bewaarregel voor onbepaalde tijd (bereik: directe berichten met overgedragen gebruikers in de hoofdorganisatie-eenheid van de overdracht, maar niet Spaces).
  • Google Drive — Aangepaste bewaarregel voor onbepaalde tijd, exclusief gedeelde schijven (bereik: overdrachtshoofdorganisatie-eenheid).
  • Gemini-app — Onbepaalde aangepaste bewaarregel (bereik: hoofdorganisatie-eenheid).
  • Gmail — Aangepaste bewaarregel voor onbepaalde tijd (bereik: overdracht van de hoofdorganisatie-eenheid).
  • Google Groepen — Aangepaste bewaarregel voor onbepaalde tijd (bereik: hoofdorganisatie-eenheid). Bewaart gegevens voor alle groepen in de doelomgeving, inclusief groepen die niet in het overdrachtsproces zijn opgenomen.
  • Google Meet — Vereist 2 aangepaste bewaarregels voor onbepaalde tijd:
    1. Exclusief gedeelde schijven (bereik: overdracht van de hoofdorganisatie-eenheid).
    2. Inclusief alle gedeelde schijven (bereik: root-organisatie-eenheid).

      Behoudt de gegevens van alle gedeelde schijven in de doelomgeving, inclusief schijven die niet in het overdrachtsproces zijn opgenomen.

  • Google Sites — Vereist 2 aangepaste bewaarregels voor onbepaalde tijd.
    1. Exclusief gedeelde schijven (bereik: overdracht van de hoofdorganisatie-eenheid).
    2. Inclusief alle gedeelde schijven (bereik: root-organisatie-eenheid).

      Behoudt de gegevens van alle gedeelde schijven in de doelomgeving, inclusief schijven die niet in het overdrachtsproces zijn opgenomen.

  • Gedeelde schijven — Onbepaalde aangepaste bewaarregel voor alle gedeelde schijven (bereik: hoofdorganisatie-eenheid). Bewaart gegevens van alle gedeelde schijven in de doelomgeving, inclusief schijven die niet in het overdrachtsproces zijn opgenomen.

Belangrijk : De bewaarregels van de kluis in de doelomgeving worden tijdens het overdrachtsproces niet verwijderd of gewijzigd, aangezien dit mogelijk onherstelbaar gegevensverlies kan veroorzaken.