Of all the projects an infrastructure engineer can undertake, migrating an established on-premises Microsoft Exchange environment to Microsoft 365 is one of those jobs where planning really matters.
Email is business-critical.
There are mailboxes, shared mailboxes, distribution groups, mobile devices, Outlook profiles, applications, scanners, SMTP relays, security gateways and numerous other dependencies to consider.
Get it right and most users barely notice anything happened.
Get it wrong and everybody notices.
I’ve been involved in several Exchange migrations, both individually and as part of larger project teams.
One of the largest involved migrating more than 400 active users within the nuclear industry from an on-premises Exchange environment to Microsoft 365.
For obvious security and confidentiality reasons, the organisation will remain anonymous.
🎯 The Project
The organisation operated:
- Two on-premises Microsoft Exchange 2019 servers
- 400+ active users
- No existing Exchange Online mailboxes
- On-premises Active Directory
- Existing email security infrastructure
- Numerous systems and devices using SMTP
- Office 2016 across the user estate
The objective was to migrate the organisation to Exchange Online and Microsoft 365 while minimising disruption to users and maintaining a controlled migration path.
I worked as part of the migration team, with particular responsibility for:
- PowerShell scripting
- Migration planning
- Runbook creation
- Technical procedures
- User communications
- Stakeholder communications
- Supporting migration and post-migration activities
🧭 Choosing the Migration Strategy
Several migration approaches were considered.
Because of the size of the organisation and the need to maintain coexistence during the migration, we selected a Hybrid Exchange migration.
This allowed the on-premises Exchange organisation and Exchange Online to coexist while mailboxes were migrated in controlled batches.
Rather than attempting a high-risk “big bang” migration, users could be moved progressively while the existing Exchange environment remained operational.
For an organisation of this size, that gave us considerably more control.
🔎 Pre-Migration Assessment
Before moving a single production mailbox, we needed to understand exactly what we were dealing with.
And with any Exchange environment that’s been operating for years, there are usually a few surprises waiting for you.
📦 Mailbox Sizes
Mailbox sizes were one of the first areas we examined.
PowerShell scripts were created to report on the Exchange environment and identify mailboxes requiring attention before migration.
This allowed us to identify oversized mailboxes and work with users before their migration batch was scheduled.
- Removing unnecessary mail
- Clearing deleted items
- Reviewing large attachments
- Archiving older content
- Identifying unusually large mailboxes
The important thing was to identify these problems before migration day, not during it.
🗄️ Cleaning Up the Exchange Databases
The existing Exchange environment had been operational for a considerable period.
Over time, Exchange databases can accumulate whitespace as mailboxes are created, moved and deleted.
Rather than simply migrating from the existing databases and ignoring their condition, we decided to clean up the environment first.
After ensuring appropriate backups were available, the existing databases were assessed.
We ultimately elected to create new Exchange databases and move the active mailboxes into them.
This gave us much cleaner source databases containing the mailboxes we actually intended to migrate.
It also gave us another opportunity to identify problematic mailboxes before introducing Microsoft 365 into the equation.
☁️ Preparing Microsoft 365
While the Exchange environment was being prepared, the Microsoft 365 tenant also needed to be made ready.
Directory synchronisation was configured between the on-premises Active Directory environment and Microsoft Entra ID.
This allowed the existing user identities to be synchronised into Microsoft 365 rather than creating an entirely separate identity environment.
We verified that:
- Users synchronised correctly
- User attributes were correct
- Required email attributes were present
- Password synchronisation was functioning
- Microsoft 365 identities matched the on-premises users
- Required domains were configured and verified
Only when we were confident in the identity synchronisation did we proceed towards mailbox migration.
🎫 Automating Microsoft 365 Licensing
With more than 400 users, assigning licences manually wasn’t something we wanted to turn into an ongoing administrative task.
Instead, we used group-based licensing.
Security groups were created for the appropriate licence requirements, with Microsoft 365 licences assigned through those groups.
When an appropriate user was added to the relevant group, the required Microsoft 365 licence could be assigned automatically.
This wasn’t just useful during the migration. It improved the organisation’s ongoing user provisioning process after the project had finished.
📬 Migrating the Mailboxes
Once identity synchronisation, licensing and the hybrid configuration had been validated, mailbox migrations began.
Rather than migrating everybody simultaneously, users were moved in controlled migration batches.
This gave us the ability to:
- Monitor migration performance
- Identify problematic mailboxes
- Control the load on the Exchange environment
- Manage internet bandwidth
- Communicate with affected users
- Resolve issues before subsequent batches
Because the source mailboxes were on-premises, internet upload capacity was an important consideration.
Fortunately, the organisation had a good connection.
The bulk transfer of mailbox data to Exchange Online was completed in approximately three days.
🌐 DNS and Mail Flow
Getting mailbox data into Microsoft 365 is only part of an Exchange migration.
The next critical stage was making sure mail actually went where it was supposed to go.
DNS and mail-flow configuration had to be carefully reviewed and updated.
- MX records
- Autodiscover
- SPF
- DKIM
- DMARC
- Mail connectors
- TLS requirements
- Mimecast integration
- Internal DNS where required
This was one of the critical stages of the project.
After the changes were made, we immediately tested mail flow in both directions.
- ✔ External → Microsoft 365: Mail received successfully
- ✔ Microsoft 365 → External: Mail delivered successfully
- ✔ Internal mail flow: Working correctly
- ✔ Security gateway / connector routing: Operating as expected
At this stage, monitoring was particularly important. If a significant mail-flow problem had appeared, we needed to know about it immediately.
Fortunately, everything behaved as planned.
🔐 Improving Email Security
The project wasn’t simply about moving exactly what existed on-premises into the cloud.
It was also an opportunity to improve the organisation’s security posture.
We configured and reviewed technologies including:
- Multi-Factor Authentication (MFA)
- Conditional Access
- SPF
- DKIM
- DMARC
- Secure mail connectors
- TLS requirements
- Email security gateway integration
Moving to Microsoft 365 gave us an opportunity to modernise both the email platform and the controls protecting user accounts.
💻 Upgrading Office at the Same Time
The organisation was still running Office 2016.
Since users were moving onto Microsoft 365, we used the project as an opportunity to modernise the desktop Office applications as well.
Scripts were created to automate the process.
The deployment workflow removed the legacy Office installation and installed the required Microsoft 365 Apps configuration.
Automating this was particularly important when dealing with hundreds of endpoints.
Where users had unusual requirements or additional Office components, those exceptions were handled individually through the normal service desk process.
🖨️ The Things People Forget About: Printers and SMTP
User mailboxes weren’t the only things sending email.
There were also multifunction printers, scanners and other devices using the existing Exchange environment as an SMTP service.
These sorts of dependencies are very easy to overlook during an email migration.
Some older devices required additional work, including firmware updates and configuration changes, before they could use an appropriate supported method of sending mail through the new environment.
Each device and application therefore had to be identified, tested and migrated appropriately.
It’s a good example of why an Exchange migration is rarely just an Exchange migration.
📢 Communication Was Part of the Technical Project
One lesson I’ve learned from migrations is that technical success isn’t enough.
Users need to know:
- What’s happening
- When it’s happening
- Whether they need to do anything
- What will look different
- Who to contact if something doesn’t work
As part of my role in the project, I produced user and stakeholder communications alongside the technical runbooks.
That helped ensure the service desk, technical teams, stakeholders and end users understood what was happening during each stage of the migration.
Good communication can prevent a technically successful migration from becoming a support nightmare the following morning.
🔎 Post-Migration Monitoring
We didn’t switch everything off the moment the last mailbox reached Microsoft 365.
The existing Exchange environment remained in place while the new platform was monitored and outstanding dependencies were addressed.
We continued checking:
- Mail flow
- Outlook connectivity
- Mobile devices
- Shared mailboxes
- SMTP devices
- Applications
- Security controls
- Microsoft Teams
- Microsoft 365 services
Any remaining issues were dealt with before decommissioning was considered.
🗑️ Decommissioning the Legacy Environment
After approximately two months of successful operation without significant migration-related issues, we were satisfied that the new environment was stable.
Only then did we move towards decommissioning the legacy infrastructure.
The remaining Exchange dependencies were reviewed and the appropriate Microsoft 365 and hybrid configuration was finalised before the old infrastructure was retired.
Decommissioning was treated as a project stage in its own right, rather than simply switching off the old Exchange servers.
🏆 The Result
The migration was successfully completed.
More than 400 users were moved from the on-premises Exchange 2019 environment to Microsoft 365.
- ✔ Exchange Online
- ✔ Microsoft 365 Apps
- ✔ Microsoft Teams integration
- ✔ Multi-Factor Authentication
- ✔ Conditional Access
- ✔ Improved email authentication with SPF, DKIM and DMARC
- ✔ Automated licence assignment
- ✔ Reduced dependency on on-premises Exchange infrastructure
- ✔ A modernised Microsoft 365 environment
Most importantly, users were able to continue working throughout the migration with minimal disruption.
💡 What Did This Project Reinforce?
Large migrations aren’t successful because somebody knows which button to press in the Exchange Admin Centre.
They’re successful because of the work that happens before and around the migration.
- Planning.
- Scripting.
- Testing.
- Documentation.
- Communication.
- Monitoring.
- Rollback planning.
With hundreds of users relying on email to do their jobs, you don’t want to be designing the migration plan while you’re performing the migration.
Prepare carefully, automate what you can, test everything and never underestimate the value of a good runbook.
