13-05-2021

Microsoft Exchange Migration Tool

Microsoft Core Services Engineering (CSE, formerly Microsoft IT) manages one of the largest enterprise infrastructures in the world. The staged migration of more than 150,000 mailboxes from Exchange on-premises servers to Office 365 and Exchange Online in 2015—a multi-step process that took months.

Migration Manager for Exchange is an efficient exchange migration and management tool enables easy consolidation of your exchange environment. For the best web experience, please use IE10+, Chrome, Firefox, or Safari. What's New with Microsoft Exchange 2016 and Office 365. Sep 19, 2018  Use this type of migration if you're running Exchange 2003 or Exchange 2007, and there are more than 2,000 mailboxes. For an overview of staged migration, see What you need to know about a staged email migration to Office 365. To perform the migration tasks, see Perform a staged migration of Exchange Server 2003 and Exchange 2007 to Office 365.

By planning ahead and then applying lessons learned during early deployments, we accomplished the daunting task of moving most user mailboxes and decommissioning most on-premises Exchange servers. This paper describes the steps we took, the challenges we faced, and our recommendations for IT pros who face this migration journey. You can employ some of the practices and concepts discussed here to help with your own migration, or simply for tasks such as general enterprise service onboarding.

Note: This paper is based on the experience and recommendations of CSE and is not intended to serve as a procedural guide. Each enterprise environment is unique; therefore, each organization should adapt the plans and best practices to meet its specific operating system management needs.

This paper is an edited version of the original paper and has been updated for length and to reflect product and organizational name changes.

Benefits of using Exchange Online

Before releasing Office 365 to the public, Microsoft recognized the advantage—to both users and the company—of migrating to Exchange Online. Exchange Online offers many benefits to users, including:

  • Continually updated Outlook Web App and Outlook 2013.
  • Access from anywhere and from any device.
  • A much larger mailbox (50 GB).
  • Guaranteed email service uptime (99.9 percent).

As IT managers, we also benefitted from:

  • Reduced server hardware and storage, which reduced costs.
  • Less time needed to support the email system, which freed up people for other projects.
  • Simplified litigation hold capabilities.
  • Guaranteed business continuity and disaster recovery.
  • We kept the ability to keep some mailboxes in on-premises Exchange for special situations.

Planning and preparation were key

Among other things, we thought about how to prioritize the migration. We determined which internal business applications would be affected by mailbox migration and decided how to test them. We also developed tools that both CSE and users could use to fix problems that arose.

But before any implementation could begin, we needed to tell everyone at Microsoft about changes coming to their email, coordinate with stakeholders, and prepare support teams. We had to confirm the migration process, so we knew it would work, and we had to find business-critical internal applications to make sure they would run. Finally, after everything was in place, we had to decide who would migrate first—and then set the date.

The communication plan

Timely and thorough communication lies at the heart of preparing for migration. We identified and approached stakeholders and obtained their approval. We prepared support materials and trained Helpdesk staff who would support the new service. And we created an array of informative communications and self-service materials for users.

We communicated with people whose mailboxes were being migrated in two ways: we published information to the intranet and we sent email. We also shared information with the IT managers at each office site.

We wanted to make sure that users could get the Exchange service reference materials they needed after migration. Our tool for publishing this information was SharePoint. We used standard templates to display service information, a setup page, troubleshooting tips, known issues, and support and other information.

Note: Troubleshooting tips were steps that users could follow for self-service. Both the troubleshooting and known issues sections saved time for the support teams and for the CSE team because they reduced the number of user assistance requests.

Employees could find information about the service they were migrating to on:

ITWeb. ITWeb is an internal Knowledge Base for Microsoft employee. We published a matrix that listed email features before and after migration. This helped set user expectations early by explaining the features they would gain or lose.

MySetup. When a user goes to the MySetup page, the request to the page identifies the user. The page displays personalized information, including the name and status of their current email service and support and setup preferences. On this page, users could see if their mailbox was still on Exchange on-premises or on Exchange Online.

The communication cadence

Our communication plan included a series of emails to inform people about the upcoming migration. After trialing different timing for our emails and reviewing user satisfaction scores, we set up a schedule for user notification. The initial, All-in email went out two weeks before migration, a Scheduled email was sent two weeks before migration, and a Welcome email was sent immediately upon successful migration. Although some people said that this schedule did not give them enough warning, most paid attention and said it was enough time to prepare for the migration without forgetting about it.

