Migration Exchange Server 2016 to Exchange Subscription Edition (SE) -

Last Updated: January 13, 2026 | Reading Time: 45 minutes | Difficulty: Advanced | Target Audience: IT Administrators

Introduction to Exchange Server Legacy Migration

This comprehensive manual provides detailed, step-by-step instructions for IT administrators executing a Legacy Upgrade from an existing Exchange Server 2016 organization to Exchange Server Subscription Edition (SE). The migration strategy involves installing new Exchange SE servers into your existing environment, methodically migrating all services and data, and performing a clean decommissioning of legacy 2016 servers. This approach ensures a controlled and seamless transition with minimal disruption to end-users.

Table of Contents – Migration Phases

Phase I: Pre-Migration Planning and Initial Deployment

1.1 Strategic Overview of Exchange Server Subscription Edition

Before initiating deployment, a thorough understanding of Exchange Server Subscription Edition (SE) is imperative. As the successor to Exchange Server 2019, SE introduces a new licensing model and serves as the definitive on-premises messaging platform. A firm grasp of its core characteristics is fundamental to a successful migration plan.

Key Exchange Server SE Specifications:

Release and Build: Exchange Server SE was released on July 1, 2025, with RTM build number 15.2.2562.17
Migration Path from 2016: Requires a Legacy upgrade (installing new SE servers alongside existing 2016 servers)
Codebase: SE RTM contains no significant code changes compared to Exchange 2019 CU15
Support Lifecycle: Exchange 2016 CU23 support ends October 14, 2025
Licensing Model: Subscription-based requiring active Software Assurance (SA) or Microsoft 365 E3

1.2 Validating Environmental Prerequisites for Exchange SE Migration

Validating that your environment meets all system and software requirements is a critical first step. Overlooking these prerequisites is a common cause of installation failures and subsequent troubleshooting delays.

Active Directory Requirements

Functional Level: Minimum Domain Functional Level and Forest Functional Level is Windows Server 2012 R2

Existing Exchange Organization Requirements

Server Version: All existing Exchange servers must run minimum Exchange 2016 CU23

Client Requirements

Outlook Version: Minimum supported client version is Outlook 2016

New Server Hardware and Operating System

RAM: Minimum 128 GB recommended (functionality confirmed with 32 GB)
Operating System: Windows Server 2019, 2022, or 2025 (Standard/Datacenter, Desktop Experience or Server Core)
Disk Formatting: System and Exchange binaries use NTFS; Mailbox Databases use NTFS or ReFS
Paging File: Set minimum and maximum to 25% of total installed memory

Software Prerequisites – Must Install Before Exchange Setup:

1.3 Preparing Active Directory for Exchange Server SE

Before the first Exchange SE server can be installed, the Active Directory schema and domain must be extended to support it. While the Exchange installation wizard can perform these steps automatically with sufficient permissions, executing them manually from the command line offers greater control and visibility.

Active Directory Preparation Commands:

Run these commands from an elevated command prompt with access to Exchange SE installation media:

Extend AD Schema: Updates schema with new classes and attributes. Wait for forest-wide replication.
Prepare AD Forest: Creates necessary containers, objects, and universal security groups (USGs).
Prepare All Domains (Optional): Run for each domain hosting Exchange recipients or servers.

1.4 Installing the Exchange Server SE Mailbox Role

The installation of the first Exchange SE server into your existing 2016 organization is performed using the graphical setup wizard. The wizard automatically detects the existing organization and adds the new server to it.

Installation Wizard Steps:

Initiate Setup: Run setup.exe from mounted installation media
File Copy: Installer copies files to temporary local disk location
License Agreement: Review and accept software license terms
Recommended Settings: Choose usage data sharing preferences
Server Role Selection: Select Mailbox role (Management Tools included automatically)
Installation Location: Specify path (default: C:\Program Files\Microsoft\Exchange Server\V15)
Malware Protection: Enable or disable built-in scanning (modifiable post-installation)
Readiness Checks: Wizard verifies prerequisites and AD preparations
Installation: Process takes approximately 16 minutes on prepared servers
Restart: Reboot server to finalize installation

Critical: After installing Exchange on a server, the server name must NOT be changed.

1.5 Initial Post-Installation Configuration

After the first server is installed, several configuration steps are necessary to license it and ensure administrators can manage it correctly within the co-existence environment.

Verifying Server Version

Verify the new server’s addition using Exchange Management Shell (EMS):

