Support for Exchange Server 2016 and 2019 ended on October 14, 2025. The servers did not stop working the very next day, but organizations using these versions must decide what to do next: migrate to Exchange Online, upgrade their environment to Exchange Server Subscription Edition, or treat the Extended Security Update (ESU) as a temporary solution.
ESU can give companies additional time to develop a plan to transition away from unsupported systems, but it is not a long-term solution. Beyond the ESU, Microsoft will no longer provide standard technical support, hotfixes, or security updates for Exchange 2016 and 2019.
For many companies, migrating Exchange to Microsoft 365 is the natural next step. However, the decision to move email to the cloud alone does not solve the most important problem: how to carry out the migration without disrupting users’ work or the operation of email-dependent applications, while also avoiding maintaining the old environment longer than necessary.
Three approaches most commonly appear in materials on migration: cutover, staged, and hybrid. However, these are not three equivalent options. Staged is now mainly of historical significance; cutover works well in specific small environments; and hybrid encompasses several scenarios—ranging from a simplified Express migration to an extended coexistence period.
ESU can give companies additional time to develop a plan to transition away from unsupported systems, but it is not a long-term solution. Beyond the ESU, Microsoft will no longer provide standard technical support, hotfixes, or security updates for Exchange 2016 and 2019.
For many companies, migrating Exchange to Microsoft 365 is the natural next step. However, the decision to move email to the cloud alone does not solve the most important problem: how to carry out the migration without disrupting users’ work or the operation of email-dependent applications, while also avoiding maintaining the old environment longer than necessary.
Three approaches most commonly appear in materials on migration: cutover, staged, and hybrid. However, these are not three equivalent options. Staged is now mainly of historical significance; cutover works well in specific small environments; and hybrid encompasses several scenarios—ranging from a simplified Express migration to an extended coexistence period.
End of Support for Exchange 2016 and 2019: Migration Isn't the Only Option
Migrating to Exchange Online simplifies email management. The organization is no longer responsible for updating Exchange servers, ensuring their high availability, managing certain backup mechanisms, scaling infrastructure capacity, or securing publicly accessible services.
However, this does not mean that Microsoft 365 will automatically be the cheapest option in every case. The decision should take into account current infrastructure and administration costs, the number and type of users, retention and archiving requirements, integrations with applications that use on-premises Exchange, regulatory requirements, the identity management model, and the services included in current or planned licenses.
An alternative remains Exchange Server Subscription Edition. For organizations that, for technical, regulatory, or business reasons, need to store some of their email locally, this can serve as either a target model or a component of a hybrid architecture.
Therefore, the right question isn't simply, „The cloud or on-premises infrastructure?” First, you need to determine what email and identity management model will be in place once the project is complete.
However, this does not mean that Microsoft 365 will automatically be the cheapest option in every case. The decision should take into account current infrastructure and administration costs, the number and type of users, retention and archiving requirements, integrations with applications that use on-premises Exchange, regulatory requirements, the identity management model, and the services included in current or planned licenses.
An alternative remains Exchange Server Subscription Edition. For organizations that, for technical, regulatory, or business reasons, need to store some of their email locally, this can serve as either a target model or a component of a hybrid architecture.
Therefore, the right question isn't simply, „The cloud or on-premises infrastructure?” First, you need to determine what email and identity management model will be in place once the project is complete.
Cutover, staged, and hybrid—how do they differ in practice?
Cutover: The Entire Organization in a Single Switchover
In a cutover migration, all mailboxes are migrated in a single pass, along with selected mail objects: contacts, mail users, and mail-enabled groups. After data synchronization, services are switched over, the relevant DNS records are updated, and email traffic is redirected to Exchange Online.
Typically, the technical limit for a cutover is about 2,000 mailboxes at a time, but a reasonable limit for a single IT team supporting users is a maximum of about 150. This difference is not a minor caveat. The technical limit specifies how many mailboxes the cutover mechanism and scripts can handle. It does not answer the question of whether the IT team can simultaneously handle users logging back into their new accounts, configuring Outlook and mobile devices, resolving Autodiscover issues, making changes to email-sending applications, and addressing post-cutover support requests.
A cutover is a good choice for a small, relatively simple organization that wants to migrate its entire environment quickly and does not need an extended coexistence period. However, you should not choose this method simply because the number of mailboxes falls within the technical limit.
Typically, the technical limit for a cutover is about 2,000 mailboxes at a time, but a reasonable limit for a single IT team supporting users is a maximum of about 150. This difference is not a minor caveat. The technical limit specifies how many mailboxes the cutover mechanism and scripts can handle. It does not answer the question of whether the IT team can simultaneously handle users logging back into their new accounts, configuring Outlook and mobile devices, resolving Autodiscover issues, making changes to email-sending applications, and addressing post-cutover support requests.
A cutover is a good choice for a small, relatively simple organization that wants to migrate its entire environment quickly and does not need an extended coexistence period. However, you should not choose this method simply because the number of mailboxes falls within the technical limit.
Staged: formerly the default path
Staged migration (according to Microsoft) involved moving users in batches. The classic approach was designed for Exchange Server 2003 and 2007; it was not intended for Exchange 2010 or later versions.
Today, its importance is even less significant. Microsoft will discontinue Staged OutlookAnywhere onboarding on May 8, 2025. Organizations that have not completed the process by that date must use a different method, such as hybrid remote onboarding.
This is important because many older comparisons still present "staged" as a fully-fledged alternative. In a new project, you should not assume that it is available simply because it appears in archived documentation. If an organization is still using Exchange 2003 or 2007, the first step should be to determine the supported migration path, rather than automatically planning for a staged migration.
Today, its importance is even less significant. Microsoft will discontinue Staged OutlookAnywhere onboarding on May 8, 2025. Organizations that have not completed the process by that date must use a different method, such as hybrid remote onboarding.
This is important because many older comparisons still present "staged" as a fully-fledged alternative. In a new project, you should not assume that it is available simply because it appears in archived documentation. If an organization is still using Exchange 2003 or 2007, the first step should be to determine the supported migration path, rather than automatically planning for a staged migration.
Hybrid: Phased Migration and a Controlled Coexistence Period
A hybrid migration connects an on-premises Exchange organization with Exchange Online. Mailboxes can be migrated in batches, and for a specified period, some users operate on-premises while others operate in the cloud.
This allows you to break down the migration by department, location, or group. Issues detected in the first batches do not immediately affect the entire company, and the team can correct the configuration before moving on to the next phase.
The hybrid model offers the most possibilities, but it also requires the most preparation. Among other things, the organization must ensure that Exchange is running the correct version and is up to date, that the Hybrid Configuration Wizard is properly configured, that Autodiscover is functioning correctly, public certificates, the availability of required services and endpoints, identity synchronization with Microsoft Entra ID, and proper email flow between environments. Microsoft also specifies the requirement for the current or immediately preceding CU or RU applicable to the version of Exchange being used.
„Hybrid” does not automatically mean "risk-free migration" or a guaranteed absence of downtime. However, it does allow for better control over the order in which users are migrated and helps limit the impact of a single issue on the entire organization.
This allows you to break down the migration by department, location, or group. Issues detected in the first batches do not immediately affect the entire company, and the team can correct the configuration before moving on to the next phase.
The hybrid model offers the most possibilities, but it also requires the most preparation. Among other things, the organization must ensure that Exchange is running the correct version and is up to date, that the Hybrid Configuration Wizard is properly configured, that Autodiscover is functioning correctly, public certificates, the availability of required services and endpoints, identity synchronization with Microsoft Entra ID, and proper email flow between environments. Microsoft also specifies the requirement for the current or immediately preceding CU or RU applicable to the version of Exchange being used.
„Hybrid” does not automatically mean "risk-free migration" or a guaranteed absence of downtime. However, it does allow for better control over the order in which users are migrated and helps limit the impact of a single issue on the entire organization.
What about Express (Minimal Hybrid)?
Microsoft also describes "Minimal Hybrid," referred to as "Express Migration." This is a simplified hybrid option for organizations that want to migrate mailboxes in a relatively short period of time and do not plan to have the environments coexist for an extended period.
In practice, therefore, the choice isn’t always simply „cutover or full hybrid.” For a smaller but more modern environment, Express may be a more reasonable path than a classic cutover. However, its feasibility and appropriateness must be assessed based on the Exchange version, the identity model, and the state of the source environment.
In practice, therefore, the choice isn’t always simply „cutover or full hybrid.” For a smaller but more modern environment, Express may be a more reasonable path than a classic cutover. However, its feasibility and appropriateness must be assessed based on the Exchange version, the identity model, and the state of the source environment.
Comparison of Exchange Migration Methods
| Criterion | Cutover | Staged | Hybrid |
|---|---|---|---|
| Main Application | Migrating an Entire Small Organization | Legacy Exchange 2003/2007 environments | Phased migration and coexistence period |
| Scale | Technically up to 2,000, but in practice usually up to about 150 mailboxes at a time for a single IT support team | Legacy method | Medium, large, and complex environments |
| Migration Method | The entire organization in a single project | User groups | User groups with environment integration |
| Coexistence | Limited | Limited | Extensive |
| Directory Synchronization | Dependent on the target identity model | Required in the classic scenario | Usually required |
| Impact on Users | Focused on the switchover | Broken down into stages | Broken down into the following groups |
| Technical complexity | Lowest | Inadequate for new projects | Highest |
| Status in New Projects | Possible in certain environments | It should not be scheduled by default | The most common option for complex organizations |
The project timeline is not determined by the method’s name alone. The schedule is more often determined by the volume of data, connection bandwidth, the number of integrations, the health of Active Directory, public folders, archives, and how user devices are managed.
When to use a cutover, and when to use a hybrid
This is a practical decision in most projects today—we're phasing out "staged" as a legacy approach.
Cutover This is worth considering when an organization has relatively few mailboxes, wants to migrate everything at once, and does not need to maintain a long-term coexistence with the local Exchange server. The environment should be as simple as possible.
The more public folders, business applications, non-standard connectors, archives, and mail-sending devices there are, the less significant the number of users becomes. A company with 80 mailboxes and several dozen integrations may face a more challenging project than an organization with 250 users that relies almost exclusively on standard Exchange features.
During a cutover, the risk is concentrated at a single point. Any errors immediately affect a large part of the organization, which is why it is so important to test DNS, Autodiscover, licenses, clients, and message flow before the actual switchover.
Hybrid It’s the natural choice when migration is to be carried out in phases or when you need to maintain mailboxes both locally and in the cloud simultaneously for a certain period of time. The most common arguments in favor of a hybrid approach include several hundred or more mailboxes, multiple branches and teams, department-by-department migration, a complex Active Directory, public folders and archives, a large number of applications integrated with email, the need for a pilot project, and regulatory requirements.
Instead of migrating everyone at once, you can start with the IT team, move on to a pilot group, and only after confirming that the migration was successful, migrate the other departments.
Cutover This is worth considering when an organization has relatively few mailboxes, wants to migrate everything at once, and does not need to maintain a long-term coexistence with the local Exchange server. The environment should be as simple as possible.
The more public folders, business applications, non-standard connectors, archives, and mail-sending devices there are, the less significant the number of users becomes. A company with 80 mailboxes and several dozen integrations may face a more challenging project than an organization with 250 users that relies almost exclusively on standard Exchange features.
During a cutover, the risk is concentrated at a single point. Any errors immediately affect a large part of the organization, which is why it is so important to test DNS, Autodiscover, licenses, clients, and message flow before the actual switchover.
Hybrid It’s the natural choice when migration is to be carried out in phases or when you need to maintain mailboxes both locally and in the cloud simultaneously for a certain period of time. The most common arguments in favor of a hybrid approach include several hundred or more mailboxes, multiple branches and teams, department-by-department migration, a complex Active Directory, public folders and archives, a large number of applications integrated with email, the need for a pilot project, and regulatory requirements.
Instead of migrating everyone at once, you can start with the IT team, move on to a pilot group, and only after confirming that the migration was successful, migrate the other departments.
Not sure if your environment qualifies for a cutover, Express, or full hybrid?
During the 30-minute consultation, we’ll go over your Exchange version, the number of mailboxes, your identity model, and key integrations. The result is a recommendation for a specific path forward, not just another list of methods.
What to Consider Before Choosing a Method
Problems during migration rarely stem from the data transfer itself. Most complications arise from dependencies that were not taken into account at the outset.
Exchange and Active Directory status. We check the exact versions, installed updates, the organization’s topology, the number of domains and forests, and the health of AD replication. An environment that has not been updated for a long time may require preparation even before the actual migration.
Identity and directory synchronization. You must decide whether users will remain synchronized with the on-premises AD after migration or whether they will ultimately be managed exclusively in the cloud. This decision affects Entra Connect or Cloud Sync, recipient management, and the ability to later remove the last Exchange server.
Integrations and SMTP. Email is sent not only by Outlook, but also by ERP systems, accounting applications, monitoring systems, scanners, multifunction printers, web forms, and helpdesks. Each of these connections must be inventoried and assigned to a target authentication method or relay.
Public folders, archives, and shared mailboxes. They have their own migration requirements and often contain significantly more data than standard mailboxes. Omitting them from the estimate affects both the schedule and the choice of method.
DNS, certificates, and email flow. Before the switchover, the following are checked, among other things: MX records, Autodiscover, SPF, DKIM, DMARC, connectors, and transport rules. Simply changing the MX records does not complete the project.
Data volume and bandwidth. Two organizations with the same number of mailboxes may require completely different schedules. Factors that matter include the average mailbox size, the number of large archives, the performance of the source environment, and the actual data transfer rate.
Exchange and Active Directory status. We check the exact versions, installed updates, the organization’s topology, the number of domains and forests, and the health of AD replication. An environment that has not been updated for a long time may require preparation even before the actual migration.
Identity and directory synchronization. You must decide whether users will remain synchronized with the on-premises AD after migration or whether they will ultimately be managed exclusively in the cloud. This decision affects Entra Connect or Cloud Sync, recipient management, and the ability to later remove the last Exchange server.
Integrations and SMTP. Email is sent not only by Outlook, but also by ERP systems, accounting applications, monitoring systems, scanners, multifunction printers, web forms, and helpdesks. Each of these connections must be inventoried and assigned to a target authentication method or relay.
Public folders, archives, and shared mailboxes. They have their own migration requirements and often contain significantly more data than standard mailboxes. Omitting them from the estimate affects both the schedule and the choice of method.
DNS, certificates, and email flow. Before the switchover, the following are checked, among other things: MX records, Autodiscover, SPF, DKIM, DMARC, connectors, and transport rules. Simply changing the MX records does not complete the project.
Data volume and bandwidth. Two organizations with the same number of mailboxes may require completely different schedules. Factors that matter include the average mailbox size, the number of large archives, the performance of the source environment, and the actual data transfer rate.
Modern Auth and SMTP AUTH: The deadline is not „March 2026”
Most Basic Authentication mechanisms in Exchange Online have already been disabled—for Outlook, EWS, POP, IMAP, Exchange ActiveSync, Autodiscover, and Remote PowerShell. The exception is Basic Authentication in SMTP AUTH, which is often used by applications, multifunction devices, and legacy messaging systems.
The original deadline has been changed several times. According to the current schedule, SMTP AUTH Basic Authentication will remain in place until the end of December 2026. After that, it will be disabled by default for existing tenants, though administrators will still be able to enable it. Microsoft is expected to announce the final removal date in the second half of 2027.
That’s no reason to postpone the integration upgrade. Rather, it’s an argument for not including in the plan the outdated assumption that all connections based on Basic Auth will stop working in March 2026.
During the assessment, it is important to separately identify email clients, applications that use EWS/POP/IMAP, systems that use SMTP AUTH, devices that send email, and applications that use the local Exchange relay.
The original deadline has been changed several times. According to the current schedule, SMTP AUTH Basic Authentication will remain in place until the end of December 2026. After that, it will be disabled by default for existing tenants, though administrators will still be able to enable it. Microsoft is expected to announce the final removal date in the second half of 2027.
That’s no reason to postpone the integration upgrade. Rather, it’s an argument for not including in the plan the outdated assumption that all connections based on Basic Auth will stop working in March 2026.
During the assessment, it is important to separately identify email clients, applications that use EWS/POP/IMAP, systems that use SMTP AUTH, devices that send email, and applications that use the local Exchange relay.
Migrating the last mailbox doesn't always mark the end of the project
Once all mailboxes have been migrated, the question arises of what to do with the on-premises Exchange server. You should not shut down the server the very next day. If your organization continues to synchronize users with the on-premises Active Directory, the on-premises environment may remain the source for certain mail attributes.
Microsoft offers several supported options for continued management: keeping the server, using Exchange Management Tools, or migrating the data source and Exchange attribute management to the cloud.
Once the Source of Authority has been properly transferred, the on-premises Exchange server no longer needs to be maintained solely for the purpose of managing recipients. The target administrative model must be planned before migration. Otherwise, the project will end up in a situation where all mailboxes are in the cloud, but the organization continues to maintain a local server without a clearly defined role.
Once the Source of Authority has been properly transferred, the on-premises Exchange server no longer needs to be maintained solely for the purpose of managing recipients. The target administrative model must be planned before migration. Otherwise, the project will end up in a situation where all mailboxes are in the cloud, but the organization continues to maintain a local server without a clearly defined role.
What Factors Determine the Cost of an Exchange Migration?
The cost of an Exchange migration consists of several components.
Microsoft 365 or Exchange Online Licenses – Their level depends not only on the capacity of the mailboxes, but also on security, archiving, retention, audit, and compliance requirements.
Preparation of the environment – Updating Exchange, reorganizing Active Directory, fixing synchronization issues, or replacing certificates can be a significant part of a project, even though they don’t yet involve migrating any mailboxes.
Migration Implementation – configuration of tenants, domains, policies, identities, connectors, batches, and piloting. In complex environments, this also includes third-party tools and work on public folders, archives, and applications.
Stabilization After Switching – user support, bug fixes, monitoring email traffic, and disabling unnecessary infrastructure components.
Therefore, pricing based solely on the number of mailboxes can be misleading. The number of users is important, but it does not reflect the state of Active Directory, the number of integrations, or the complexity of the architecture.
What a migration project from ISCG might look like
The project should begin with an assessment, not with the creation of the first migration batch.
- Environmental Assessment – Exchange versions, updates, number and types of mailboxes, archives, public folders, domains, certificates, and integrations.
- Target Architecture Design – migration method, identity model, recipient management approach, email flow, and plan for phasing out the on-premises environment.
- Preparation and Pilot Testing – configuration of tenants, synchronization, domains, policies, and connectors. The initial migration will involve a controlled test group, ideally consisting of IT users and representatives of several job profiles.
- Production Migration – a single handoff or subsequent phases, with verification of incoming and outgoing email, clients, calendars, delegations, and applications at every stage.
- Stabilization and Closure – monitoring the environment, resolving issues, managing DNS, and securely decommissioning on-premises Exchange components.
To get started, we need information about the Exchange version, the number of mailboxes, the Active Directory model, public folders, archives, and the systems that use email. This is enough to prepare an initial recommendation on the methodology and scope of further analysis.
An Exchange migration should result in a target management model, not just a data transfer.
Schedule a 30-minute consultation—we’ll assess the environment, outline the right path forward, and identify risks that could affect the timeline.
Frequently Asked Questions (FAQ)
The technical limit is approximately 2,000 mailboxes, but Microsoft recommends a number not exceeding approximately 150—due to the capacity of a single IT support team, the time required to create users, and data migration. The choice of method should also be based on integrations, data volume, and the ability to support users after the switchover.
The classic staged method was designed for Exchange 2003 and 2007. Microsoft discontinued Staged OutlookAnywhere onboarding in May 2025, so in a new project, you must specify a different supported approach, most often based on hybrid mechanisms.
Hybrid allows you to migrate users in stages and typically minimizes the project’s impact on the entire organization, but it does not guarantee that there will be no issues. Users may be asked to restart Outlook, log in, or refresh their settings after the mailbox migration is complete.
No. A small number of mailboxes does not automatically mean a simple environment. With multiple integrations, large archives, a complex Active Directory, or the need for a phased migration, the Express or hybrid option is often the safer choice.
Not always. First, you need to determine where the source of Exchange attributes will be located after migration and how users synchronized from the on-premises AD will be managed. Microsoft provides supported management options that do not require an active Exchange server, but these require proper preparation.
A simple cutover can be completed in a few days, but a full project also includes assessment, tenant preparation, testing, DNS configuration, and stabilization. A hybrid migration typically takes anywhere from a few weeks to several months. The duration depends mainly on the volume of data, bandwidth, the number of integrations, and the state of the source environment.
Summary
There is no single best method for migrating Exchange to Microsoft 365—there is a right approach for each specific scale, architecture, and state of the source environment. Cutover works well for small, simple organizations that want to migrate everything at once—but even here, success depends not on the number of mailboxes, but on the number of integrations, the state of Active Directory, and the capabilities of the support team. Staged migration is now mainly of historical significance: following the discontinuation of Staged OutlookAnywhere onboarding in May 2025, it should not be planned by default for new projects. Hybrid—ranging from the simplified Express model to full coexistence—offers the greatest control over the sequence and pace of migration, but also requires the most preparation: from the latest Cumulative Update (CU), through identity synchronization, to public certificates and proper email flow between environments.
There is one common factor: migration begins with an assessment, not with the first batch. The Exchange version, identity model, public folders, archives, SMTP integrations, and the on-premises server retirement plan—these are the factors that shape the timeline and cost more than the number of mailboxes alone. A project that overlooks these factors at the outset usually has to make up for them along the way—at the expense of time, budget, and user patience.
Are you planning an Exchange migration? We’d be happy to start by reviewing your environment—including the version, scale, integrations, and identity model—to outline a specific path forward, rather than just another list of methods.
There is one common factor: migration begins with an assessment, not with the first batch. The Exchange version, identity model, public folders, archives, SMTP integrations, and the on-premises server retirement plan—these are the factors that shape the timeline and cost more than the number of mailboxes alone. A project that overlooks these factors at the outset usually has to make up for them along the way—at the expense of time, budget, and user patience.
Are you planning an Exchange migration? We’d be happy to start by reviewing your environment—including the version, scale, integrations, and identity model—to outline a specific path forward, rather than just another list of methods.
Do you want to understand your options first after Exchange support ends?
Contact us—we’ll respond within one business day with an initial assessment and a recommendation for the next step.
Learn about our other services
Business applications
Services for applications and turnkey solutions in the area of process digitization and modern work environment.
Full support and optimization of IT infrastructure, ensuring stable development of your business.
IT infrastructure
Security of deployment and maintenance of Microsoft 365 and Azure services that enable flexible management and cost optimization.