We also set up a couple of contingency email templates to use if a migration would be delayed or if there were problems during migration.

All-in

The All-in email telling people about migrating to Exchange Online came from a high-level executive. It notified people that their email would be moving soon and to watch for a follow-up email with more information.

Scheduled

We sent the Scheduled email two business days before the migration. That email told people the date their email would migrate and any changes they might experience. We eventually added, “Please read this email and take appropriate action or you may lose email access.” It also gave instructions such as:

  • Using their user name (someone@example.com) to log in to their mailbox instead of the Domainalias format.
  • Using Outlook Web Access (OWA) and Exchange ActiveSync (EAS) and the new web addresses of each.
  • Updating to the latest version of Outlook before migration.
  • Contacting support, along with links to ITWeb and MySetup.
  • Recommending that users print out the email in case they could not access their mailbox after migration.
  • Urging users to complete any necessary steps before the migration date.

Welcome

We sent the Welcome email immediately after migrating a group of users. We welcomed them to the Exchange Online service, thanked them for their patience, and pointed out differences in the new experience. It was similar to the Scheduled email, but it contained more detail.

Note: Users would obviously not see the Welcome message if their email went down during the migration. Using the Scheduled message, they could find support information on the ITWeb pages at any time in the process and could find their current service on the MySetup page. Finding their current service status told users if their migration succeeded or not.

After migration, users’ mobile devices stopped synchronizing email until they reconfigured them by correcting the EAS address in configuration settings. For users, this was one obvious way to know that they were successfully migrated.

Exchange Migration Assistant

Delayed

We sent a Delayed email if we had to postpone a migration. We sent it two business days after the scheduled migration date if it was not completed. We informed users that we were still working on their migration, thanked them for their patience, and reminded them that they would receive another email after migration was complete.

Incident

An Incident email was sent when something went wrong. It described the incident and the resolution, and it reminded users that they could check the status of their service on the MySetup page.

Other communications

During the planning, execution, and follow-up phases of migrating to Exchange Online, we engaged Microsoft employees in other ways.

Microsoft Exchange To Office 365 Migration Tool

Marketing, surveying, and special requests

To attract volunteers for the first migration, we placed notices on the corporate intranet home page and on digital displays around the corporate campus. A week after migration, we sent out a survey that asked people about their migration experience. A month later, we sent a survey that asked about overall performance and satisfaction with the service. We also provided forms for people to make special requests:

Sign up. People could fill out and submit a sign-up form if they wanted to migrate early.

Opt out. They could use this form if they wanted to delay migration.

Request Fulfillment. This page offered forms that people could use to request changes such as adding accepted domains and adding an IP address to the allow list.

Establishing governance for a smooth transition

Other Microsoft teams were involved in the mailbox migration effort. The purpose of the governance step was to make sure that these teams understood how migration would affect their workloads and responsibilities and to give them the opportunity to ask questions, raise objections, and suggest changes.

We created a PowerPoint deck that described the project charter for the migration. We sent this deck to the required governance and review channels, also called CABs (change advisory boards) or stakeholders. These partner teams included Networking, Identity (Active Directory/Accounts/Federation Services), Legal, and Support and Helpdesk teams. We needed to make sure that all teams were prepared to support migration.

As the last step in the governance process, we got sign-off from stakeholders on the final version of the project charter. At this stage, we engaged our Legal and Human Resources teams to ensure that we were in compliance with local requirements at regional datacenters around the world.

Preparing support teams is vital

To help user support teams prepare for the calls they would receive during migration, we gave them training materials, email setup steps, descriptions of all known issues and bugs, and information about the escalation process.

Tier 1 support is the internal Helpdesk; at this level, users might be using an incorrect password. If Tier 1 cannot solve the problem, they escalate the issue to Tier 2. At this level, a user might need to repair their Outlook profile. When an issue couldn’t be resolved at Tier 2, it escalated to the CSE team that worked on the migration, or Tier 3. Issues at this level might be problems such as bugs in the product or issues that need to be fixed at the identity level.

Defining escalation paths

