{"id":677,"date":"2026-10-06T13:30:15","date_gmt":"2026-10-06T12:30:15","guid":{"rendered":"https:\/\/www.mrpaulclarke.co.uk\/?page_id=677"},"modified":"2026-10-06T17:29:55","modified_gmt":"2026-10-06T16:29:55","slug":"case-study-migrating-400-users-from-exchange-2019-to-microsoft-365","status":"publish","type":"page","link":"https:\/\/www.mrpaulclarke.co.uk\/?page_id=677","title":{"rendered":"Case Study – Migrating 400+ Users from Exchange 2019 to Microsoft 365"},"content":{"rendered":"\r\n

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<\/strong>.<\/p>\r\n\r\n\r\n\r\n

Email is business-critical.<\/p>\r\n\r\n\r\n\r\n

There are mailboxes, shared mailboxes, distribution groups, mobile devices, Outlook profiles, applications, scanners, SMTP relays, security gateways and numerous other dependencies to consider.<\/p>\r\n\r\n\r\n\r\n

\r\n

Get it right and most users barely notice anything happened.<\/p>\r\n

Get it wrong and everybody notices.<\/strong><\/p>\r\n<\/blockquote>\r\n\r\n\r\n\r\n

I’ve been involved in several Exchange migrations, both individually and as part of larger project teams.<\/p>\r\n\r\n\r\n\r\n

One of the largest involved migrating more than 400 active users within the nuclear industry<\/strong> from an on-premises Exchange environment to Microsoft 365.<\/p>\r\n\r\n\r\n\r\n

For obvious security and confidentiality reasons, the organisation will remain anonymous.<\/p>\r\n\r\n\r\n\r\n

\r\n\r\n\r\n\r\n

🎯 The Project<\/h2>\r\n\r\n\r\n\r\n

The organisation operated:<\/p>\r\n\r\n\r\n\r\n

    \r\n
  • Two on-premises Microsoft Exchange 2019 servers<\/li>\r\n
  • 400+ active users<\/li>\r\n
  • No existing Exchange Online mailboxes<\/li>\r\n
  • On-premises Active Directory<\/li>\r\n
  • Existing email security infrastructure<\/li>\r\n
  • Numerous systems and devices using SMTP<\/li>\r\n
  • Office 2016 across the user estate<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n

    The objective was to migrate the organisation to Exchange Online and Microsoft 365<\/strong> while minimising disruption to users and maintaining a controlled migration path.<\/p>\r\n\r\n\r\n\r\n

    I worked as part of the migration team, with particular responsibility for:<\/p>\r\n\r\n\r\n\r\n

      \r\n
    • PowerShell scripting<\/li>\r\n
    • Migration planning<\/li>\r\n
    • Runbook creation<\/li>\r\n
    • Technical procedures<\/li>\r\n
    • User communications<\/li>\r\n
    • Stakeholder communications<\/li>\r\n
    • Supporting migration and post-migration activities<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n
      \r\n\r\n\r\n\r\n

      🧭 Choosing the Migration Strategy<\/h2>\r\n\r\n\r\n\r\n

      Several migration approaches were considered.<\/p>\r\n\r\n\r\n\r\n

      Because of the size of the organisation and the need to maintain coexistence during the migration, we selected a Hybrid Exchange migration<\/strong>.<\/p>\r\n\r\n\r\n\r\n

      This allowed the on-premises Exchange organisation and Exchange Online to coexist while mailboxes were migrated in controlled batches.<\/p>\r\n\r\n\r\n\r\n

      Rather than attempting a high-risk “big bang” migration, users could be moved progressively while the existing Exchange environment remained operational.<\/p>\r\n\r\n\r\n\r\n

      For an organisation of this size, that gave us considerably more control.<\/p>\r\n\r\n\r\n\r\n

      \r\n\r\n\r\n\r\n

      🔎 Pre-Migration Assessment<\/h2>\r\n\r\n\r\n\r\n

      Before moving a single production mailbox, we needed to understand exactly what we were dealing with.<\/p>\r\n\r\n\r\n\r\n

      And with any Exchange environment that’s been operating for years, there are usually a few surprises waiting for you.<\/p>\r\n\r\n\r\n\r\n

      📦 Mailbox Sizes<\/h3>\r\n\r\n\r\n\r\n

      Mailbox sizes were one of the first areas we examined.<\/p>\r\n\r\n\r\n\r\n

      PowerShell scripts were created to report on the Exchange environment and identify mailboxes requiring attention before migration.<\/p>\r\n\r\n\r\n\r\n

      This allowed us to identify oversized mailboxes and work with users before their migration batch was scheduled.<\/p>\r\n\r\n\r\n\r\n

        \r\n
      • Removing unnecessary mail<\/li>\r\n
      • Clearing deleted items<\/li>\r\n
      • Reviewing large attachments<\/li>\r\n
      • Archiving older content<\/li>\r\n
      • Identifying unusually large mailboxes<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n

        The important thing was to identify these problems before migration day, not during it.<\/strong><\/p><\/blockquote>\r\n\r\n\r\n\r\n

        🗄️ Cleaning Up the Exchange Databases<\/h3>\r\n\r\n\r\n\r\n

        The existing Exchange environment had been operational for a considerable period.<\/p>\r\n\r\n\r\n\r\n

        Over time, Exchange databases can accumulate whitespace as mailboxes are created, moved and deleted.<\/p>\r\n\r\n\r\n\r\n

        Rather than simply migrating from the existing databases and ignoring their condition, we decided to clean up the environment first.<\/p>\r\n\r\n\r\n\r\n

        After ensuring appropriate backups were available, the existing databases were assessed.<\/p>\r\n\r\n\r\n\r\n

        We ultimately elected to create new Exchange databases and move the active mailboxes into them<\/strong>.<\/p>\r\n\r\n\r\n\r\n

        This gave us much cleaner source databases containing the mailboxes we actually intended to migrate.<\/p>\r\n\r\n\r\n\r\n

        It also gave us another opportunity to identify problematic mailboxes before introducing Microsoft 365 into the equation.<\/p>\r\n\r\n\r\n\r\n

        \r\n\r\n\r\n\r\n

        ☁️ Preparing Microsoft 365<\/h2>\r\n\r\n\r\n\r\n

        While the Exchange environment was being prepared, the Microsoft 365 tenant also needed to be made ready.<\/p>\r\n\r\n\r\n\r\n

        Directory synchronisation was configured between the on-premises Active Directory environment and Microsoft Entra ID.<\/p>\r\n\r\n\r\n\r\n

        This allowed the existing user identities to be synchronised into Microsoft 365 rather than creating an entirely separate identity environment.<\/p>\r\n\r\n\r\n\r\n

        We verified that:<\/p>\r\n\r\n\r\n\r\n

          \r\n
        • Users synchronised correctly<\/li>\r\n
        • User attributes were correct<\/li>\r\n
        • Required email attributes were present<\/li>\r\n
        • Password synchronisation was functioning<\/li>\r\n
        • Microsoft 365 identities matched the on-premises users<\/li>\r\n
        • Required domains were configured and verified<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n

          Only when we were confident in the identity synchronisation did we proceed towards mailbox migration.<\/p>\r\n\r\n\r\n\r\n

          \r\n\r\n\r\n\r\n

          🎫 Automating Microsoft 365 Licensing<\/h2>\r\n\r\n\r\n\r\n

          With more than 400 users, assigning licences manually wasn’t something we wanted to turn into an ongoing administrative task.<\/p>\r\n\r\n\r\n\r\n

          Instead, we used group-based licensing<\/strong>.<\/p>\r\n\r\n\r\n\r\n

          Security groups were created for the appropriate licence requirements, with Microsoft 365 licences assigned through those groups.<\/p>\r\n\r\n\r\n\r\n

          When an appropriate user was added to the relevant group, the required Microsoft 365 licence could be assigned automatically.<\/p>\r\n\r\n\r\n\r\n

          This wasn’t just useful during the migration. It improved the organisation’s ongoing user provisioning process after the project had finished.<\/strong><\/p><\/blockquote>\r\n\r\n\r\n\r\n

          \r\n\r\n\r\n\r\n

          📬 Migrating the Mailboxes<\/h2>\r\n\r\n\r\n\r\n

          Once identity synchronisation, licensing and the hybrid configuration had been validated, mailbox migrations began.<\/p>\r\n\r\n\r\n\r\n

          Rather than migrating everybody simultaneously, users were moved in controlled migration batches<\/strong>.<\/p>\r\n\r\n\r\n\r\n

          This gave us the ability to:<\/p>\r\n\r\n\r\n\r\n

            \r\n
          • Monitor migration performance<\/li>\r\n
          • Identify problematic mailboxes<\/li>\r\n
          • Control the load on the Exchange environment<\/li>\r\n
          • Manage internet bandwidth<\/li>\r\n
          • Communicate with affected users<\/li>\r\n
          • Resolve issues before subsequent batches<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n

            Because the source mailboxes were on-premises, internet upload capacity was an important consideration.<\/p>\r\n\r\n\r\n\r\n

            Fortunately, the organisation had a good connection.<\/p>\r\n\r\n\r\n\r\n

            The bulk transfer of mailbox data to Exchange Online was completed in approximately three days<\/strong>.<\/p><\/blockquote>\r\n\r\n\r\n\r\n

            \r\n\r\n\r\n\r\n

            🌐 DNS and Mail Flow<\/h2>\r\n\r\n\r\n\r\n

            Getting mailbox data into Microsoft 365 is only part of an Exchange migration.<\/p>\r\n\r\n\r\n\r\n

            The next critical stage was making sure mail actually went where it was supposed to go.<\/p>\r\n\r\n\r\n\r\n

            DNS and mail-flow configuration had to be carefully reviewed and updated.<\/p>\r\n\r\n\r\n\r\n

              \r\n
            • MX records<\/li>\r\n
            • Autodiscover<\/li>\r\n
            • SPF<\/li>\r\n
            • DKIM<\/li>\r\n
            • DMARC<\/li>\r\n
            • Mail connectors<\/li>\r\n
            • TLS requirements<\/li>\r\n
            • Mimecast integration<\/li>\r\n
            • Internal DNS where required<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n

              This was one of the critical stages of the project.<\/p>\r\n\r\n\r\n\r\n

              After the changes were made, we immediately tested mail flow in both directions.<\/p>\r\n\r\n\r\n\r\n

                \r\n
              • ✔ External \u2192 Microsoft 365:<\/strong> Mail received successfully<\/li>\r\n
              • ✔ Microsoft 365 \u2192 External:<\/strong> Mail delivered successfully<\/li>\r\n
              • ✔ Internal mail flow:<\/strong> Working correctly<\/li>\r\n
              • ✔ Security gateway \/ connector routing:<\/strong> Operating as expected<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n

                At this stage, monitoring was particularly important. If a significant mail-flow problem had appeared, we needed to know about it immediately.<\/p>\r\n\r\n\r\n\r\n

                Fortunately, everything behaved as planned.<\/p>\r\n\r\n\r\n\r\n

                \r\n\r\n\r\n\r\n

                🔐 Improving Email Security<\/h2>\r\n\r\n\r\n\r\n

                The project wasn’t simply about moving exactly what existed on-premises into the cloud.<\/p>\r\n\r\n\r\n\r\n

                It was also an opportunity to improve the organisation’s security posture.<\/p>\r\n\r\n\r\n\r\n

                We configured and reviewed technologies including:<\/p>\r\n\r\n\r\n\r\n

                  \r\n
                • Multi-Factor Authentication (MFA)<\/strong><\/li>\r\n
                • Conditional Access<\/strong><\/li>\r\n
                • SPF<\/strong><\/li>\r\n
                • DKIM<\/strong><\/li>\r\n
                • DMARC<\/strong><\/li>\r\n
                • Secure mail connectors<\/li>\r\n
                • TLS requirements<\/li>\r\n
                • Email security gateway integration<\/li>\r\n<\/ul>\r\n\r\n\r\n\r\n

                  Moving to Microsoft 365 gave us an opportunity to modernise both the email platform and the controls protecting user accounts.<\/p>\r\n\r\n\r\n\r\n

                  \r\n\r\n\r\n\r\n

                  💻 Upgrading Office at the Same Time<\/h2>\r\n\r\n\r\n\r\n

                  The organisation was still running Office 2016.<\/p>\r\n\r\n\r\n\r\n

                  Since users were moving onto Microsoft 365, we used the project as an opportunity to modernise the desktop Office applications as well.<\/p>\r\n\r\n\r\n\r\n

                  Scripts were created to automate the process.<\/p>\r\n\r\n\r\n\r\n

                  The deployment workflow removed the legacy Office installation and installed the required Microsoft 365 Apps configuration.<\/p>\r\n\r\n\r\n\r\n

                  Automating this was particularly important when dealing with hundreds of endpoints.<\/p>\r\n\r\n\r\n\r\n

                  Where users had unusual requirements or additional Office components, those exceptions were handled individually through the normal service desk process.<\/p>\r\n\r\n\r\n\r\n

                  \r\n\r\n\r\n\r\n

                  🖨️ The Things People Forget About: Printers and SMTP<\/h2>\r\n\r\n\r\n\r\n

                  User mailboxes weren’t the only things sending email.<\/p>\r\n\r\n\r\n\r\n

                  There were also multifunction printers, scanners and other devices using the existing Exchange environment as an SMTP service.<\/p>\r\n\r\n\r\n\r\n

                  These sorts of dependencies are very easy to overlook during an email migration.<\/p>\r\n\r\n\r\n\r\n

                  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.<\/p>\r\n\r\n\r\n\r\n

                  Each device and application therefore had to be identified, tested and migrated appropriately.<\/p>\r\n\r\n\r\n\r\n

                  It’s a good example of why an Exchange migration is rarely just an Exchange migration.<\/strong><\/p><\/blockquote>\r\n\r\n\r\n\r\n

                  \r\n\r\n\r\n\r\n

                  📢 Communication Was Part of the Technical Project<\/h2>\r\n\r\n\r\n\r\n

                  One lesson I’ve learned from migrations is that technical success isn’t enough.<\/p>\r\n\r\n\r\n\r\n

                  Users need to know:<\/p>\r\n\r\n\r\n\r\n