Academy › Publishing › Domain and email
When the business changes its name, migrate one role first, not the whole team
Choose which team role changes address first, leave it with forwarding and a notice while you confirm everything's coming through, and only then switch the rest all at once.
By Yodai · Published September 6, 2026 · Updated October 12, 2026
There's no attack here: you're the one deciding to move the business email to a new name, and the risk is that something breaks without anyone warning you in time. You've renamed the business, or bought the new domain, and the email is already set up: admin@newname.com, sales@newname.com, each role with the address that matches it, just as you organized things before this change. One step is left, and it's the hardest one to decide: on Monday, do you switch all eight people on the team at once, or start with just one?
Switching everyone at once seems fastest. One notice, one messy day, and it's done. But if something goes wrong, a forwarding rule set up wrong, a signature that doesn't update on your phone, a website form that keeps sending to the old address, you find out with eight broken inboxes at once, not just one.
What breaks without warning
The new email works fine on day one, on your computer, right in front of you. What breaks shows up later, and almost always somewhere else: the phone, a form nobody checks, an invoice you sent three months ago. None of this shows up when you test it yourself for a few minutes before calling the switch good. It shows up weeks later, when someone outside the company is still writing to the old address.
That's why you don't switch the whole team on the same day. You migrate one role first, give it enough time for these failures to surface, fix them, and only then move everyone else at once.
The pilot: one role, not the whole team
- 1Pick the role with the least outside exposure
Internal admin or bookkeeping, not sales or customer service. If something breaks, let it break where no one outside the business can see it. - 2Don't delete the old account
Create the new one and set up forwarding from the old one, plus an auto-reply that says which address to use from now on. - 3Let it run for a week or two
Check every day what's still coming into the old inbox despite the notice. That list, not a gut feeling, is the proof of what needs fixing before you touch the rest of the team. - 4Fix it, then migrate the rest all at once
With what you learned from the pilot role, switch the whole team the same day, not one by one. Migrating one by one splits people outside the business between two different addresses depending on who they write to, and that's more of a mess than the one you were trying to avoid.
- If forwarding fails for a day, no one outside the business notices
- You have time to fix it without a customer waiting on a reply
- The email volume is lower, so there's less noise when checking for each failure
- You spot the real failure faster, because that inbox gets used every day
- If something breaks, you lose an appointment or a payment while you're fixing it
- The cost of the mistake is paid by someone outside the team, not inside it
Which one do I pick: Start with an internal role: it's the cheap mistake, because if the forwarding doesn't work for a day, nobody outside the team notices, and you've got time to fix it calmly. Only pick a customer-facing role if the business is so small there's no other role to test with first. In that case, still migrate that one person first, not the whole team on the same day, and ask them to check both inboxes that week.
- The pilot role you choose: an internal one, not the customer-facing one
- New account created, with forwarding and an auto-reply active on the old one
- A trial period set, one to two weeks, checking what's still coming into the old inbox
- The rest of the team migrates all at once, with the list of what went wrong already fixed
- One last decision is still pending, for whenever the business changes hands: what gets sold with the domain and what stays yours
Test yourself
Answer before opening each one. If one gives you trouble, go back to the section that explains it.
1. A team of four: the customer service rep handles the most email traffic each day, and someone suggests migrating them first so you'll spot any failure sooner. Which role do you migrate first, and why?
The internal role, not customer service. Spotting the failure sooner doesn't make up for who pays for it: if forwarding fails for a day on the customer service inbox, you lose an appointment or a reply to someone outside the company. In admin or accounting, the same failure is only noticed by the team, and you have time to fix it calmly.
2. Ten days after turning on forwarding for the pilot inbox, nothing new is arriving at the old inbox. Do you wait out the full fourteen days, or migrate the rest of the team now?
Migrate now. The one to two week window is a guideline to give you room to observe, not a hard rule: what matters is the signal, that nothing new is arriving despite the auto-reply, and that signal already showed up.
3. A one-person business has two addresses, admin and sales, and the same person answers both. Does it make sense to pilot one before touching the other, or since it's just one person, does it not matter if you switch both the same day?
It still makes sense. Switch admin first, leave forwarding and the auto-reply active, and check for a few days what's still coming in there before touching sales. The pilot catches the failure before it reaches a customer, and that doesn't depend on whether there's a whole team behind it or just one person handling two addresses.
Changing your name means moving your own email to a new address. Selling the business is different: there, you decide which inbox moves with the buyer and which one you keep.
In Yodai you connect the domain you already have to your site, and it stays registered where it is, in your name. See how your own domain for your website works.
NextWhat comes with the domain and what you keep