To prepare for migration, we had to define and communicate escalation paths. The escalation paths changed according to the phase of the migration.

  • During the Pilot phase, we escalated directly to the Exchange product group. When we encountered a non-trivial issue, we emailed a specific engineer in Exchange. This was the most efficient because we knew that things were going to break in this phase.
  • After the Pilot phase, we followed a more typical process of going through Helpdesk and then, if necessary, escalating to the Exchange product support team in Microsoft Customer Service and Support.
  • We created escalation paths for other stakeholders, including the Identity and Networking teams.
  • We prepared our own team members by holding daily sync meetings and making sure that everyone knew where to find the training materials that were distributed to the Helpdesk and product support teams.

Creating service quality metrics

We set and closely followed many service quality metrics, such as the number of mailboxes that had been successfully migrated. Watching the metrics during migration helped us make prompt decisions. The primary metric we watched was Helpdesk ticket count. If we noticed more than a 10 percent increase in tickets, we stopped all migration. This increase indicated that there was a serious problem.

Validating migration and testing business-critical applications

Before we could move forward, we needed to validate and test the migration process and locate business-critical internal applications that depended on email.

Validating migration. We created test accounts and migrated them to test migration scenarios using Outlook, using OWA, and on our mobile devices. We developed a validation procedure that guided our testers and focused on different parts of the new service. In one scenario, for example, we tested the Outlook free/busy schedules of users in different Exchange services.

Testing business-critical applications. The many businesses in Microsoft depend on internal business applications that use mailboxes. These are often high-impact applications, which means that if the application (or its email) breaks, it could disable some part of the company. We needed to identify internal apps with mailboxes and prepare them for migration. And someone had to test the applications to find out if we could migrate them to the new service at all.

We located business owners and asked them to test their internal business applications. Once testing was complete and the app was verified on the new service, we could migrate it a later, appropriate date. Any internal business applications that broke during migration had to be reengineered to run on the new service.

We did not know what or where these important applications were when we started this project. It required much research because some of these applications had no documentation and ownership had changed, so it was difficult to find current owners.

Selecting users and scheduling migration

We had to carefully prioritize which users to migrate and when. The nature of a person’s work and the technologies they worked with were considered carefully. Some examples of scheduling choices include:

Engineering first. We migrated engineers and IT people in the Pilot phase because they work primarily with their own internal teams. If their email went down, only they would be affected. Plus, these people have strong technical skills, were highly motivated for the migration to succeed, and could give us valuable information about any problems they encountered. We wanted to find problems early in the process so that we could learn from them and use these lessons throughout the migration.

Customer-facing groups later. We chose to migrate customer-facing employees—those who often work with partners or customers—later in the migration process, after we had expertise in supporting the migration.

Avoid sensitive weeks. We did not migrate certain teams at certain times because of the nature or timing of their work. For example, because Sales and Finance employees have special responsibilities near the start and end of months and quarters, we migrated them only during the middle two weeks of a month.

Avoid freeze periods. Freeze periods are the last two weeks of the calendar year (December) and the fiscal year (June). These are busy times for some teams—especially Finance—so we did not want to cause issues and escalations during those times. We also avoided migrating members of any product group that was releasing a new product, which was the case with Xbox One.

Creating tools and reports

We created tools to help us keep track of the overall health of the migration. For example, we knew that during migration we would need to find out how many mailboxes were in each of the services (on-premises Exchange and Exchange Online) so we tracked those numbers by setting up PowerShell scripts to copy data to SQL databases. Other reports included:

Delegation families. A delegation family consists of users who have delegated permissions to someone else (described in more detail in the Pilot phase section).

Mailbox count. The number of migrated mailboxes across all our services and the number of migrated mailboxes classified by office, site, and region.

We also developed:

Outlook troubleshooting tool. We built this tool when we discovered that, after migration, up to 10 percent of users needed to repair their profiles. This tool changed a value deep in the Outlook settings but let users do it with a single click. We later added functionality to make registry key changes for users, when needed.

Other custom tools. Before migration, we developed tools that let users fix problems themselves by, for example, confirming and setting mailbox permissions. We updated these tools to work with the new Exchange Online service.

Tracking issues and bugs

We ensured we had a process to track issues and bugs on SharePoint and that we had a follow-up and closure process for each issue or bug.

The migration journey

The migration was divided into four phases:

  • Pilot phase.
  • Initial Volume phase.
  • Continuous Volume Migration phase.
  • Decommissioning phase.