Get-ExchangeServer | FT Name, Edition, AdminDisplayVersion -AutoSize

Accessing Exchange Server SE Admin Center (EAC)

In co-existence environments, administrators with mailboxes on Exchange 2016 servers will be redirected to the old EAC. Force the new Exchange SE EAC by appending the parameter:

https://<Exchange Server SE>/ecp/?ExchClientVer=15.2

Entering the Product Key

Recommended Method: Use PowerShell via Exchange Management Shell to set the product key (EAC method may fail with “Invalid Product Key” error).

After setting the key, restart the Microsoft Exchange Information Store service.

Phase II: Configuring Core Services and Security

2.1 Defining the Client Access Namespace Strategy

This phase establishes the configuration of Client Access Namespaces, which are the URLs that clients use to connect to Exchange services. A well-defined and consistent namespace strategy across both old and new servers is critical for simplifying user experience, managing SSL certificates, and enabling seamless final cutover.

Recommended Namespace Design (Split DNS Configuration):

Server FQDNs: SRV1.virgilsecureinfo.local, SRV2.virgilsecureinfo.local (internal, not for client use)
Primary SMTP Namespace: virgilsecureinfo.com (primary email domain)
Virtual Service Address: mail.virgilsecureinfo.com, mail.virgilsecureinfo.local (all primary client access services)
Autodiscover: autodiscover.firma.cz (CNAME or A record pointing to mail service)
OWA Download Domain: maildownload.virgilsecureinfo.com (mitigates CVE-2021-1730)

The key strategic benefit is using a virtual DNS A record containing IP addresses of all production Exchange servers, providing simple load distribution and straightforward final cutover (requires only updating IP addresses in single DNS record).

2.2 Implementing and Assigning SSL Certificates

SSL certificates are critical for encrypting communications between clients and servers. A newly installed Exchange server uses a self-signed certificate by default, which is not trusted by client devices, causing Outlook clients to receive trust warnings via Autodiscover.

Certificate Deployment Process:

Request Certificate: Use certlm.msc console for control and visibility. Specify Common Name (e.g., mail.virgilsecureinfo.com) and add all required hostnames to Subject Alternative Name (SAN) field.
Assign Services in EAC: Navigate to Servers > Certificates. Select certificate, click Edit, and assign to Exchange services: IMAP, POP, IIS, and SMTP.

2.3 Configuring Client Access Virtual Directories

Client access in Exchange is handled by a set of virtual directories within Internet Information Services (IIS), each corresponding to a specific protocol or service. Configure internal and external URLs on the new Exchange SE server to match existing servers for consistent client experience.

Virtual Directory	Service Name	Function
mapi	MAPI over HTTP	Primary connection protocol for modern Outlook clients
owa	Outlook on the web	Web browser-based mailbox access
Microsoft-Server-ActiveSync	Exchange ActiveSync (EAS)	Mobile device synchronization
AutoDiscover	Autodiscover	Automatic client profile configuration
ecp	Exchange Admin Center (EAC)	Web-based management interface
EWS	Exchange Web Services	API for Outlook for Mac, Free/Busy, Out of Office
OAB	Offline Address Book	Distribution point for OAB
PowerShell	Remote PowerShell	Remote management via PowerShell

PowerShell Configuration Script:

$s = "SRV1"
$urlI = "mail.virgilsecureinfo.local"
$urlE = "mail.virgilsecureinfo.com"
Get-MapiVirtualDirectory -Server $s | Set-MapiVirtualDirectory -InternalUrl https://$urlI/mapi -ExternalUrl https://$urlE/mapi
Get-OwaVirtualDirectory -Server $s | Set-OwaVirtualDirectory -InternalUrl https://$urlI/owa -ExternalUrl https://$urlE/owa
Get-ActiveSyncVirtualDirectory -Server $s | Set-ActiveSyncVirtualDirectory -InternalUrl https://$urlI/Microsoft-Server-ActiveSync -ExternalUrl https://$urlE/Microsoft-Server-ActiveSync
Get-EcpVirtualDirectory -Server $s | Set-EcpVirtualDirectory -InternalUrl https://$urlI/ecp -ExternalUrl https://$urlE/ecp
Get-WebServicesVirtualDirectory -Server $s | Set-WebServicesVirtualDirectory -InternalUrl https://$urlI/EWS/Exchange.asmx -ExternalUrl https://$urlE/EWS/Exchange.asmx
Get-OabVirtualDirectory -Server $s | Set-OabVirtualDirectory -InternalUrl https://$urlI/OAB -ExternalUrl https://$urlE/OAB
Get-PowerShellVirtualDirectory -Server $s | Set-PowerShellVirtualDirectory -InternalUrl https://$urlI/powershell -ExternalUrl https://$urlE/powershell
Get-ClientAccessService -Identity $s | Set-ClientAccessService -AutoDiscoverServiceInternalUri https://$urlI/Autodiscover/Autodiscover.xml

