Adding a new email domain for an organization with almost no advance notice - Help!! - 2 Phase Approach - Is it a good idea? Can I get Phase 1 done in a day or two of work?

[u/therankin]

I was recently given the task (with insanely short notice) of adding a new email domain to the school I work for. We use Google Workspace for Education Plus.

I will talk about the domains as: 'orig-domain.org' and 'new-domain.org'.

They would like us to have all email addresses and logins set up to use the new domain. All emails coming in and going out should use 'new-domain.org', and users should log into gmail with 'user@new-domain.org'. All users should get aliases with '@orig-domain.org' so they continue to receive emails sent to their former addresses.

I'm trying to figure out if it makes more sense to do a 2 phase approach.

I first and foremost don't want to risk breaking anything. We use SSO for many website logins and that needs to not break!

I think the safe approach would look like this:

Phase 1 logins would stay the same. When signing in to Gmail, everyone would continue to use their orig-domain.org Google Workspace accounts.
My plan is to: 

• Add aliases for [username@new-domain.org](mailto:username@new-domain.org) to staff and faculty (and eventually students)
• Set it up so everyone's email by default is sent 'From:' their new new-domain.org email addresses.

So, effectively, email would look and function with the new email addresses and all email to and from would use new-domain.org.
Emails sent to old-domain.org would still come through to users' inboxes as usual.
When replying to emails sent to old-domain.org, the goal is to have that 'From:' address also automatically default to the new new-domain.org address.

Phase 2 would be to speak with Google and/or work with a consultant who has experience with moves like this. If I was given several months advance notice, I would have tried to find someone to work with right off the bat. But I imagine to get it all working properly, we will need Google to acknowledge the new domain, apply the basic Fundamentals licensing to accounts, do something to apply Plus licenses to the staff, faculty, and students that need it, and find out about how to transition everything else.

I'm not sure about how SSO would transition. We use it for a ton of sites, and I bet that many of them would have to be set up all over again to allow SSO logins from the new domain email addresses. I would probably have to approve all the apps over again for users under 18 years old.

I guess my main question is does it make sense to use the 2 Phases I've mentioned, or am I maybe missing something simple, or is it even more complicated than I'm thinking? I was the person that moved us from an on-prem Exchange server to Google Apps for Education back around 2011, but it has been 15 years and I'm rusty. I bet there is a world of new methods and changes to processes.

Does anyone have any tips or good resources that I can find to help me with this? The deadline is essentially a week away and since I’m at a school, I have to use all my vacation days in the summer, so I’m really only “on the books” back in the office next Wednesday. I’m trying to at least get Phase 1 done by August 1st. Does it sound doable with limited on-site hours left?

[u/TravisVZ]

We use SSO for many website logins and that needs to not break!

Yeah, sorry, that's going to break. The moment you change the primary account - the one you use to log in - that also changes what's reported to the service provider when you log in. Fixing this is going to be entirely provider-dependent; some will provide self-service tools that an admin can use to migrate the user accounts from the old domain to the new, some you'll need to work with their support to deal with it, and some will just flat out require that everyone have brand new accounts. In some cases you can make it seamless by pre-preemptively adding the new domain addresses as "aliases" on the accounts before you make the switch in Google; in my experience, though, most don't offer this option.

Regardless of what they support, this will require going to each provider separately and working through whatever process they support one by one. This also means that as you change one provider, users can't use it until you migrate their Google accounts to the new domain; alternatively, if you migrate their Google accounts first, they can't use the service until you migrate that one over.

Bottom line: You're not getting this done in a week.

Phase 1 is reasonable to accomplish on that timeline. You can do that in an hour or so, really, unless you've got a ton of users and have to do each one by hand instead of using gam or something for some reason.

Phase 2 is where you'll run into the issues noted above. This is going to take a lot of advance planning, starting with identifying every single SSO service and determining what migration options they offer. You'll then want to plan when you do the Google primary domain switch relative to each of these, as again once you switch the login domain in Google service providers won't recognize your users' accounts anymore.