Microsoft exchange migration tool for exchange 2010

Although any corporate IT migration is likely to encounter many of the same challenges, these aspects of our deployment were unique:

  • During the early phases of migration, we moved mailboxes to a beta version of Office 365 Exchange Online because Microsoft had not yet released Office 365. Some migrations that failed in the early years would succeed now.
  • We had to migrate mailboxes from multiple Active Directory forests.
  • In addition to making sure that the email service worked, we supported ongoing development of new products and features for the Microsoft Exchange product group.

Phase 1: Pilot

During the Pilot phase, volunteers and internal users that would have the least impact on Microsoft business were moved first, giving us time to learn from and refine the migration. We tested our communications plan, refined our user support plan, and fine-tuned preliminary steps so that the process would run smoothly when we automated and expanded the Exchange Online deployment across the company.

Much of the Pilot phase consisted of migrating the Microsoft Office product group and our own IT group. Using lessons learned during this phase, we updated validation testing for new vulnerabilities and specific client scenarios. These scenarios included not only using Outlook and Outlook Web App on desktops and laptops, but email on mobile devices and other client applications. As a part of this testing, users validated whether all features of the migrated mailbox worked or whether some functionality was broken. We also carefully monitored each batch of migrating accounts and documented Helpdesk issues and escalations.

Our biggest lesson was that we needed a process to allow migration exceptions. We learned that some people had to temporarily delay migration because something about their environment, such as the applications or technologies they used, would not work. We even had to turn down certain volunteers because we found that, for technical reasons, they could not successfully migrate.

Migration steps

We initially followed these steps to migrate mailboxes:

  1. We ran tools to ensure that mailboxes could be moved by filtering out exceptions and for users opting out.
  2. We sent out the Scheduled migration email.
  3. We ran a script that removed any non-accepted domains in the user’s email address list.
  4. We disabled Exchange Unified Messaging (EUM) for users.
  5. We added the service address (service.microsoft.com) to the user’s email address list. (Note that adding this address can cause a delay due to directory synchronization.)
  6. Migration was automatically suspended when mailbox content was 95 percent moved, until the scheduled cutover.
  7. The script retried if migration failed and sent an error log if failures continued, so it could be escalated to service engineering to investigate.
  8. The auto-suspended migration finished and cut over on the scheduled date.
  9. We added the service license.
  10. We re-enabled EUM.
  11. We sent the Welcome migration email.
  12. We sent the migration survey to users seven days after the completed migration.
  13. We sent the performance survey to users 30 days after the completed migration.

As we continued to migrate users and discover issues, we added more steps to the process, including:

  • We made sure that objects were synced across our services and that there were no mismatched globally unique identifiers (GUIDs) or persistent unique identifiers ( PUIDs). (Other organizations with less complex deployments than Microsoft should not encounter this issue.)
  • Before migrating a mailbox, we copied all the mailbox attributes to ensure that permissions and rules would be intact after the migration.
  • We made sure that the migration didn’t create duplicate mailboxes by performing an Active Directory cleanup after migration was complete.
  • We verified that the new mailboxes were created, and that mail would be delivered to them.
  • We archived and deleted move requests within seven days after the migration. (Typically, move requests were stored on the server for 30 days after migration.)

Challenges

We encountered a number of challenges during the Pilot phase:

  • We had to deal with the complexity of ensuring a positive client experience across multiple protocols, applications, and networks.
  • We had to edit our pre-migration communications to ensure that a general audience could understand all our messages.
  • There were initial onboarding issues due to limited egress proxy capacity in the internal network.
  • There was an impact on Helpdesk and the user experience due to limited proactive monitoring of the email service with a tool such as System Center Operations Manager (Operations Manager). This meant that if a service outage occurred, we were not notified with a custom alert, so we could not reach out to users quickly enough to prevent calls to Helpdesk.
  • We had to mitigate some negative assumptions about the service, which caused some users to opt out of migration.

In the hybrid (cross-premises) deployment, Azure Active Directory did not always synchronize in a timely manner. We had to manually replicate cross-premises items including dynamic distribution groups and Send As mailbox permissions.

Creating the exception list

User mailboxes were grouped in exception categories that applied to their circumstances. We used Active Directory and PowerShell queries to define the exception list categories.