Outlook Anywhere Configuration (Backward Compatibility):

Set-OutlookAnywhere -Identity "SRV1\Rpc (Default Web Site)" -ExternalHostname "mail.virgilsecureinfo.com" -InternalHostname "mail.virgilsecureinfo.local" -InternalClientAuthenticationMethod Negotiate -ExternalClientAuthenticationMethod Negotiate

Verification Step:

Test access to new server’s OWA and ECP URLs directly from browser using ?ExchClientVer=15.2 parameter (e.g., https://mail1.virgilsecureinfo.local/owa/?ExchClientVer=15.2). Confirm pages load without certificate errors.

2.4 Configuring Mail Flow Connectors

Mail flow into and out of the Exchange organization is managed by Receive Connectors and Send Connectors. During migration, the objective is to configure connectors on the new server to mirror the existing environment and add the new server as an active transport source.

Receive Connectors

A new Exchange server installation creates five default Receive Connectors. Settings on these connectors (message size limits, logging levels) must be configured to match corresponding connectors on existing Exchange 2016 servers to ensure consistent behavior.

Best Practice: Use PowerShell to compare connector properties on old and new servers to identify and reconcile differences. Use the Set-ReceiveConnector cmdlet to apply necessary changes.

Send Connectors

Send Connectors are configured organization-wide, not per-server. The only required action is to add the new Exchange SE server as a source server for outbound mail flow.

Perform this in the EAC under Mail Flow > Send Connectors. Edit each relevant Send Connector, navigate to the Scoping tab, and add the new server to the list of Source servers.

Phase III: Establishing Data Management and High Availability

3.1 Managing Mailbox Databases

Upon installation, a new Exchange server has a single, default mailbox database on the system drive. This configuration is not suitable for production environments. This phase covers essential tasks of renaming, relocating, and configuring databases for production use.

Database Management Tasks for Each Exchange SE Server:

Rename the Default Database: Use Exchange Management Shell (EMS) to assign a descriptive name aligning with established naming conventions.
Move Database and Log Paths: Critical best practice to move database file (.edb) and transaction logs to separate, dedicated drives. This improves performance and recoverability. Use Move-DatabasePath cmdlet in EMS. Database will be temporarily dismounted during this operation.
Create New Databases: Create additional databases using EAC (Servers > Databases > New). After creating a new database, restart the Microsoft Exchange Information Store service.
Configure Database Limits: For each new database, configure appropriate mailbox size limits (IssueWarningQuota, ProhibitSendQuota) and assign an Offline Address Book.

Troubleshooting Note: MapiExceptionTooManyMountedDatabases

Exchange Server Standard edition is limited to a maximum of 5 mounted databases per server. Attempting to mount a sixth database will result in this error.

3.2 Building the New Database Availability Group (DAG)

A Database Availability Group (DAG) is Exchange’s native technology for providing high availability and site resilience. It operates by replicating databases between member servers. Because all members of a DAG must be the same version of Exchange, a new DAG must be created for Exchange SE servers.

DAG Creation and Configuration Steps:

Prepare the Witness Server: A DAG requires a Witness Server to maintain quorum. On the chosen server, add the Exchange Trusted Subsystem domain security group to the server’s local Administrators group.
Create the DAG: In the EAC, navigate to Servers > Database Availability Groups and create a new DAG. Specify a unique name for the DAG and the FQDN of the Witness Server. Leave the IP address field blank to create a modern, IP-less DAG.
Add Servers to the DAG: Once the DAG object is created, add the new Exchange SE servers as members.
Configure DAG Networks: Best practice is to isolate replication traffic on a dedicated network for performance and security. First enable manual DAG network configuration in the DAG’s properties in the EAC. Then, for the network designated for MAPI traffic, select the Disable Replication option.

3.3 Adding and Validating Database Copies

The final step in establishing high availability is to create passive copies of mailbox databases on other member servers within the new DAG. This is accomplished in the EAC under Servers > Databases by selecting the database and using the Add database copy action.

Troubleshooting Note: Failed Seeding Operations

The initial seeding operation to create a database copy may fail. Even if an error is displayed, the process often successfully creates the copy but leaves it in a Failed and Suspended state. This can typically be resolved by right-clicking the new passive copy in the EAC and selecting the Update action to re-initiate the seeding process.

Verify Replication Health:

After adding database copies, use the Test-ReplicationHealth cmdlet in EMS to verify DAG health and replication status for all database copies on all member servers:

Test-ReplicationHealth

With the new, highly-available Exchange SE infrastructure fully configured and validated, the project can now proceed to the critical phase of migrating user and system data.

Phase IV: Executing the Mailbox Migration

4.1 Migration Strategy and Critical Prerequisites

This phase initiates the migration of mailboxes from legacy Exchange 2016 servers to the new Exchange SE infrastructure. This operation, known as a “Move Request,” is an online process handled by the Mailbox Replication Service (MRS) that allows users to remain connected with minimal disruption.

Microsoft Recommended Move Order:

System Mailboxes (Arbitration mailboxes)
User Mailboxes
Public Folder Mailboxes

Critical Prerequisite – Transaction Log Space

A mailbox move generates a large volume of transaction logs on the target database, with log volume roughly equivalent to the size of content being moved. Sufficient disk space on the transaction log drive is absolutely critical. If the drive runs out of space during a migration batch, the database will dismount, causing an outage for all users on that database.

4.2 Step 1: Moving System Mailboxes

System (or arbitration) mailboxes store organization-wide data and must be moved to the new servers first to ensure the new environment is fully functional.

Arbitration Mailboxes

List all arbitration mailboxes and move them to Exchange SE servers:

# List arbitration mailboxes
Get-Mailbox -Arbitration

# Move a specific arbitration mailbox
New-MoveRequest -Identity "SystemMailbox{guid}" -TargetDatabase "DB01-SE"

Audit Log Mailbox

# List the audit log mailbox
Get-Mailbox -AuditLog

# Move the audit log mailbox
New-MoveRequest -Identity "Audit Log Mailbox" -TargetDatabase "DB01-SE"

Discovery Search Mailbox

# List the discovery search mailbox
Get-Mailbox -Filter {Name -like "DiscoverySearchMailbox*"}

# Move the discovery search mailbox
New-MoveRequest -Identity "DiscoverySearchMailbox{guid}" -TargetDatabase "DB01-SE"

4.3 Step 2: Moving User Mailboxes

User mailboxes can be moved individually, in batches by database, or via a CSV file, using either the EAC or EMS.

PowerShell Commands for Migration Planning:

# Count mailboxes per database
Get-Mailbox | Group-Object -Property Database | Select Name, Count

# List mailboxes and their sizes
Get-Mailbox -ResultSize Unlimited | Get-MailboxStatistics | Select DisplayName, Database, TotalItemSize

Two Primary Methods for Executing Moves:

Method 1: Using EAC (Migration Batch)

The EAC provides a wizard-driven process under Recipients > Migration. Create a “Migration Batch” to move selected users or a list from a CSV to a target database.

Method 2: Using EMS (Move Request)

PowerShell offers more granular control and is ideal for scripting large moves:

# Move all mailboxes from a specific database
Get-Mailbox -Database "DB01-2016" | New-MoveRequest -TargetDatabase "DB01-SE"

# Move specific users
New-MoveRequest -Identity "[email protected]" -TargetDatabase "DB01-SE"

# Move mailboxes from CSV file
Import-CSV C:\mailboxes.csv | New-MoveRequest -TargetDatabase "DB01-SE"

Monitor Progress and Cleanup:

# Check status
Get-MoveRequest | Get-MoveRequestStatistics

# Remove completed requests
Get-MoveRequest -MoveStatus Completed | Remove-MoveRequest -Confirm:$false

4.4 Step 3: Moving Public Folder Mailboxes

Since Exchange 2013, public folders are stored in special Public Folder Mailboxes. Migrating the public folder hierarchy involves moving these mailboxes to a database on an Exchange SE server. This operation must be performed using EMS.

# List PF mailboxes and their sizes
Get-Mailbox -PublicFolder | Get-MailboxStatistics | Select DisplayName, Database, TotalItemSize

# Move a single PF mailbox
New-MoveRequest -Identity "PublicFolderMailbox" -TargetDatabase "DB01-SE"

# Move all PF mailboxes from a specific server
Get-Mailbox -PublicFolder -Server "MAIL0" | New-MoveRequest -TargetDatabase "DB01-SE"

4.5 Decommissioning Legacy Databases

After confirming all mailboxes have been moved off the old Exchange 2016 databases, those databases can be safely removed. For a database that is part of a DAG, this is a two-step process:

Remove Database Copies: All passive copies must be removed first. In the EAC (Servers > Databases), select the passive copy and click Remove. After the removal operation completes, manually delete the database and transaction log files from the disk on the server that hosted the copy.
Remove the Active Database: Once only the empty active database remains, it can be deleted using the trash can icon in the EAC. After removal, manually delete the database and transaction log files from the disk on the server.

With all data migrated and legacy databases removed, the final phase involves redirecting all live traffic to the new servers and formally removing the old servers from the organization.

Phase V: Final Cutover and Decommissioning

5.1 Redirecting Production Communication

This is the final cutover step, where all client access traffic and mail flow are redirected from the legacy Exchange 2016 servers to the new Exchange SE servers.

Client Access Redirection:

Internal Traffic: Update the internal DNS A record for the shared virtual namespace (e.g., mail.virgisecureinfo.com) to remove IP addresses of old servers and contain only IPs of new servers.
External Traffic: Update firewall policies (e.g., NAT rules) to point to the new servers.

Mail Flow Redirection:

Inbound SMTP: Same process as Client Access (DNS/Firewall updates)
Outbound SMTP: Edit the organization’s Send Connectors and change the Source server selection to include only the new Exchange SE servers.

Alternative Cutover Strategy:

IP Address Change Method: Assign the new servers the original IP addresses of the old servers. If using this method, it is crucial to run ipconfig /flushdns on all other Exchange servers in the organization.

5.2 Updating the Exchange Hybrid Configuration

For environments using Exchange Hybrid, the Hybrid Configuration Wizard (HCW) must be re-run to update the configuration to use the new Exchange SE servers for mail flow and other hybrid services.

Hybrid Configuration Update Process:

Download the latest version of the HCW
Run the HCW on one of the new Exchange SE servers
During the wizard, select the new servers in the Receive Connector and Send Connector configuration pages

5.3 Decommissioning the Legacy Exchange 2016 Environment

Once all traffic is flowing through the new SE servers and operations are stable, the legacy 2016 environment can be formally decommissioned.

Decommissioning Steps:

1. Perform Final Checks

Place the original servers into Maintenance Mode for a period to ensure no services are still relying on them
Use the Microsoft Remote Connectivity Analyzer to validate that external services are working correctly and connecting to the new servers

2. Remove the Original DAG

Remove all server members from the legacy DAG, then delete the now-empty DAG object itself using the EAC.

3. Uninstall Exchange Server 2016

The recommended method is to run from an elevated command line:

Setup.exe /mode:Uninstall

Troubleshooting Common Uninstallation Issue:

An “Access is denied” error during the language pack removal step is common. If this occurs, restart the server and re-run the uninstallation from the command line. This typically resolves the issue.

5.4 Final Post-Migration Cleanup

Perform the following final cleanup tasks to fully remove traces of the old servers:

Remove the original server objects from the backup solution
Verify the old server computer accounts have been removed from AD groups (e.g., Exchange Servers)
Verify the old server objects have been removed from the Exchange organization configuration using ADSI Edit
Delete the old server computer accounts from Active Directory
Decommission and delete the virtual machines of the old servers

Conclusion: Successful Exchange Server SE Migration

Congratulations on the successful migration of your organization to Exchange Server Subscription Edition!

This comprehensive process—involving careful planning, parallel configuration, methodical data migration, and clean decommissioning—has positioned your organization on Microsoft’s modern, supported on-premises messaging platform.

Ongoing Maintenance Recommendations:

Regular Patching Schedule: Establish a schedule for Exchange Cumulative Updates
Health Monitoring: Regularly run the Exchange Health Checker script to proactively identify and address potential configuration issues
Performance Monitoring: Monitor database performance, mail flow metrics, and client connectivity
Security Updates: Stay current with security patches and best practices
Backup Validation: Ensure backup solutions are properly configured for the new SE environment

This ensures the long-term performance, security, and stability of your new messaging infrastructure.