Google has announced that their "GSuite Legacy free editon" will no longer be available from May 1, 2022.
https://support.google.com/a/answer/2855120
Accordingly, we had to plan to shift some of our domains which used the Legacy free edition. For those with deep pockets or for those whose revenues justified it, the easiest option would have been to shift to a paid plan. But since we already had the non-profit free edition for other domains, we wanted to shift the "Legacy free" domains there instead.
Some other options would have been
- another provider - like zoho.com which might be cheaper
- running our own mail server using tools like mailinabox.email or iRedMail or Modoboa which would be cheaper still, but would require manpower to maintain
- using the available Microsoft Office365 emails, which also we have as part of non-profit free credits.
For one of our domains, x.tld, there was only one mail box, which was moved to our domain registrar's free mailbox plan - they offer two free mailboxes. (Edit April 2022 - now moved to using improvMX.) Then we used x.tld as a test run for the migration of our more important a.tld domain by moving it to our free.tld non-profit account as an additional domain -
https://support.google.com/a/answer/7502379
Google doesn't seem to offer any seamless "move domain from one account to another" option. We have to delete the domain from the source account and add to the destination account. If we just delete x.tld from the source account by deleting the google account itself, the blogger and youtube accounts associated with that google account would get deleted as well. Luckily, we had another domain y.tld which was not being used for emails. We added y.tld as a secondary domain in the source account.
For adding y.tld as a secondary domain and not an alias, first we had to upgrade to Google Workspace Business Starter - otherwise it allows only the addition of alias domains. After y.tld was added as a secondary domain, we made y.tld the primary domain, then removed the x.tld email alias which is automatically created for each of the users in x.tld which has now been transformed into y.tld due to the change in the primary domain. So, now the blogger and youtube channels can be accessed using user@y.tld, and x.tld was available to be migrated to the free.tld account within half an hour or so.
In the case of x.tld, which had only one user, there was an option where the user could submit a form to google for consideration for a different migration path if the domain was being used for an Individual instead of a Business. But I didn't take it, as anyway such an option would not be appropriate for us. Additionally, in the case of x.tld, an email had been received saying that if we opt to upgrade by ourselves, we would not be charged till July during the upgrade process. But in the case of a.tld, that email was not received, hence charges were a possibility. But as mentioned in the support page, admins who opt to upgrade before the deadline will not be charged till July 1 2022. So for the a.tld migration as well, we could migrate without incurring charges. This information is seen only after going through the "Switch" button and confirming that we wish to set up billing etc.
Here are excerpts from a migration email sent to our users of a.tld:
- Before the migration, it is strongly recommended that you take a backup of all your old data. You can do this by logging in to your a.tld account and going to https://takeout.google.com/
- After the migration, the following would happen:
- Old emails will be migrated from the old inbox to the new inbox over the course of 2-3 days, depending on the number of emails.
- During this time, the old emails would also be available in the old inbox by logging in to an alternate email id, which would have b.tld instead of a.tld - for example,
- f@a.tld would be able to log in as f@b.tld and see the old emails.
- Calendar data would need to be exported from the old account and imported into the new account. - https://support.google.com/calendar/answer/37111
- Similarly, google drive content would need to be imported separately into the new account. The backup of your data taken using takeout.google.com would contain all this by default.
- Contacts can also be exported from the old account - https://support.google.com/contacts/answer/7199294
and imported into the new account - https://support.google.com/contacts/answer/1069522 - In case contacts were not created manually but just appear automatically based on old emails, such contacts will again start to appear automatically in the new account after the email migration is complete, in 2-3 days.
- In case you use secondary google products like blogger, youtube, etc, you will need to login with @b.tld (for example f@b.tld) to access the older content after the migration.
Before the migration, I tried out using the email migration service to move emails from a test account - https://support.google.com/a/answer/9216781 - the email data migration tool went quite slowly, around 10 minutes for 60 MB of emails, and then remaining at 99% for quite a while. During the actual migration, which started on Sunday morning, the migration progress (of emails being taken via imap) on Tuesday morning after around 45 hours of migration is shown in the cropped image below, where the mailboxes with the largest number of emails and nearly 15 GB of content remaining half-done. Google takeout after excluding emails went quite quickly when the "add to Drive" option was chosen, less than five minutes each, with only one user having more than 2 GB of takeout data after excluding emails. The "Start time" shown as a date in 2001 is what I had chosen to include all emails, since we need to set a start date for the email migration.
One issue faced during the migration was: the admin email id in a.tld which was used to send out alerts to users about the migration turned out to be caught by spam filters. So, almost none of our users were alerted about the move, and some of them were upset about this. Probably maintaining updated phone numbers and alerting via SMS or Whatsapp might be a better way to go. Or use another email id which is known to work, and use read receipts.
Migrating another set of domains to another non-profit account ran into IMAP authentication issues for all those users who had recovery email / recovery phone number / disabled IMAP manually. The relevant team had to manually log in to each account, change recovery phone number to their number (or ask the concerned person to tell them the OTP), enable IMAP and "allow less secure apps".
No comments:
Post a Comment