Standard: No exceptions applied to these mailboxes. We could migrate them with no known negative effect.

Sales/Finance organization: These people were in the Standard category but were temporarily exempt during sensitive times and freeze periods.

Location: Migration was limited to locations within the United States. Some US office locations were on hold until network sign-off due to a network egress issue.

Feature requirement: The mailbox was temporarily exempt from migration until particular features, such as S/MIME encryption was enabled or legacy telephony requirements were resolved. S/MIME encryption was not supported at the beginning of the migration process, so people who had an S/MIME certificate had to be migrated after the Exchange team added support for this feature. We also had to create dial plans for legacy telephony users, which took extra time and delayed the migration of these users.

Executives and delegated mailboxes: Many executive admins have delegation authority over their manager’s mailbox so that they can send mail on the manager’s behalf. They might also have delegation authority over conference rooms that have mailboxes, which allows them to accept invitations for the room. This group of executive admin conference room is called a delegation family. We had to work carefully with delegation families by engaging executive admins to confirm migration schedules. We had to verify who they needed to maintain delegation for, because some of them reported to more than one executive. We migrated people with delegation relationships separately, but we had to migrate each family in the same batch. People in delegation families got special versions of the Scheduled and Welcome emails, which gave them specific resources to use if they encountered problems with delegation. Also, many conference rooms at Microsoft use displays by Crestron. When we started the migration process, Crestron displays were not compatible with Office 365. After a compatible version of Crestron is deployed, we can migrate the mailboxes of all affected conference rooms.

System accounts: Also called service accounts, these accounts were created for business purposes (such as gathering team email), but they are not an employee’s mailbox. We migrated them in a separate batch from their owners but at the same time as their owners. It was important to move them at the same time because cross-premises delegation was not supported. As with delegated mailboxes, we had to engage with owners and then manually move system accounts.

Pilot Phase: What we learned

We discovered during the Pilot phase that we had to examine how different parts of Microsoft used various email features so we could enable the corresponding features (if any) in Exchange Online for those users. For example:

  • Certain businesses within the company were still using old SMTP services simply because they had been using them for many years.
  • People had written applications that depended on an Exchange mailbox but did not use autodiscovery; instead, they used hard-coded addresses. Now, Outlook can find a user’s mailbox even if the user is not on the corporate network. They just need to provide valid credentials when logging in to their computer. Users typically are unaware of autodiscovery because it works behind the scenes.
User tasks

Before migration, we alerted users to the following tasks:

  • To minimize connectivity issues, all Outlook users must update to the latest version. Users can do this easily through Windows Update. (We asked people to do this in the Scheduled email message.) This is necessary because server changes are often applied to Office 365 and all clients must have the corresponding changes.
  • Any user who has rules that they want to keep after migration must save them to the server, not to the client. We take this safety measure so that they can repair or rebuild their Outlook profile after migration, if necessary.
Roll-back procedure

We sometimes needed to move people back to on-premises Exchange, at least temporarily. In some cases, they had to return to the original service to be keep using a feature that was, at the time, unsupported in the online service. In other cases, people were migrated back and had to remain in on-premises Exchange until we found a solution.

Microsoft Exchange Migration Tool Free

Phase 2: Initial Volume

During this phase, we automated the migration process to make it more manageable. This allowed us to increase our migration rate to 4,500 mailboxes per week. Early on, we worked with executives to send the All-in email to people who would be migrated. We continually updated user communications (surveys, the Knowledge Base site, and the email cadence) and we started sending a monthly newsletter to update users on migration progress. For this phase, we targeted certain classes of mailboxes to move first:

  • Mailboxes in the Standard category on the exceptions list, namely, mailboxes that had no special feature requirements such as S/MIME encryption.
  • Mailboxes that were hosted in legacy services that would be decommissioned.

We limited the number of users migrated to 1,500 per day on Tuesdays, Wednesdays, and Thursdays after 6:00 PM Pacific Time to lessen the impact on Helpdesk. We chose these days because on Mondays people are catching up on their work after the weekend, and on Fridays, we wanted to avoid Helpdesk issue escalations.

We also started tracking service quality metrics. An example of a service quality metric is the Helpdesk ticket rate after migration. We would stop migration if the Helpdesk ticket rate exceeded 10 percent for a given migration batch. Similarly, we continually refined the process for analyzing user feedback and taking action. We set up a weekly check-in with partners to review any impact they experienced. Finally, we expanded our validation process to include other applications, protocols, and networks.

