Tenant Migration Email Address: 3 Hidden Truths 3 Hidden Truths Consultants Know
There is a moment in almost every tenant migration project where some in the room, usually a senior stake holder, sometimes a department head, ask the question with the quiet confidence of someone who already knows t he answer.
“So the email addresses stay the same, right?”
The rooms shifts slightly. The engineers glance at each other. The project manager opens their mouth and then closes it again. Ant the consultant, who has heard this question across a dozen different projects in a dozen different countries, takes a breath and begins to explain something that is much harder to explain than it should be.
That moment is where this article begins
The Question That Changes Everything
Every project has its version of this conversation. The settings changes. Somethimes it is a workshop in a glass-walled conference romm in Amsterdam, sometimes it is a Teams call with six squares and someone’s cat walking across the keyboard. But the dynamic is always the same.
The business side has been told a migration is happening. The have approved the budget. They have signed off on the timeline. And someone somewhere in the briefing, the topic of email came up and someone summarized it as “users will be moved to the new environment.”
What that summary left out is that email in a tenant migration is not moved. It is recreated. In a new tenant, under a new domain, with a new address, at least temporarily. And what happens to the address after the depends on a chain of business decisions that the technical team is waiting on, often weeks into a project that has already started.
The tenant migration email address question is never just a technical question. That is the first thing experienced consultants learn. It is a legal question, a brand question, a communications question, and sometime a political one. Bty the time it lands on the engineer’s desk, it has already passed through several rooms where it should have been resolved.
What a Tenant Migration Email Address Transition actually looks like
The 3 Hidden Options No One Tells you About Upfront
Most stakeholders assume there is one way to handle email during migration. There are three. Each one has consequences that extend well beyond the technical team.
The first option is forwarding. During the migration period, any email sent to the user’s new address. The user keeps working in their old environment until cutover. After cutover, that forwarding is removed or reversed. This is the most commonly used approach because it is most transparant to the user. They do not need to check two inboxes. They do not need to manage two identities. The complexity lives in the configuration, not in their day.
The second option is coexistence with address rewriting. This is where the engineering gets sophisticated. When a user in the source tenant sends an email, the sending address is autmatically rewritten to their new target address before it reaches the recipient. From the outside world. the user is already operation under their new address, even though they are still working from the old environment. Replies come back to the new address. Signatures reflect the new brand. The transition is invinsible externally while still being technically in-progress internally. This approach is used when there is a hard business requirement that the new email address must be live from a specific date, usually tied to a merger announcement or a rebrand launch.
The third option is doing noting. The migration happens. Cutover lands. Users wake up with a new email address and any mail sent to the old one is forwarded from source to target post-migration. This is the fastest to configure and the hardest on users. It works in some scenarios. it causes real problems in others.
The choice between these three is not a technical preference. It is a direct function of what the business has decided, and when they decided it.
Carve-Outs: When You Can Keep the Address You Have
A carve-out migration is its own category of project. The organization being separated from its parent is not joining someone else’s environment. It is a starting fresh. Building a new tenant from the ground up. And in that scenario, the question of the tenant migration email address has one variable that mergers rarely have: the organization might own its domain outrights.
In one project spanning multiple countries accross Europe, the organization being carved out was keeping its own name. It had operated under that name, with that domain, for years. And when we sat down to plan the migration, one of the cleaner path available was a domain transfer at cutover. Stand up the new tenant with a temporary domain variation, something workable for the build phase, and then transfer the actual domain across when the cutover window opened.
From the outside world, nothing changed. Users kept the email address they had always had. The migration was invisible in the way every migration aspires to be.
But there is what that narative leaves out: not every location was part of the carve-out.
Some users at some sites remained with the parent company. And those users were sitting in the same domain. Before the domain could be transferred to the new tenant, those users needed their email address to be changed to the parent company’s own domain, their new home now that the separation was complete. That meant two workstreams running in parallel. One preparing the new environment. one transitioning the users who were staying behind.
The domain tranfer could only happen after both workstreams were complete. And neither could start untill the legal structuren of the carve-out was confirmed enough to know which sites were in scope and which were not.
This is what a carve-out actually looks like from the inside, A migration project that cannot move forward until a corporate legal process resolves itself. Engineers waiting. Timelines shifting. And a simple question, who keeps the domain, carrying months of dependency behind it.
Mergers: When the Addres Becomes a Business Decision, Not a Technical One
Mergers are different. In a merger, there is rarely a question of whether the domain will transfer. The aquiring company’s domain is the acquiring company’s identity. The acquired organization is, by definition, joining that identity.
What gets complicated is the gap between when the deal closes and when the rebrand is finalized.
In one project, a country-level organization had been acquired. The migration into the acquiring company’s tenant was scoped and ready to begin planning. The first question the business stakeholders raised was whether users could keep their existing .com domain. The answer was no. That domain was the primary address for tens of thousands of users at the source company globally. It was not transferable.
They asked about an alternative domain. A variation. Something that would signal continuity. That request was also declined, because the organization was going to be fully rebranded under a new name. Using the old domain in any form was inconsistent with that direction.
The problem was that the new brand name had not been finalized yet.
So the project began with a temporary domain that everyone in the room knew was not the permanent answer. We configured forwarding from the target to the source to make sure email sent to the temporary address found its way to users who were still working in the old environment. It worked. No email was lost, No users were stranded.
But they ended up communicating the email address change twice. Once when the final rebrand name was confirmed and the permanent address was set. Every customer, every supplier, every partner contact received two rounds of “our email address has changed” notifications.
That is not a migration failure. The technical execution was sound. But it is a consequence, a very visible and very external one, of a business decision that arrived late.
The Human Side of Cutover That Gets Forgetten
The goal, in every migration, is that the user barely notices.
Email history intact. Calendar meetings still here. Contacts accessible. OneDrive files in place. That is the promises of modern migration tooling and, when it is delivered, it represents an enourmous amount of quiet engineering that no one in the business will ever think to acknowledge.
The moment users actually notice is cutover. That is when a new device arrives, or a device needs to re-enrolled, or Outlook prompts for credentials it has never seen before. That moment is not always avoidable. But its shape is entirely defined by decisions made weeks or months earlier.
Will devices be re-enrolled to comply with the new tenant’s security policy? Will the existing device be migrated through tooling that handles workspace continuity? Will users receive a new device as part of the transition? THese are not engineering questions by the time they surface in a migration project. THey are outcomes of IT strategy, endpoint management policy, and sometimes collective bargaining agreements in regions where device ownership is sensitive topic.
What you tell users to expect depends entirely on what has been decided. And the worst version of a cutover is one where users were told one thing and experience another. Not because anyone lied, but because the desicion changed after the communication went out.
Migration fatigue in organizations is real. Users who have livd through a previous migration, or who have heard stories from colleagues at other companies, arrive at cutover with anxiety that has been building for weeks. The email question is often the anchor of that anxiety. Will I lose my emails? Will people still be able to reach me? Will I lose track of something important while this is happening?
Those questions deserve real answers early. Giving them requires that the business has made the decisions that make answers possible.
Why the desicion Must Happen Before the Project Does
In years of running these projects, the single most consistent source of delay is not technical. It is a business desicion that has not been made.
The rebranding question is the most common. Is a rebrand happening? If so, what is the new name? What will the email convention be? When will it be confirmed?
Coexistence configuration cannot be finalized without this information. The engineering team can build the infrastructure. They can run parallel workstreams. But they cannot configure address rewrite for the domain that does not exist yet.
the day 0 require the next most common. Some mergers carry a legal or communications requirement that from the moment the transaction closes, all users must appear externaaly under the acquiring company’s email address. That is a coexistence requirement. And the coexistence takes time to design, test, and validate. It cannot be introduced two weeks before the deal closes.
Domain ownership is a question that sometimes surfaces embarrassingly late. Who actually owns the domain? Is it registered to the entity being carved out? Can it be transferred, or does the transfer require consent from a party that is no longer cooperative? These are not IT questions. They are legal and commercial questions that belong in the M&A workstream, not in the technical migration plan.
The stakeholders who have the authority to make these decisions and the marketing teams who understand what an uncoordinated emails change look like to the outside world both need to be in the room before the project kickoff. Not at the kickoff. Before it.
When they are not, organizations often find themselves in the position of communicating the same change twice. Once with the temporary answer, and once with the real one. Every customer, every partner, every supplier receives that second message and wonders why the first one was not right. That erosion of confidence is quiet, but it accumulates. And it is entirely avoidable.
Tooling, Trust, and the EWS Deadline Approaching in 2026
Microsoft does not have a native, end-to-end tenant migrations solutions. This is not a secret, but it surprises people who assume that because Microsoft 365 is the product, Microsoft has built the tool the tools to move between instances of it.
What Microsoft provides is a set of APIs, configuration capabilities, and scripting options that a skilled engineering team can assemble into a working migration pipeline. if requires building your own reporting layer, typically Power BI or Microsoft Fabric, and significant ongoing scripting effort to handle edge cases that puprpose-built tools handles out of the box.
Third-pary platforms, such as Quest, BitTitan, and AvePoint exist specifically to solve this problem. They bring tested workflows, compliance documentation, built-in reporting, and in many cases in ability to migrate between different mail platforms entirely, not just Microsoft to Microsoft. For organizations running a complex migration with coexistence requirements, these tools are not a preference. They are a practical necessity.
There is, however, a significant technical shift approaching that every organization in migration planning needs to understand.
Exchange Web Services (EWS) is being deprecated by Microsoft 2026. Many coexistence solutions in the market rely on EWS for the address rewriting and mail flow management that makes today rely on EWS for the address rewriting and mail flow management that makes transparant coexistence possible. When EWS goes away, those solutions will need to have rebuilt their coexistence architecture on Microsoft Graph. The vendor who have done that work will be in a strong position. The vendor who have not will face a difficult window.
Microsoft graph is the right long-term architecture. The transition is the right direction. But what i means in practice for migration timelines, for coexistence feature parity, and for tool availability in months around that October 2026 deadline is something no one can fully predict yet. Organizations planning migrations that involve coexistence and extend into late 2026 should be asking their tooling vendors directly about their Graph roadmap today. Not when the project starts. Now
You can find more details on EWS deprecation in Microsoft’s official Exchange documentation
