Google Workspace Domain Transfer - Key Takeaways | C2C Community

Google Workspace Domain Transfer - Key Takeaways

  • 20 June 2022
  • 5 replies
  • 465 views

Userlevel 5
Badge +6
Google Workspace Domain Transfer - June 16th 2022 - Michele Chiappalone

 

The C2C Connect: UK and I group, led this week by @fintan.murphy and @andy.yates ​hosted their regular session for Google Cloud customers and professionals located in the UK & Ireland. These monthly sessions bring together a local community of cloud experts and customers to connect, learn, and shape the future of cloud. 

 

60 Minutes Summed Up in 60 Seconds

Presenter Michele Chiappalone talked to our members about the Google Workspace Domain Transfer service. He covered what the tool is, what the transfer process looks like, and how to engage with him and his team. There was a record number of questions from the audience - and the notes below capture the key points from both presentation and answers to those questions:

  1. Traditional migration pain points - disruption, complexity, time, expense

  2. The Domain Transfer tool enables you to merge two environments with no business interruption

  3. It is only available to “Select” or “Enterprise” customer segments, through a PSO engagement

  4. Benefits: data never leaves, entities are left intact, content sharing is retained, low operational complexity, it usually completes in <24 hrs, with no downtime

  5. IAM is not impacted - the user is the same - just transferred to a new tenant

  6. Customers love it! 150 transfers, since august 2017; up to 65k users, 450M files

  7. There are some limitations: licenses are not transferred, it’s all-or-nothing, there’s no identity merge / deduplication, there’s no going back!

  8. Source and destination admin access is revoked during the process; only the destination admin is automatically restored

  9. The public Help Center article has the latest on what is / is not supported: https://support.google.com/a/topic/10308467

  10. Policies and settings are not copied over

  11. GCP Projects will continue to exist, but they stay in the source, moving these is a separate effort (to be done either before or after - and not during the domain transfer)

  12. Additional Google Services (adwords, youtube, etc) - are NOT supported (officially);  experience suggests that ownership / access remains, as the Google account remains the same. To date, the team has not seen reports of issues with these services / access

  13. Services offered by Google’s Professional Services Organization (PSO) - with experts in Workspace and Domain Transfer - at a cost of 1 advisory unit; with a max of 12 transfers in a single PSO engagement (1 transfer = 1 source to 1 destination environment). It is not based on the numbers of users or domains within a given tenant.

  14. There are some eligibility checks - blockers include e.g. accounts undergoing service wipeout, those with legacy data locations, google voice, google advanced MDM in source, or client side encryption.

  15. Partners can access these resources (published in Partner Advantage):

    Google Workspace Domain Transfer Pitch Deck 

    Guidelines for Partners 

  16. There is now no lower limit to the number of users (there used to be, but this has been superseded by the customer classification)

  17. Chromebook devices need to be reprovisioned in the destination environment

  18. Plans to update the service to allow for partial carve-out (divestiture, etc) are being discussed! Stay tuned! Let your partner know of any desired use cases in this regard

  19. These, and any other changes to the service should be announced on the Workspace Roadmap, for those who have access - and in Partner Advantage updates. The team will advertise updates - but also be sure to let them know if there are particular unmet needs.

  20. The migration of an external IDP (e.g. Okta) is out of scope. The settings for this need to be adapted (post transfer) - this is also true for SAML apps, and any auto-provisioning will need to be stopped and re-attached / reconfigured. This approach of stop and re-attach / reconfigure is also necessary for GCDS (and GCDS should recognise that it’s the same user).

  21. Only a few of the organization policies and settings from the admin console can currently be exported via API - and Michele isn’t aware of any changes that are coming there, but it may be worth checking the Workspace Roadmap. Typically this isn’t a blocker, because most customers want to apply destination policies (not preserve those from the source).

  22. Groups are moved, Groups settings should also transfer - but Michele will follow up on this.

  23. EDU is not supported (eg.for teaching / learning upgrades) - and no current plans / ETA (but maybe in the future)

  24. Stay tuned for future plans about GWS partner access to the tool

  25. File sharing permissions with external domains are preserved through the migration

  26. Customers typically apply Chromebox for Meetings licenses to the destination (and set up those CfM devices again) manually, ahead of transfer

  27. The transfer plan is a deliverable of the engagement. 

  28. Drive additional storage license purchased / attached to end-users - Michele will check if / how these might transfer, but it’s not a hard blocker (it can be overcome)

  29. The service has evolved over the past 3 years - but there are still some things that might not be covered (eg. rules) - so if there are concerns about a particular feature, it’s best to check help center article: https://support.google.com/a/topic/10308467

  30. The OU structure will continue to exist in the source. It is not intended to be used, but it can still act as a reference, if needed when setting up destination policies and settings.

  31. As part of the migration, you can opt to recreate the OU structure manually in advance, or let the service recreate it automatically during migration. Doing it manually may help in checking settings ahead of the move. 

  32. Data studio files - as they live in Drive, so it should work - but will follow up

  33. There are no data limitations (beyond who it is available to)

  34. Admin / audit logs will not be moved - but a separate system could be put in place (e.g. via a SIEM) if you need to preserve the logs.

  35. Chromebooks need to be re-enrolled. Android needs to be downgraded to basic MDM, then re-set up (including private apps, etc).

  36. Apps Script is a corner case: the file itself is moved, but the default GCP project continues to live in the source. Recommend making a copy, and recreating the whole thing in the destination; triggers, events, permissions (OAuth) may need to be regranted after the transfer.

  37. Small customers still have options for copy-based migrations - we’ll provide a link for this

  38. Chrome Browser Cloud Management (CBCM) - needs to be reconfigured in the destination.

There were so many questions, we didn’t get to all of them! We’ll post them, and the answers as we get them, in the comments below.

 

Watch the recording here

 


5 replies

Userlevel 6
Badge +17

Wow, what a thorough write-up of an incredible session.

Very thorough write-up from an interesting session that triggered so many questions. I was particularly interested to hear about 18 ‘Plans to update the service to allow for partial carve-out (divestiture, etc) are being discussed! Stay tuned! Let your partner know of any desired use cases in this regard’ and 24 ‘Stay tuned for future plans about GWS partner access to the tool’.

Userlevel 7
Badge +29

Great takeaway post, @andy.yates, thanks! It would be great if Michele could perhaps answer questions in here - as there were so many questions in the event that not everybody had the time to ask! 😁

Userlevel 5
Badge +6

So it turns out that, due to some pretty impressive moderation by @Fintan Murphy, and some even more impressive answering by Michele Chiappalone, we actually got through all the questions that were asked during the session!

There is one question that came up afterwards that I’m aware of - which was about migrated Groups - and whether or how the Migration tool resolves discrepancies between individual Group settings, and the target organisation policy? That is - if a target organisation has settings which prevent Group Owners from allowing external members, or allowing external incoming email - and the source Groups have these settings enabled, what will the result be?

 

 

 

Group settings are preserved during the transfer, with a watchpoint on dynamic groups. See https://support.google.com/a/answer/10311856

Reply