Challenges

We encountered new challenges during this phase of migration. Our goal was to stay ahead of issues that affected or may affect the quality of service. We worked to counter negative assumptions about the online service that came from users who migrated during the Pilot phase, which caused some users in this phase to opt-out. Despite our best efforts, some migrations were not completed on schedule.

It was challenging to migrate large mailboxes (over 10 GB), so we updated our processes to start the migration process a week before they were scheduled. We also mitigated possible delays by setting expectations with users—we targeted a specific date, but it might be delayed two or three days depending on the mailbox complexity.

Updating our processes

During this phase, we made several changes to our processes. The biggest change was automating email communications and the migration process itself. This started by determining mailbox eligibility by using PowerShell to obtain data from Exchange, Active Directory, and HeadTrax (HR) systems.

To support the migration process and improve the user experience, we developed troubleshooting tools that ran batch files, and we developed client synthetics to establish baseline performance metrics that helped us get a better view of the migration process from the client side. We created and used synthetic (or derived) metrics, which we gathered by running Microsoft Azure and on-premises virtual machines. A client synthetic is an artificial account that emulates a user, which we put through the migration process. By monitoring simulated performance numbers, we could put ourselves in the clients’ shoes and make changes to improve their experience. A synthetic also generates performance alerts, automatically notifying us if something stops running.

At first, we deployed client synthetics to mimic both on-premises (over the WAN) and Azure-based (over the internet) virtual machines to test the performance of client scenarios such as mail flow, load time of free/busy calendar information, and time required for autodiscovery in Outlook. We connected these client synthetics to Exchange at each datacenter location. We developed a C# application to produce synthetic transactions and analyze the Exchange environment. We also developed a PowerShell app that connected to the Exchange environments to check for known issues and bugs.

All synthetic results and data were stored in SQL Server databases in Azure. We received reports for many worldwide locales, which included performance numbers on Autodiscovery performance, MailFlow performance, Create Rule, Create EAS Partnership, Load Free/Busy, and Load GAL (Global Address List). For each of those actions, we got metrics on: Min Performance, Median Performance, Max Performance, Average Performance, and Availability.

Phase 3: Continuous Volume Migration

In this phase, migration became an automated run-state process. Although automation succeeded in general, we found more challenges, such as users we could not easily group into a category.

During this phase, we continued to use the established automated process that, based on updated eligibility criteria, continually scheduled the migration of 1,500 users daily from Tuesday through Thursday. We also began to migrate some mailboxes on Mondays and Fridays, when necessary.

We avoided migrating on weekends because that was when network maintenance and synchronization were most likely to occur. And after learning about the needs, for example, of executive accounts, we established separate projects to migrate more complex mailboxes.

We set up a service team that was responsible for communications, onboarding, service management, engineering, tools, and reporting. We decided to stop synchronizing with our partner teams (the Networking and the Identity teams) to get sign-off for migration, and used an automatic escalation process if issues occurred.

We further developed and updated our troubleshooting tools (including collecting metrics), and we continued to add client synthetic metrics to the process. We used synthetics to test performance so that we would know when to stop migrating, if necessary. We also set up a process to collect additional mailbox metrics including volume usage and client connections.

We continually updated our user communications and feedback processes, and developed new communications to target specific user personas, such as admins, which included information about delegation and calendar management.

Challenges

Some users wanted to migrate early, but they were not eligible. The more complex and difficult mailboxes such as executives and system accounts had to wait until we could develop an account-management tool to directly provision on-line service and cross-premises delegation. Cross-premises means spanning the on-premises Exchange service and Exchange Online.

For example, if Person A’s mailbox is in on-premises Exchange and Person B’s mailbox is in Exchange Online and Person B wants to check Person A’s schedule—this constitutes a cross-premises action that we had to specially validate. We knew our process worked in an all on-premises situation or completely on Exchange Online, but not between the two. We originally did not have this situation in our migration plans because we thought that everyone would be on the same service, but then realized that the migration schedule would indeed allow for this crossover.

Executive migration

We established a separate process with executives and admins to migrate executives, by first examining the migration schedule and confirming the delegation family to ensure that they migrated as a group.

