Migrating from Microsoft Exchange Server is one of the most consequential IT projects a business can undertake. Email is the backbone of business communication, and getting the migration wrong can mean downtime, lost data, broken integrations, and staff who cannot do their jobs. Getting it right means a seamless transition that your users barely notice.
The difference between a migration that goes smoothly and one that does not almost always comes down to planning. Businesses that rush into execution without fully understanding their environment, their dependencies, and their cutover requirements are the ones that encounter problems. Those that invest time upfront in a structured planning process tend to deliver on time, on budget, and without disruption.
This guide covers what that planning process should look like, from the initial audit of your Exchange environment through to post-migration monitoring.
Why Businesses Are Migrating From Exchange Server Right Now
Exchange Server migrations are happening at an accelerated rate for one primary reason: Microsoft ended mainstream support for Exchange Server 2019 in October 2025. This means no new security patches, no bug fixes, and no feature updates. Any vulnerability discovered in Exchange Server from that date forward is a permanent, unpatched risk.
Beyond the end-of-support issue, businesses are also migrating because:
- On-premise server maintenance is becoming increasingly expensive and difficult to staff
- Cloud platforms offer collaboration tools that Exchange cannot match, including Teams, SharePoint, and real-time document collaboration
- Cyber insurance providers are increasingly scrutinizing the use of end-of-life software
- Compliance frameworks including Cyber Essentials, ISO 27001, and GDPR require that software is supported and patched
- The predictable monthly cost of cloud licensing is preferable to the unpredictable capital and operational cost of running on-premise infrastructure
For most businesses, the destination is Microsoft 365 or Google Workspace. This guide focuses primarily on migrations to Microsoft 365, though many of the planning principles apply equally to Google Workspace migrations.
Step 1: Assess Your Current Environment Thoroughly
The most common cause of migration problems is an incomplete understanding of the environment being migrated. A thorough assessment before any migration work begins is not optional, it is the foundation everything else is built on.
Mailbox inventory
Document every mailbox in your Exchange environment. This includes user mailboxes, shared mailboxes, room and resource mailboxes, and equipment mailboxes. For each one, record the current size, the owner or responsible party, and whether it is actively used. Mailboxes that belong to former employees or have not been accessed in months should be identified now, before they are migrated across unnecessarily.
Distribution groups and mail-enabled security groups
List every distribution group, dynamic distribution group, and mail-enabled security group. Note the membership of each, who manages it, and whether it includes external contacts. These all need to be recreated or migrated to Microsoft 365 and should be verified post-migration to ensure membership and delivery are correct.
Public folders
Public folders are one of the trickiest elements of an Exchange migration. They are often heavily used, poorly documented, and surprisingly large. Audit all public folders, document their size and content, and make decisions now about whether each one will be migrated, replaced with a SharePoint site or Teams channel, or retired. Leaving this decision until mid-migration creates delays.
Third-party integrations
Identify every application, system, or service that connects to your Exchange environment. This typically includes CRM systems, helpdesk platforms, HR and payroll software, finance systems, backup tools, fax-to-email services, and any custom-built internal applications that send or receive email. Each integration needs to be assessed individually. Some will reconnect automatically to Microsoft 365. Others will require reconfiguration. A few may not be compatible and will need to be replaced or retired.
Active Directory health
Microsoft 365 integrates with on-premise Active Directory via Azure AD Connect (now Microsoft Entra Connect). Before migration, your Active Directory needs to be in good health. Common issues include duplicate user accounts, accounts with incorrect or missing attributes, and UPN suffixes that do not match your email domain. Running the Microsoft Entra Connect health check and the IdFix tool before migration will surface issues that need to be resolved before directory synchronization begins.
DNS records
Document your current DNS configuration, specifically your MX records, SPF record, DKIM records, DMARC record, and Autodiscover CNAME. Understanding your current DNS setup is essential because the cutover from Exchange to Microsoft 365 is fundamentally a DNS change. When you update your MX record to point to Microsoft 365, email starts flowing to the new system. That moment needs to be planned carefully, and the change needs to be executed correctly.
Backup systems
Verify that a full, tested backup of your Exchange environment exists before any migration work begins. This is non-negotiable. If something goes wrong during migration, your backup is the safety net. A backup that has not been verified as restorable is not a backup.
Step 2: Choose Your Migration Path
There are several ways to migrate from Exchange Server to Microsoft 365, and the right approach depends on the size and complexity of your environment.
Cutover migration
In a cutover migration, all mailboxes are migrated to Microsoft 365 in a single batch. This is the simplest approach and is best suited to smaller organizations, typically those with fewer than 150 mailboxes. The migration happens over a defined period, after which the on-premise Exchange server is decommissioned. The main downside is that all users switch to the new system simultaneously, which can create a concentrated support demand around cutover.
Staged migration
In a staged migration, mailboxes are moved to Microsoft 365 in batches over a period of weeks or months. This approach is better suited to larger organizations where moving everyone at once is impractical. Staged migrations allow issues identified early in the process to be resolved before they affect the remaining users.
Hybrid migration
A hybrid configuration connects your on-premise Exchange Server to Microsoft 365, allowing both environments to operate simultaneously and share a common address book, free/busy calendar information, and mail flow. Hybrid migrations are the most flexible approach for larger or more complex environments because they allow mailboxes to be moved individually over time while maintaining a seamless experience for users. They also provide a fallback position if issues are encountered during migration.
For most small and mid-size businesses, a staged or cutover migration to Microsoft 365, with a well-planned pilot phase, is the appropriate approach. Full hybrid configuration adds complexity that is not always warranted.
Step 3: Plan Your Security and Compliance Configuration
Migration is not just a change of where your email is hosted. It is an opportunity to reset your security posture and implement protections that Exchange Server could not provide. Planning this configuration in advance means it is ready before the first live mailbox moves.
Multi-factor authentication
Enable MFA for all users before cutover. Do not migrate mailboxes to a tenant where MFA has not been configured. The approach depends on your plan: Security Defaults (included in all plans) provides a basic MFA baseline, while Conditional Access policies (Business Premium and above) give you full control over when and how MFA is required.
Conditional Access
Configure Conditional Access policies to require MFA for all users and apps, block legacy authentication protocols, and restrict access from unexpected geographic locations. Legacy authentication blocking in particular is critical: protocols like POP, IMAP, and SMTP AUTH bypass MFA entirely and are a common attack vector.
Email security policies
Configure anti-phishing policies, anti-spam policies, and if your plan includes it, Safe Links and Safe Attachments via Microsoft Defender for Office 365. Set up DKIM signing for your domain in the Defender portal, and ensure your SPF and DMARC records are correctly configured before cutover.
Data retention policies
If your business has compliance obligations around email retention, configure Microsoft Purview retention policies before migration. This ensures that retention rules are applied from day one of the new environment rather than being retrofitted later.
Role-based access controls
Review who in your organization needs administrative access to Microsoft 365 and assign the most limited role that allows them to do their job. Avoid assigning Global Administrator rights to anyone who does not specifically need them. Create a small number of dedicated admin accounts that are separate from day-to-day user accounts.
Step 4: Run a Pilot Migration
Before migrating your entire organization, run a pilot with a small, representative group of users. The pilot serves several purposes: it validates your migration approach, surfaces issues before they affect everyone, and gives you a realistic sense of how long the full migration will take.
Choosing your pilot group
Select a pilot group of five to fifteen users that represents the diversity of your organization. Include users with large mailboxes, users who rely heavily on shared mailboxes or public folders, users with mobile devices, and if possible, a member of the IT team who can provide detailed technical feedback. Avoid selecting only technically savvy users who will tolerate issues that a typical user would not.
What to validate during the pilot
- Mail flow. Confirm that email arrives correctly in the new environment and that replies from Microsoft 365 appear correctly to external recipients.
- Calendar and contacts. Verify that calendar events, recurring meetings, and contacts have migrated accurately and that free/busy information is visible to other users.
- Mobile devices. Confirm that Outlook on iOS and Android connects correctly to the new environment and that calendar and contact sync is working.
- Shared mailboxes and distribution groups. Test that shared mailbox access and distribution group delivery are functioning as expected.
- Third-party integrations. For any integrations identified during the assessment phase, verify that they continue to function correctly against the new environment.
- Autodiscover. Confirm that Outlook clients configure automatically when connected to the new tenant.
Document every issue found during the pilot, resolve it, and verify the fix before proceeding to the full migration.
Step 5: Execute the Full Migration
With a successful pilot completed and all identified issues resolved, you are ready to execute the full migration. A few principles apply regardless of the specific migration approach you are using.
Communicate with your staff in advance
Staff should not be surprised by a migration. Send communication well in advance explaining what is changing, what they will need to do (if anything), and who to contact if they experience issues after cutover. Clear, proactive communication dramatically reduces the volume of support requests on cutover day.
Schedule cutover carefully
Plan the DNS cutover for a time that minimizes disruption. For most businesses this means outside of core business hours, typically a Thursday or Friday evening, with the weekend available to address any issues before Monday morning. Avoid scheduling cutovers immediately before major business events, audits, or busy periods.
Monitor in real time during cutover
During the cutover window, monitor mail flow logs, message trace in the Exchange admin center, and DNS propagation. Confirm that inbound email is arriving in Microsoft 365 and that outbound email from the new environment is delivering correctly. Check that Autodiscover is resolving to the new tenant and that Outlook clients are reconfiguring.
Keep rollback plans ready
Before executing the cutover, confirm that you have a documented rollback procedure. If the cutover encounters a critical issue that cannot be resolved quickly, you need to be able to revert DNS to point back at Exchange and restore mail flow while the issue is investigated. A rollback plan that has not been documented and reviewed in advance is not a rollback plan.
Complete the batch migrations
If you are using a staged approach, continue migrating the remaining batches of mailboxes according to your schedule. Maintain active monitoring throughout and address issues as they arise rather than allowing them to accumulate.
Step 6: Post-Migration Activities
The migration is not complete when the last mailbox moves. A defined post-migration phase is essential to ensure the environment is stable, all users are productive, and the old Exchange infrastructure is properly decommissioned.
Verify the environment
Confirm that all migrated mailboxes are accessible and correctly configured. Run message trace tests to verify mail flow in both directions. Check that all distribution groups are delivering correctly. Verify that shared mailboxes have the correct permissions and are accessible to the right users.
Update DNS records
Once mail flow is confirmed in Microsoft 365, update your SPF record to remove the on-premise Exchange server, ensure DKIM is enabled for your domain, and verify that your DMARC record is in place and correctly configured.
Provide user support and training
Have support resources available for the days following cutover. Common user questions involve Outlook reconfiguration, finding emails that were in flight during the cutover, and getting used to the web or mobile interface. For organizations moving to Outlook Online for the first time, short training sessions covering the key differences help staff get productive quickly.
Monitor security alerts
Review the Microsoft Defender portal and Secure Score in the days following migration. Address any new alerts promptly and use Secure Score recommendations to continue improving your security configuration beyond the baseline established during migration.
Decommission Exchange Server
Do not leave your Exchange Server running indefinitely after migration is complete. An active Exchange server still represents an attack surface, and the cost of maintaining it adds no value once the migration is complete. Plan decommissioning as a formal step in the migration project with a target date, not an indefinite postponement.
Common Migration Mistakes to Avoid
Not taking a verified backup before starting. A backup that has not been tested for restorability is not a backup. Verify it before any migration work begins.
Underestimating mailbox sizes and migration time. Large mailboxes take significantly longer to migrate than small ones. Factor this into your timeline, particularly for users with archives or large Sent Items folders.
Ignoring public folders until it is too late. Public folders need decisions made about them before migration, not during it. Leaving them to the last minute consistently causes delays.
Not testing third-party integrations in the pilot. An integration that breaks on cutover day is a major incident. Every integration should be tested during the pilot, not discovered to be broken after the full cutover.
Failing to communicate with staff. Users who are surprised by a migration are users who flood IT support with calls on cutover day. Communicate early, communicate clearly, and set expectations about what to do if something does not work.
Leaving Exchange Server running indefinitely post-migration. Every day an unnecessary Exchange server remains running is a day of unnecessary risk and cost.
Skipping DNS verification before cutover. TTL values, propagation times, and incorrect record formats all cause mail flow issues during cutover. Verify every DNS record before executing the cutover, not after.
The Bottom Line
A successful Exchange migration is not a matter of luck. It is the product of thorough planning, a well-executed pilot, careful DNS management, and clear communication with the people who depend on email to do their jobs.
Businesses that invest time in the planning phases described above consistently deliver migrations that complete on schedule, stay within budget, and cause minimal disruption. Those that skip steps in a rush to execute quickly are the ones that encounter the problems this guide is designed to help you avoid.
Carden IT Services delivers end-to-end Exchange Server migrations to Microsoft 365 and Google Workspace. Fixed price, zero downtime, and a named engineer from assessment to handover. Book a free 20-minute assessment call to get started.