You do not need to change your email address, migrate your history, or switch everyone over on the same morning. The move that works is: run the new tool alongside the old mailbox for two weeks, start with one address rather than all of them, and change one habit at a time. The disruption people fear almost always comes from doing it as a single cutover, and from a decision nobody made explicitly about whether you actually want a help desk or just an owner per message.
What “a group mailbox” usually means
Three very different situations go by that name, and the starting point changes the plan.
A distribution list. Messages are copied into everyone’s personal mailbox. There is no central archive to migrate, which makes this the easiest technical move and the hardest cultural one: your team has never had a shared place, and you are about to give them one.
A shared mailbox with proper permissions. Microsoft 365 or a Google Group with Collaborative Inbox. The history exists and is central. You are adding a coordination layer on top of something that already works, which is the smoothest of the three.
An ordinary account whose password circulates. The most common in small organisations and the one with a deadline attached, because it is the one that gets locked by the provider or lost when someone leaves. Here the migration is also a security fix.
Identify which one you are in before anything else. If you are not sure of the differences, shared mailbox vs distribution list lays them out.
Decide what you are moving to, explicitly
This is the decision teams skip, and skipping it is what makes migrations painful. A help desk and a shared inbox are not the same destination.
A help desk turns each email into a ticket with a reference number, adds a customer portal and a knowledge base, and reports on resolution times. It suits a team whose job is support, whose volume justifies queues and SLAs, and whose customers expect a ticket number.
A shared inbox keeps email looking like email to the person writing to you, and adds an owner, a status and internal notes on your side. It suits a team where answering mail is part of everyone’s job rather than the whole job.
The test is your correspondent. A software buyer reads a ticket number as professionalism. A parent, a member or a client of a small firm reads it as being processed by a machine. We went through the six criteria in shared inbox vs help desk. Pick one, say it out loud to the team, and do not change your mind in week three.
One thing to check before you plan anything
If you are on Microsoft 365, note two constraints that will shape the sequence, both documented by Microsoft.
You can convert a user mailbox into a shared mailbox. That is the usual move when the address started as somebody’s personal account. But you cannot migrate a shared mailbox into a Microsoft 365 group. If you think you might want a group later, decide now, because the way back involves rebuilding.
Also worth knowing: a shared mailbox supports a maximum of 25 users, and Microsoft warns of connection failures or duplicated messages beyond that. If you are near that number, the platform is already part of your problem.
The four-week plan
Four weeks is not a technical requirement. It is the time it takes for a habit to change without anyone feeling ambushed.
Week 1: observe, change nothing. Count what actually arrives. How many messages a day, on which addresses, from whom, and how many need a real answer rather than a glance. Write down who currently answers what. Most teams discover here that 60% of the volume is on one address and that one person is quietly handling most of it. That fact will shape everything else.
Week 2: connect, in parallel. Set up the new tool on one address, the busiest one. Do not disconnect anything: the mailbox keeps working exactly as it did, and the team can still use Outlook or Gmail as before. Nobody is required to change. Two or three volunteers use the new tool for real replies and report what is missing.
Two things to verify in this week, before anyone commits. That replies leave from the shared address rather than the individual’s own, which is exactly what Gmail delegation gets wrong: when a delegate sends, their own address appears. And that your history came across, or is at least reachable.
Week 3: switch the habit, keep the escape hatch. The whole team answers from the new tool. The old access stays open, and that matters more than it sounds: a team that cannot fall back will resist, while a team that knows it can fall back rarely does. Introduce exactly one rule, the assignment one: you take a conversation before you answer it. Not statuses, not tags, not notes. One rule.
Week 4: add the second rule, and only the second. Mark conversations done. Now the inbox tells you what remains rather than what has been glanced at. Tags, canned replies and reporting come later, when someone asks for them. A team that gets three new rules at once applies none of them.
Then stop. The most common mistake at this point is to keep configuring.
What actually breaks, and how to avoid it
The history. People assume they will lose it and get anxious. In practice a tool that connects on top of your mailbox syncs what is there and changes nothing at your provider. Say so in week 1, because unspoken, that fear turns into resistance in week 3.
The sending address. The one thing your customers see, and the one that gets discovered late. Send yourself a test from each person’s account in week 2 and read the From line.
Notifications. People used to seeing every message in their personal inbox feel like they have gone deaf. Set notification preferences in week 3, not week 4, and expect the complaint before it arrives.
The person who does not want this. There is usually one, and usually the one who has held the mailbox alone for years. This is not obstruction: a system where they were indispensable is being replaced by one where they are not. Give them the assignment rules to own. It works far better than persuasion.
Everything at once. One address, then the second one a month later. A team can absorb one change at a time and no more.
What not to do
Do not change your email address. Ever, as part of this. A tool that requires it is the wrong tool.
Do not migrate all your addresses on day one. The second address is much easier once the first one has taught you your own edge cases.
Do not do a big-bang cutover on a Monday morning. If it must be one day, make it a Tuesday in a quiet week, never a Monday and never in your busy season.
Do not set up tags before you know what you would filter. Almost every team invents fifteen tags in week one and uses two by month three.
How to tell it worked
Not by adoption statistics. By these three, at the eight-week mark.
Nobody asks “did anyone answer this?” out loud any more. Nothing sits unanswered for three days because each person assumed someone else had it, which is the failure mode nobody counts because nothing visibly goes wrong. And when somebody is away, their conversations are visible and can be picked up without asking them for anything.
If those three hold, the workflow exists. If they do not, adding features will not fix it, and the problem is a rule nobody agreed to.
Where Trupeo fits
Trupeo is the shared inbox end of that choice, not the help desk end. You connect the mailbox you already have, Gmail, Outlook, Microsoft 365 or any IMAP provider, and keep your address. Each person signs in with their own account, so the shared password stops circulating on day one. Each conversation gets one owner, an open or done status, internal notes and tags, and everyone sees when a colleague is already replying.
The parallel-running part is deliberate: the mailbox keeps working normally throughout, so week 2 costs nothing and week 3 has a way back. See the features or our pricing, and our complete shared inbox guide for the wider subject.
Frequently asked questions
How do we move from a group mailbox to a proper workflow without disrupting the team?
Run the new tool in parallel with the existing mailbox rather than cutting over. Start with one address, let two or three people use it for real replies for a week, then move the whole team while leaving the old access open. Introduce one rule at a time: assignment first, then a done status. Four weeks is enough, and the disruption teams fear comes from doing it in one day.
Do we have to change our email address?
No. A shared inbox connects on top of the mailboxes you already have, so your correspondents keep writing to the same address and keep receiving replies from it. Any tool that requires a new address should be ruled out at that point.
Will we lose our email history?
No, when the tool connects to your existing mailbox rather than replacing it. Your mail stays at your provider and the tool syncs what is there. Verify it in your first week with the new tool, before the whole team depends on it.
Should we choose a help desk or a shared inbox?
It depends on what your correspondents expect. A help desk adds ticket numbers, a portal and resolution reporting, which suits a dedicated support team with volume. A shared inbox keeps the exchange looking like normal email while adding an owner and a status on your side, which suits a team where answering mail is part of everyone’s job.
How long does the migration take?
Technically, connecting a mailbox takes minutes. Changing the habit takes about four weeks: one to observe, one in parallel, one to switch with a fallback available, one to add the done status. Teams that try to do it in a day spend longer undoing the resistance it creates.
Sources:
- About shared mailboxes in Microsoft 365: the ability to convert a user mailbox to a shared mailbox, the 25-user maximum, and the warning about connection failures or duplicated messages beyond it.
- Compare types of groups in Microsoft 365: the statement that it is not possible to migrate a shared mailbox to Microsoft 365 Groups, and the stated purpose of each group type.
- Delegate and collaborate on email: what a delegate can and cannot do, and the fact that the delegate’s own email address appears when they send.
- Make a group a Collaborative Inbox: the requirement to enable conversation history before Collaborative Inbox features work, and who can turn them on.