System account migration

Also called service accounts, system accounts are special non-user accounts created for specific uses. We created system accounts to test migration, for example. We learned to advise mailbox users how to configure their post-migration mailbox in certain ways, such as by resetting the web address for EWS.

We established a separate process to engage system account owners and ensure that their mailbox and programmatic uses could migrate. We also developed service guides that described how to code with autodiscovery and gave them extra time to confirm that they could successfully migrate.

New tool for account management

The Accounts team created and used an account management tool that provisions and manages accounts and mailboxes for new hires. Originally, the tool provisioned new hires in on-premises Exchange. We asked them to update their tool so that it would provision new hires in Exchange Online. We also had to schedule the time it would take this team (outside our IT team) to develop and test this tool.

Phase 4: Decommissioning

After users in on-premises Exchange servers were moved to the cloud, they could be decommissioned. We started with more than 150,000 mailboxes and migrated more than 90 percent of Microsoft to Exchange Online. This means that we needed only a fraction of the original on-premises Exchange servers and we have decommissioned the rest; over 220 servers have been removed.

A couple of issues caused us to modify our processes during this phase.

Addressing dial plans

Some users who had Exchange Unified Messaging (EUM), which supplies voice mail, used dial plans. With a dial plan, they could call a toll-free number to retrieve their voice mail. These dial plans were routed through on-premises Exchange servers. We discovered that we needed to re-route these dial plans early in the process to make them point to the new service.

Working with litigation hold and email data retention

When a legal department places an email account on litigation hold, it means that the contents of the mailbox must be safeguarded for a prescribed retention period. Litigation hold and a 30-day retention period applied to some email accounts during our migration.

In other words, after we moved all the mailboxes from a particular server, we had to wait 30 days before we deleted anything from the server, even though the email was in the new service. After the 30 days, we contacted legal and the HR representative to verify that the retention period was over. Once they agreed, we decommissioned the on-premises Exchange servers.

Our experience with litigation hold taught us that when an account is on litigation hold, the user’s mailbox dumpster (Deleted Items) does not empty. This causes the mailbox to become very large—in some cases, over 100 GB—and difficult to move. And almost all executive email accounts are on litigation hold.

We worked with legal teams to determine what email we could remove from a user’s mailbox to reduce its size and make migration more manageable. We also moved content to an archive if the mailbox was too big in order to start the migration.

Managing other exceptions

We had to delay or cancel the migration of certain mailboxes due to special circumstances, often because of the nature of a user’s job or because of applications and features that caused technical issues. In many cases, we found that migration disabled the mailboxes that we moved. We then had to migrate them back to on-premises Exchange to investigate and solve the problem.

MSLPA users

Microsoft Least Privileged Access (MSLPA) users have limited access to certain corporate resources such as SharePoint and Lync (now Skype). We tried to figure out how to migrate them to Office 365, but we encountered several obstacles. First, these users are in the MSLPA forest of Active Directory, which is not federated with Office 365. Also, migrating these users to Office 365 would give them access to SharePoint and Lync, which is not allowed. For these reasons, we realized that we needed to keep them in on-premises Exchange. We moved them in a small deployment to one of our on-premises Exchange servers, where they will most likely stay.

Retail hourly

When another company was sued for overtime pay because its employees checked work email in their off hours, Microsoft took steps to avoid such a lawsuit. Our original solution in on-premises Exchange was to block access to Outlook when people were not on the corporate network and at specific times of day. However, we did not have a post-migration solution in Exchange Online to block access in this way.

Eventually, the decision was made to let these people check mail after hours and be paid for it. When we got official sign-off from HR and the legal department, we migrated these people, who now have the same access to email as other employees.

Worldwide datacenters

Office 365 is currently limited to datacenters in the region where the account was opened. For example, users on the Microsoft Redmond campus are subscribed to a tenant in North America, which means that we can only use datacenters hosted in North America. Employees in Asia and Europe who migrated to Office 365 would have connected from their region to the North America region, which might cause latency. The solution was for these people to move to dedicated services in their own region (Office 365 Exchange Online Dedicated), which are hosted in Asia and Europe.

Loss of password reset through OWA

In our on-premises Exchange installation, people could use OWA to reset their passwords rather than connecting to the corporate network through Windows. However, Office 365 does not let users reset their passwords this way, so migrated users lost that capability.