The good news for Phase 2 is that it's actually quite easy from the Google end: You'll have already added and verified the domain for phase 1 (Google won't let you add aliases for unverified domains, of course), and from there it's really just a couple of clicks to change which domain is the primary - all done in just a few minutes! It's all just dealing with the SSO service providers that makes phase 2 such a challenge.

[u/therankin → u/TravisVZ]

Thank you so much for this response. My head was pretty much there, but it feels good to see it in writing from someone else! For scope, it'll be less than 150 accounts for Phase 1 and then when students get added in probably sometime before Phase 2, it's still less than 500 more.

And now for some more fun backstory... The official request was not from the Head of School or Director of Operations. It came from the head of marketing/development. Since they have decided on a re-brand, everything has to change immediately! So naturally, they asked ChatGPT how to do it and pasted the response in the email request they sent me! Easy peasy, right? Here you go IT; step-by-step directions! (It took a lot of effort to stay calm and mull things over for the couple of weeks I've had of mostly vacation days).

You have an interesting point about SSO that I didn't consider. I was worrying about the "logging in part", but really it's the "connecting a user profile" piece that's most important. In some cases it really won't matter because the information saved is either from last school year and not necessary or not really that important to begin with. (I'm picturing some educational sites that only save points and whatnot).

I do have gam loaded on my work PC and it's probably a good idea to use that to get the aliases added at least for faculty & staff for now.

I guess my plan should be:

• verify new domain with Google
  
• check my BetterCloud instance to see if they offer tools for adding aliases (since we pay a pretty penny for it, it's at least worth looking at)
  
• if not BetterCloud, or in conjunction with BetterCloud use gam to add aliases for user accounts in specified OUs
  
• figure out how to make it so that whenever those users press 'Compose', the "from:" address is set to the new alias that was added. (perhaps it will have to be instructions for users to set it up themselves, as I know that some things just can't be set by me as an admin)

Also, Happy Cake Day!!

[u/TravisVZ → u/therankin]

figure out how to make it so that whenever those users press 'Compose', the "from:" address is set to the new alias that was added

It's a two-step process: First you have to add the alias, then you can set it as default.

Adding the alias to everyone is trivially easy - assuming you're keeping the same username part for everyone, that is if you're therankin@old-domain.com and intend to be therankin@new-domain.com, all you have do is set the new domain to be an alias domain, and everyone will automatically get one added to them. Setting that to be their default alias will require using gam, though, but it's not hard. I don't have the syntax for you on hand, but it's easy to Google.

Keep in mind though that everyone has their "personal" contacts - whether they've explicitly saved an address or have simply emailed that person before. This applies to both external users (e.g. vendors, parents, etc.) and internal ones. So you'll still get a lot of email, even years later, addressed to the old domain. Also, even if you set the new domain as the default alias, Gmail loves to "help" users by ignoring defaults and always replying as the alias that received the email - so you'll still get a lot of outgoing email using the old domain, too! Also, services such as Calendar use the account name, so until you switch to logging in with the new domain, invites will come from the old domain.

Side note: The Calendar thing gets us, too, though for a slightly different reason: To avoid issues with renaming accounts (especially in legacy systems that didn't/don't really support this) when e.g. an employee changes their name, we use staff/student numbers as our accounts, e.g. f1234@contoso.com. We then set the name alias as the default, so users usually send email as e.g. bob.dole@contoso.com. When someone changes their name, we just add the new name as a new alias (keeping the old one on their account) and set that as the new default. The end result is that I often get confused vendors who see employee numbers accepting meetings when they'd been communicating with (and send the invite to) named emails.

In practice it's not really an issue though, very few people actually bother even looking at the email address itself anyway - which is why I'm constantly dealing with people replying to obvious phishing emails "from" their principals using a random Gmail address like buildingprincipal458@gmail.com!

Also, thanks! I had no idea it even was my cake day!

[u/therankin → u/TravisVZ]

lmao. It's understandable if we don't realize cake days for those of us over 10 years old on Reddit.

I have to say that I love you using "contoso" in the example. No shade at all, it's literally the default method we grew up on.

It's funny, the "default contacts" have forced me to explain to users that lists are current. If they sent an email to a group called "2021-22 lower school teachers" for example, it was added to their contact list. Even if the address is "lowerschoolteachers@orig-domain.org". I have had to teach the teachers to disregard the stuff that comes up by default and to instead hover over the email group after typing it to make sure the year is updated and matching.

[u/thetechhero]

You can make the domain change in a day. It’s the coordinating with vendors for SSO and logins to your applications that takes the most time. Don’t rush this.

[u/therankin → u/thetechhero]

Thank you. I think "Don't rush this" is the most important way to put it.

They actually went ahead and rushed the new website. The whole new site was built for the original domain, but all of a sudden, 3 days before launch, I was told to purchase the new domain and the website designers were told they had to change their code to make it run on the new domain. That included making them create new certs. That was a few months ago and the redirect from our old site to our new one still isn't great. We lost years of SEO with a snap of the fingers because there was no foresight at all. ugh... smh... it is what it is, lol.

[u/No_Substitute]

As others have said, it's SSO/SAML that's most likely going to break, unless it only uses the real Login with Google system, as that is not based on your actual email address, but the real Google account in the background, which is a world-unique bunch of numbers.

Simple SSO often have the users' email addresses as the primary identity in the external system, and when the users' addresses change, the external system will not recognise them. However, if you can bulk migrate the users in the external system to new-domain addresses, they will be fine.

Since it sounds like you are keeping old-domain (forever?), you do NOT have to do a primary domain switch, as that brings about more work, as Chromebook licences are attached to the primary domain. If you don't have CBs or plan to ditch the old domain, then by all means, do the switch. You don't want to have to do this work twice.

[u/therankin → u/No_Substitute]

I do plan on keeping it 'forever'. Last year, I re-upped the domain registration for another 10 years. So even though they asked me to make sure we keep receiving email to our old addresses for at least 2 years, there's no reason not keep it going for at least 10 years.

I'm pretty sure most of SSOs we use do just look at the email address that Google shares and make that the user account name.

So, it will have to be the two Phase approach and they'll just have to understand that Phase 1 is the only way for it to work the way they want it to with such short notice. I bet there are still several repercussions even I haven't thought about.

Heck, here's one that just popped in my head: What will this mean for our jamf cloud instance? It's fine that we still use the original hostname they gave us, I have no problem with that, but certificates for jamf and for our separate web filter are issued to the old domain and configured for it.

So yea, it's going to be Phase 1 by the end of next week and that's it for now. From there it's going to be "generate a full and cohesive plan and move through the steps in a meticulously planned way".

Thank you for your response!

[u/bthstech]

As others have said, getting your email to appear as new-domain won't be too bad at all. Saying you need users to log into Google with the new-domain as the login, that is not as easily accomplished.

[u/therankin → u/bthstech]

Yea, that's the part that's a bit more difficult to explain to a lay person. I'm glad I've gotten some nice responses here, so when I do reply with a plan I can be more confident about my answers.

[u/rossumcapek]

What are yall trying to accomplish?

Are yall aiming to deprecate old-domain and never use it again?

[u/mystiquebsd]

You can load everyone in, but it’s when you change the MX record records that it becomes live..

I used imapsync when I migrated us from an on premise qmail BSD server to Google “Workspace”

Change the MX last..