The solution was for the Identity team to implement a self-service password reset option. (The Identity team owns Active Directory and the accounts process at Microsoft.) This solution was intended primarily for partners, such as an employee of Samsung who works in a Microsoft office and uses a Microsoft mailbox. We had to wait for the Identity team to port a solution for them before we moved them to Exchange Online.

Lessons learned

In the process of migrating 150,000 mailboxes from on-premises Exchange to Exchange Online, we learned several valuable lessons that can be applied as best practices in other migration deployment plans. Some of these lessons we learned during migration and some as outcomes after migration. These lessons can be divided into two general categories: service manager recommendations and ways to provide critical support to keep the migration experience as painless as possible for users.

Service Manager recommendations

The CSE Exchange Service Manager who works on the email and calendaring team in the User Productivity Services group at Microsoft compiled the following recommendations during the migration process.

Learn about dependent services: Learn other dependent services, such as your network infrastructure, DirSync (directory synchronization of Active Directory), corporate account creation, and how your service and client protocols interact with them end-to-end.

Microsoft Exchange Online Migration Tool

Learn the current service configurations: Learn current service configurations and settings and any other legacy artifacts to determine your next steps.

Profile the user and system mailboxes: Profile user and system mailboxes to determine the average mail volume through Exchange Client Access Server (CAS) and transport logs to determine what can be migrated.

Maintain a client-side focus. Shift from a server-side to a client-side focus. Know your users and hear their voices through surveys and feedback.

Ask for the features you need. Make your voice heard. Request the feature set that you need for your project or enterprise.

Ensure access to your tools and resources. Make sure that you can access your own internal tools and resources anytime and anywhere, and that you can consolidate the data from them when needed. Consider using technologies such as Microsoft Azure, SharePoint Online, and Microsoft SQL Server.

Learn to use PowerShell: PowerShell is your friend when you need to access information quickly; learn it and use it well.

Document all processes and procedures: Document all processes and procedures to improve team efficiency and to identify points of automation.

Prepare your network. Ensure that your network is ready to take on the additional internet traffic and can support IPv6.

Snapshot the mailboxes. To enhance the migration experience, ensure that you can carry over attributes, permissions, and rules post-migration by taking a snapshot of mailboxes before you move them.

Set expectations with users. Communicate with users to ensure that you set expectations and tell them what they should prepare for. For example, if they lose delegated permissions, they must know who to contact for support.

Update Outlook. Tell all users to update Outlook to the latest version, and tell them that their Outlook profile might be corrupted after migration. Include instructions to both Helpdesk and to your users on how to repair or rebuild the Outlook profile; also, let users know to save their Outlook rules to the server or back them up to where they can reload them if needed.

Prepare for legacy artifacts. You will find legacy artifacts that could block migration. Be prepared to take action and enable those accounts to migrate later.

Prepare for large mailboxes. Large mailboxes can be tricky to migrate—for example, if they are on litigation hold. Learn ways to copy mailbox items to an archive and to remove email data that was delivered during particular times.

Critical support for the ideal experience

We recommend that you consider the following technical and human factors before and during migration to create the best user experience for the users whose mailboxes you will migrate.

Network optimization. Pay attention to Network Optimization for online (anytime and anywhere) services outside the corporate network (WAN) and for the internet.

Federated authentication. Use federated authentication (Active Directory Federation Services) to enable users to access corporate services anytime and anywhere over the internet.

Team involvement. Involve teams responsible for the directory service to ensure consistent synchronization across the services.

Microsoft Exchange Migration Tool 2016

Helpdesk support. Make sure that your internal support team is prepared to ensure a good user experience when things go wrong. Also, ensure that support taxonomy is accurate and adhered to. This helps support trending of issues and improves the user experience.

Managing your own migration journey

By planning ahead and then applying our lessons learned, you too can take your company through the migration of Exchange Online. That way, your users can enjoy the benefits of working anywhere and from any device, while your organization benefits from reduced server hardware and costs, less email support, and reliable business continuity and disaster recovery.

Microsoft Exchange Public Folder Migration Tool

For more information

Microsoft IT Showcase

Microsoft Exchange Migration Tool

© 2019 Microsoft Corporation. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY. The names of actual companies and products mentioned herein may be the trademarks of their respective owners.